后端即时通讯【免费下载链接】nonebot2跨平台 Python 异步聊天机器人框架 / Asynchronous multi-platform chatbot framework written in Python项目地址https://gitcode.com/gh_mirrors/no/nonebot2点击查看免费下载NoneBot 作为跨平台异步聊天机器人框架通过响应规则来决定一个事件是否交给某个事件响应器Matcher处理。本指南以 NoneBot 2.4.4 版本文档为骨架结合仓库源码与测试用例系统讲解RuleChecker的编写方式、Rule的组合与合并、主动调用规则以及startswith、command、regex等全部内置响应规则的实现细节与实战用法帮助你精准控制机器人的事件响应行为。响应规则在事件处理链路中的位置机器人在实际应用中往往会接收到多种多样的事件类型NoneBot 通过响应规则来控制事件的处理。在 指南 中我们为weather命令添加了一个ruleto_me()参数这个参数就是一个响应规则确保只有在私聊或者bot时才会响应。从事件处理流程看响应规则的检查并不是最先执行的。在 事件响应器实现 中check_rule的逻辑是event_type event.get_type() return event_type (cls.type or event_type) and await cls.rule( bot, event, state, stack, dependency_cache )也就是说一个事件要经过事件类型检查 → 权限检查permission→ 响应规则检查rule三步全部通过后才会触发响应器。因此响应规则负责的是在类型与权限都满足的前提下进一步筛选出具有某种特征的事件。关于完整的事件响应器组成类型、权限、规则、优先级、阻断、有效期等可参考 事件响应器进阶。RuleChecker返回 bool 的依赖函数响应规则是一个Rule对象它由一系列的RuleChecker函数组成每个RuleChecker函数都会检查事件是否符合条件如果所有的检查都通过则事件会被处理。RuleChecker是一个返回值为bool类型的依赖函数即RuleChecker支持依赖注入。在 类型定义 中T_RuleChecker: TypeAlias _DependentCallable[bool] RuleChecker 即判断是否响应事件的处理函数。 依赖参数: - DependParam: 子依赖参数 - BotParam: Bot 对象 - EventParam: Event 对象 - StateParam: State 对象 - DefaultParam: 带有默认值的参数 这意味着RuleChecker的形参可以从Bot、Event、State乃至其他子依赖中自动注入取值写法上与事件处理函数一致。我们可以根据 配置项在weather插件目录中编写一个响应规则from nonebot import get_plugin_config from .config import Config plugin_config get_plugin_config(Config) async def is_enable() - bool: return plugin_config.weather_plugin_enabled weather on_command(天气, ruleis_enable)在上面的代码中我们定义了一个函数is_enable它会检查配置项weather_plugin_enabled是否为True。这个函数is_enable即为一个RuleChecker。在这个例子中is_enable没有声明任何参数直接读取插件配置而一旦需要检查这条消息是否来自某个用户就可以注入Event参数例如使用event.get_user_id()获取发送者 ID。需要说明的是在 Rule 构造 中普通函数会被自动包装为Dependent[bool]因此同步函数同样可以作为RuleChecker使用框架会自动适配。RuleRuleChecker 的集合与并发检查Rule是若干个RuleChecker的集合它会并发调用每个RuleChecker只有当所有RuleChecker检查通过时匹配成功。例如我们可以组合两个RuleChecker一个用于检查插件是否启用一个用于检查用户是否在黑名单中from nonebot.rule import Rule from nonebot.adapters import Event async def is_enable() - bool: return plugin_config.weather_plugin_enabled async def is_blacklisted(event: Event) - bool: return event.get_user_id() not in BLACKLIST rule Rule(is_enable, is_blacklisted) weather on_command(天气, rulerule)从源码看Rule的实现位于 nonebot/internal/rule.py有几个值得注意的实现细节去重存储所有RuleChecker会被解析成Dependent[bool]后放入一个set中重复传入的同一函数不会重复执行。并发执行Rule.__call__使用anyio.create_task_group()创建任务组对每个checker调用tg.start_soon(_run_checker, checker)并发启动每个检查结果通过result is_passed累加因此结果是所有检查者通过才通过。跳过语义如果某个RuleChecker抛出SkippedException该检查会被视为未通过结果置为False这在测试 tests/test_rule.py 中有明确验证。空规则恒真当Rule不含任何RuleChecker时__call__直接返回True即无规则 全部放行。禁止或运算Rule不支持|合并__or__会直接抛出RuntimeError(Or operation between rules is not allowed.)。因为响应规则本质上是与语义全部满足才响应不存在或的合法场景。合并响应规则使用 运算符合并与复用在定义响应规则时我们可以将规则进行细分来更好地复用规则。而在使用时我们需要合并多个规则。除了使用Rule对象来组合多个RuleChecker外我们还可以对Rule对象进行合并。在原weather插件中我们可以将ruleto_me()与ruleis_enable使用运算符合并from nonebot.rule import to_me from nonebot import get_plugin_config from .config import Config plugin_config get_plugin_config(Config) async def is_enable() - bool: return plugin_config.weather_plugin_enabled weather on_command( 天气, ruleto_me() is_enable, aliases{weather, 查天气}, priorityplugin_config.weather_command_priority, blockTrue, )这样weather命令就只会在插件启用且在私聊或者bot时才会响应。合并响应规则可以有多种形式例如rule1 Rule(foo_checker) rule2 Rule(bar_checker) rule rule1 rule2 rule rule1 bar_checker rule foo_checker rule2支持规则与规则、规则与函数、函数与规则三种组合方式这得益于 Rule 的__and__与__rand__实现当另一侧是Rule时合并双方checkers当另一侧是普通函数时直接将其包装为新的RuleChecker加入集合。同时我们也无需担心合并了一个None值Rule会忽略None值assert (rule None) is rule这一行为在 tests/test_rule.py 中有对应断言Rule(truthy) None与Rule(truthy)等价None Rule(truthy)同样等价并且__and__/__rand__内部在遇到None时直接返回自身因此合并None是零开销的安全操作。这一特性在组合可选生效的规则如根据配置决定是否追加to_me()时非常实用。主动使用响应规则脱离响应器手动判断除了在事件响应器中使用响应规则外我们也可以主动使用响应规则来判断事件是否符合条件。例如rule Rule(some_checker) result: bool await rule(bot, event, state)我们只需要传入Bot对象、事件和会话状态Rule会并发调用所有RuleChecker进行检查并返回结果。从 Rule.call签名 看它还接受两个可选参数stack: AsyncExitStack | None与dependency_cache: T_DependencyCache | None用于在复杂场景下复用外部异步上下文与依赖缓存例如在事件响应器内部再次手动调用某个Rule。对绝大多数场景直接传入bot、event、state三个必选参数即可拿到布尔结果。内置响应规则源码级逐项拆解NoneBot 内置了一些常用的响应规则可以直接通过事件响应器辅助函数或者自行合并其他规则使用。内置响应规则的完整实现集中在 nonebot/rule.py下面逐项拆解其行为与典型用法内置响应规则列表与辅助函数速查可参考 事件响应器进阶。startswith / endswith匹配消息纯文本的开头与结尾startswith(msg, ignorecaseFalse)匹配消息纯文本是否以指定字符串开头。支持传入单个字符串或字符串元组ignorecase控制是否忽略大小写。endswith(msg, ignorecaseFalse)匹配消息纯文本是否以指定字符串结尾参数语义与startswith一致。两者在 实现 中都调用event.get_plaintext()获取纯文本分别使用re.match锚定开头、re.search锚定结尾匹配成功后会把命中的文本写入state的STARTSWITH_KEY/ENDSWITH_KEY中。测试用例tests/test_rule.py验证了大小写、多前缀、非message事件等边界行为。典型用法from nonebot.rule import startswith, endswith # 匹配以 ! 或 / 开头的消息 rule startswith((!, /), ignorecaseFalse) # 匹配以 . 或 。 结尾的消息 rule endswith((., 。), ignorecaseFalse)也可以直接使用辅助函数on_startswith/on_endswith创建响应器。fullmatch / keyword完全匹配与包含匹配fullmatch(msg, ignorecaseFalse)匹配消息纯文本是否与指定字符串完全相同。注意实现中会先剔除空文本再做in判断开启ignorecase时通过str.casefold()做大小写无关比较命中后写入FULLMATCH_KEY。keyword(*keywords)匹配消息纯文本是否包含任意一个关键字返回第一个命中的关键字并写入KEYWORD_KEY。from nonebot.rule import fullmatch, keyword # 匹配消息恰好为 ping 或 pong rule fullmatch((ping, pong), ignorecaseFalse) # 匹配消息中包含 hello 或 hi rule keyword(hello, hi)测试用例见 tests/test_rule.py覆盖了空文本、多关键字、非message事件等场景。辅助函数为on_fullmatch/on_keyword。command最常用的命令匹配规则command是最常用的响应规则它根据配置中的command_start命令起始符默认/与command_sep命令分隔符默认.判断消息是否为命令。命令解析后的结果可以通过Command、RawCommand、CommandArg、CommandStart、CommandWhitespace依赖注入获取相关说明见 依赖注入进阶。在 底层实现 中command规则由两部分组成TrieRule前缀树注册每次调用command(...)时会把命令起始符 命令文本如/help注册进全局CharTrie前缀树。事件到来时由TrieRule.get_value在消息首个文本段中做最长前缀匹配提取出command、raw_command、command_arg、command_start、command_whitespace并存入state。这部分逻辑在 TrieRule 实现 中对富文本消息如命令后紧跟图片也有完整处理参见 tests/test_rule.py。CommandRule校验检查解析出的命令元组是否在注册的命令列表中并根据force_whitespace校验命令与参数间的空白符。典型用法from nonebot.rule import command # 匹配 /help 或 /帮助 开头的消息 rule command(help, 帮助) # 匹配 /help.cmd 开头的消息 rule command((help, cmd))command默认允许命令与参数间不加空格如需严格匹配空白符可使用force_whitespace参数它可以是bool或具体字符串# 命令与参数间必须有任意个数的空白符 rule command(help, force_whitespaceTrue) # 命令与参数间必须恰好是一个空格 rule command(help, force_whitespace )该参数的三种取值None/bool/str与命令后无参数时的行为差异在 tests/test_rule.py 中有系统的参数化测试。辅助函数为on_command这是日常开发中创建命令响应器最常用的入口。shell_command类 shell 命令解析shell_command响应规则用于匹配类 shell 命令形式的消息。它首先与command一样进行命令匹配如果匹配成功则会进行进一步的参数解析。参数解析基于argparse标准库在此基础上添加了消息序列Message支持——文本段会经shlex.split切分非文本消息段如图片会作为整体参数保留。解析结果可通过ShellCommandArgv解析前参数列表、ShellCommandArgs解析后参数字典依赖注入获取若解析失败通过ShellCommandArgs获取到的将是ParserExit异常。from nonebot.rule import shell_command, ArgumentParser parser ArgumentParser() parser.add_argument(-v, --verbose, actionstore_true) rule shell_command(cmd, parserparser)也可以不提供parser参数此时shell_command不解析参数但仍会把argv参数列表写入状态。辅助函数为on_shell_command。相关的解析成功/失败/富文本参数等分支行为见 ShellCommandRule 实现 与 tests/test_rule.py。regex正则表达式匹配regex响应规则用于匹配消息是否与指定正则表达式匹配。有两个值得注意的语义匹配使用search而非match如需从头匹配请使用r^xxx来确保匹配开头匹配对象是EventMessage的str字符串含消息段表示而非PlainText纯文本字符串。import re from nonebot.rule import regex rule regex(r[a-z], flagsre.IGNORECASE)匹配成功后匹配对象会被写入REGEX_MATCHED状态键可通过RegexStr、RegexGroup、RegexDict依赖注入获取匹配字符串、分组元组与分组字典。辅助函数为on_regex。实现与测试分别见 RegexRule 和 tests/test_rule.py。to_me / is_type与机器人相关与事件类型过滤to_me()匹配事件是否与机器人相关私聊或消息中了机器人。其ToMeRule通过注入EventToMe()参数获取event.is_tome()的结果辅助函数on_message等内部即预设了该规则。is_type(*types)匹配事件类型是否为指定类型或一系列类型通过isinstance(event, self.types)判断可用于精确限定某个适配器的特定事件类例如from nonebot.rule import is_type from nonebot.adapters.onebot.v11 import PrivateMessageEvent, GroupMessageEvent rule is_type(PrivateMessageEvent, GroupMessageEvent)这两个规则实现见 nonebot/rule.py测试见 tests/test_rule.py。小结响应规则的选用思路综上NoneBot 的响应规则体系可以概括为三层RuleChecker返回bool的依赖函数是规则的最小单元支持从Bot/Event/State等注入参数可读插件配置、可查黑名单、可做任意自定义判断RuleRuleChecker的集合构造时去重、调用时并发、全过才通过支持合并且自动忽略None也支持直接await rule(bot, event, state)主动判断内置规则startswith、endswith、fullmatch、keyword、command、shell_command、regex、to_me、is_type等全部可通过on_*辅助函数一键创建响应器也可通过自由组合进自定义规则。在实际项目中推荐优先复用内置规则与on_*辅助函数当需要插件开关、用户白名单、时间段限制等业务化判断时再编写自定义RuleChecker并通过Rule(...)或合并进响应器。更完整的内置规则与辅助函数清单、以及CommandGroup/MatcherGroup响应器组的用法可继续阅读 事件响应器进阶相关核心源码位于 nonebot/rule.py、nonebot/internal/rule.py行为验证可参考 tests/test_rule.py。赞分享后端即时通讯【免费下载链接】nonebot2跨平台 Python 异步聊天机器人框架 / Asynchronous multi-platform chatbot framework written in Python项目地址https://gitcode.com/gh_mirrors/no/nonebot2点击查看免费下载相关推荐NoneBot2 响应规则Rule全解析从 RuleChecker 依赖注入到内置规则与主动调用NoneBot2 响应规则Rule全解析从 RuleChecker 依赖注入到内置规则与主动调用 事件响应器Matcher是 NoneBot2 处理消后端即时通讯NoneBot 事件响应器进阶组成结构、内置响应规则与响应器组实战NoneBot 事件响应器进阶组成结构、内置响应规则与响应器组实战 本篇技术指南聚焦 NoneBot 事件响应器Matcher的进阶用法先拆解一个事件响后端即时通讯JUnit4 Rule链多规则组合应用技巧JUnit4 Rule链多规则组合应用技巧 引言告别测试代码混乱的痛点 你是否还在为JUnit测试中多个前置条件的复杂依赖关系而头疼是否遇到过 Bef测试开发工具上一篇解决华硕笔记本合盖休眠难题GHelper合盖模式全解析下一篇CANN算子测试工具ACLNN指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考