[Plugin] astrbot_plugin_sentinel

[Foolllll-J]

插件信息

{
  "name": "astrbot_plugin_sentinel",
  "display_name": "QQ 群哨兵",
  "desc": "实时监控群聊消息，通过关键词或正则表达式进行识别，并自动执行撤回、禁言以及踢出等操作。",
  "author": "Foolllll",
  "repo": "https://github.com/Foolllll-J/astrbot_plugin_sentinel",
  "tags": [
    "群管理",
    "禁言",
    "撤回",
    "踢人"
  ]
}

插件检查清单

• 我的插件经过完整的测试
• 我的插件不包含恶意代码
• 我已阅读并同意遵守该项目的 行为准则。

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sentinel

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

代码质量与编码规范

• 未使用的导入：MessageEventResult、MessageType 在文件中未被使用，建议删除以降低噪音与误导。
• 未使用的方法：_extract_text_from_json() 定义后从未被调用；而 on_message() 里却通过 str(msg_seg) 拼接“json”相关内容，导致“写了但没用”的维护负担。
• 重复的类型/列表转换：多处出现 user_id in [str(u) for u in whitelist]、group_id not in [str(g) for g in target_groups] 这类每次消息都重新构造列表的写法，可读性一般且有额外开销（尤其白名单/规则多时更明显）。

功能实现与逻辑正确性

• JSON 文本提取逻辑实际无效/偏离意图：on_message() 发现包含 “json” 的消息段后，仅将 seg_str = str(msg_seg) 追加到 message_str，而不是解析其中 JSON 并提取文本；这会导致：
  • 关键词/正则可能匹配不到 JSON 内真正的文本字段（漏判）。
  • 反而可能匹配到序列化后的结构/字段名（误判）。
  • 既然已有 _extract_text_from_json()，却未接入流程，逻辑不一致。
• delete_msg 参数类型风险：message_id = event.message_obj.message_id 直接传给 call_action("delete_msg", message_id=message_id)，但常见 CQHTTP 接口期望 message_id 为整数；若这里是字符串或其他类型，可能导致撤回失败（建议显式 int() 并做好异常分支）。
• 管理员角色字符串兼容性隐患：代码用 role == 'admin' 判断管理员，但不同适配器/上游实现中管理员字段可能为 'administrator' 或其他枚举值；在这种情况下 ignore_admin 规则会失效（造成误处理管理员消息）。
• get_kv_data() 返回类型不确定导致的加法风险：current_hits = await self.get_kv_data(kv_key, 0) 后直接 current_hits += 1，若 KV 存的是字符串（例如 "1"）会触发类型错误；建议读取后显式转换并兜底。
• 命中计数的并发竞态：在高并发下同一用户短时间多次触发规则，get_kv_data -> +1 -> put_kv_data 不是原子操作，可能丢计数或重复踢人边界行为（需要原子自增或加锁/事务式操作，视框架 KV 能力而定）。
• 命中计数无过期策略：hits:{group}:{user}:{rule} 永久累积，长期运行会导致 KV 体积膨胀；并且“踢人阈值”可能本意是“短期内累计”，但目前是“永久累计”。

安全漏洞与最佳实践

• 配置驱动正则存在 ReDoS 风险：对每条消息对每个关键字 re.search(kw, message_str)，若配置里出现灾难性回溯正则（或被误配），可能造成 CPU 飙升、事件循环卡顿（异步环境下尤为致命）。Python re 默认没有超时机制，建议对正则来源、复杂度和执行策略做约束（例如：预编译、限制规则数量/长度、避免危险模式，或引入可控的匹配策略）。
• 异常吞噬导致可观测性差：
  • _extract_text_from_json() 中 except Exception: pass 会吞掉所有解析异常，后续排障困难（至少应 debug 级别记录异常原因或对特定异常分类处理）。
  • 多处 except Exception as e: 仅笼统报错，没有包含必要上下文（例如规则 index、触发关键词等），定位复杂规则时成本高。

可维护性与可读性

• 规则匹配逻辑可读性与扩展性一般：on_message() 内部循环较长且混合了：白名单/黑名单过滤、消息拼装、规则过滤、关键词/正则匹配、执行动作；建议拆分成更小的纯函数/步骤（例如：should_skip_user/group、build_search_text、match_rule），否则后续新增动作或消息类型会变得脆弱。
• 对消息段类型的判断过于粗糙：用 "json" in seg_str.lower() 判断“包含 json 段”，依赖 __str__ 输出格式，稳定性差；一旦消息段字符串表示变化就会失效或误判。

潜在缺陷/性能问题（异步环境）

• 规则量增大时的 CPU 压力：对每条群消息按规则数 × 关键词数进行 re.search，且未预编译正则；规则多、群消息频繁时会明显增大 CPU 消耗并影响事件循环调度延迟。
• 无必要的字符串拼接与列表构造：频繁构造 message_str += " " + seg_str 与 [...] for ... 列表会放大开销，尤其在大群高频消息场景下更明显。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你这套“配置里随便写正则，然后对每条消息挨个 re.search”的设计，基本是在邀请别人（或误配）用一个灾难性回溯把事件循环打成单线程烤箱。至少把正则预编译、限制规则规模，并想清楚“正则是武器，不是玩具”，不然性能和稳定性迟早背刺你。

人物二（Guido van Rossum，偏 Pythonic 的整洁派）：
现在 on_message() 把过滤、提取、匹配、执行全塞在一起，读起来像一条长长的管道但又没分段。更糟的是你写了 _extract_text_from_json() 却完全没用，属于“未来维护者陷阱”。把“构造可搜索文本”“匹配规则”“执行动作”拆成小函数，类型转换（int/str）也集中处理，会更 Pythonic、也更不容易出边界 bug。

人物三（Grace Hopper，偏可观测性与排障）：
我不怕 bug，我怕的是你把异常吞了还不给线索：except: pass 会让你在生产上像盲飞。还有 KV 命中计数没有过期、也非原子递增，时间久了既难解释“为什么突然被踢”，也难复现问题。把异常记录清楚（带 rule_index、群号、用户、命中的 kw），再给计数一个合理的窗口/TTL，你未来排障会少很多“凭感觉”。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。

[Foolllll-J]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sentinel

您好！我已经对你提交的插件代码进行了初步自动化审核，作为初步参考:

main.py

代码质量与编码规范

• 未使用的导入较多：json, List/Set/Optional/Dict/Any 在文件中未使用，会增加维护噪音，也可能误导读者以为存在相关逻辑。
• PEP 8 细节：
  • 多处超长行（如 @register(...) 一行、logger.error(...) 等），可读性较差。
  • _update_cache / execute_actions 内部逻辑偏长且层级深，建议拆分成更小的私有方法（例如：解析禁言时长、匹配规则、计数与踢人等），否则后期加动作/加字段会迅速失控。
• 命名与字段结构：
  • 运行时向 rule copy 塞入 _compiled_patterns、_groups_set、_user_whitelist_set 等“内部缓存字段”，会让“配置对象”和“运行态对象”耦合；若后续需要序列化/热更新配置，容易产生混乱（例如把 _compiled_patterns 意外写回配置）。

功能实现与逻辑正确性

• 配置缓存不会自动更新：_update_cache() 只在 __init__ 调用一次；如果框架支持热更新/重载配置，插件不会重新编译规则与集合缓存，导致规则更新不生效或行为不一致。
• “正则编译失败”的降级策略可能造成误杀：
  • 当前逻辑：正则编译失败 → compiled_patterns.append(kw) → 后续走“子串包含”匹配。
  • 问题：正则写错时不应默默变成“包含匹配”，这会改变语义并可能大幅扩大命中范围（例如原本想写 \bfoo\b，写错后变成只要出现 \bfoo\b 这串字符就命中，或反过来变成对普通词片段的误命中）。
• 对消息内容的提取方式可能不可靠：
  • event.message_str 通常包含 CQ 码/序列化后的片段；再把 msg_seg 做 str(msg_seg) 并仅用 "json" in seg_str.lower() 来决定是否拼接，属于非常脆弱的启发式策略：
    • 可能漏掉真正的 JSON 段（不包含“json”字样但实际是 JSON）。
    • 可能误把无关段拼进去导致误命中。
  • 若目的是检测结构化消息（如 JSON 卡片/转发等），应优先使用框架提供的结构化字段/segment 类型判断，而不是字符串包含。
• delete_msg 参数类型可能不一致：
  • message_id = event.message_obj.message_id 未强制转换为 int；而后续 set_group_ban/set_group_kick 都显式 int(...)。如果 adapter 对 delete_msg 的 message_id 要求严格类型，可能导致撤回失败（并进入异常分支）。
• 禁言时长区间解析缺少边界保护：
  • 允许 "start-end"，但未处理 start > end、负数、过大值等情况；random.randint(start, end) 在 start>end 时会直接抛异常（当前会被 ValueError 之外的异常漏出，因为这里只捕获了 ValueError）。
  • "1-2-3" 这类格式会 split("-") 得到 3 段并触发 ValueError？实际是 map(int, ...) 会报 ValueError 或解包报 ValueError/ValueError 之外的错误（解包是 ValueError 吗？是 ValueError: too many values to unpack，能被捕获，但错误提示会不够直观）。
• 踢人计数存在并发竞争条件：
  • 命中次数逻辑是“读-改-写”：get_kv_data → current_hits += 1 → put_kv_data。在高并发/同一用户短时间多条消息触发时，可能发生丢计数（race condition），导致阈值触发不准确。
  • 更稳妥的方式是使用支持原子自增的存储接口（若框架 KV 支持），或用锁按 (group_id,user_id,rule_index) 粒度保护。
• 计数数据缺少生命周期管理：
  • hits:{group}:{user}:{rule} 没有 TTL/过期策略；只要没达到 kick_threshold，计数会永久累积，可能导致“隔了很久又触发一次就被踢”，也会造成 KV 数据无限增长。
• 动作顺序与异常传播不一致：
  • event.send(...)（回复、踢人消息）未做异常捕获；当发送失败时可能打断后续逻辑（例如计数清理、后续动作），导致状态不一致。
• terminate 空实现：
  • 若框架期望在 terminate 做清理（取消任务、释放资源、刷新缓存等），空实现会让读者误以为缺少必要清理逻辑；至少应注释说明“无需清理”。

安全漏洞与最佳实践

• 配置驱动的正则存在 ReDoS 风险：
  • rule["keywords"] 直接 re.compile 并对每条消息做 pattern.search(message_to_check)；如果规则来自不可信来源（或可被群管理以外的人编辑），恶意正则（灾难性回溯）可导致 CPU 飙升，形成拒绝服务。
  • 即便规则可信，消息内容可能很长（尤其拼接了疑似 JSON 段），也会放大 ReDoS 影响面。
• 日志可能泄露敏感信息：
  • 撤回日志记录了 group_id/user_id/message_id。如果日志可被非预期人员访问（或上传到外部），可能造成隐私泄露。至少应提供配置开关或降低粒度（例如仅 debug 记录 message_id）。

可维护性与可读性

• 单个方法职责过多：
  • on_message 同时做：权限绕过、内容抽取、规则过滤、逐规则逐 pattern 匹配、命中后触发动作；后续新增“警告次数衰减/不同动作组合/不同消息段提取策略”会很难改且易引入回归。
• 魔法字符串过多且缺少集中定义：
  • 如角色 'owner'/'admin'/'member'、KV key 前缀 hits:、API action 名称 "delete_msg" / "set_group_ban" / "set_group_kick" 等，建议集中常量化，降低拼写错误风险与后续修改成本。

框架适应性检查（与题目要求对照）

• @register 使用注意：
  • 代码使用了 @register(...)，而题目说明在 v3.5.20 之后该装饰器已废弃。若运行环境确实较新，可能存在未来兼容性/加载行为差异风险（建议至少在代码注释中说明对目标 AstrBot 版本的假设）。
• filter 导入符合要求：已使用 from astrbot.api.event import filter，但也带来与内置 filter 同名覆盖；当前符合框架规范，但在本文件内会降低读者对内置 filter() 的可用性预期（属于可读性问题）。
• 未使用 StarTools.get_data_dir 的持久化问题：
  • 当前代码未进行文件持久化，因此无需强制使用 StarTools.get_data_dir()；但你确实在用 KV 做“累计命中”，其“永久累积”带来的存储膨胀问题（见上）仍需处理（TTL/定期清理/按周期衰减）。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你把“配置结构”和“运行时缓存”搅成一锅粥（rule.copy() 后塞 _compiled_patterns 这种字段），短期省事，长期就是维护地狱。把缓存放到独立的数据结构里，别污染配置对象；否则你迟早会在热更新/序列化/调试时被反噬。

人物二（Grace Hopper，偏工程与可运维性）：
hits 计数没有 TTL，也没有并发保护，这就是典型“今天能跑、明天炸锅”的运维隐患：数据越积越多、阈值触发不符合直觉、并发下还会丢计数。把“计数周期”（例如按天/按小时衰减）和“原子自增”想清楚，系统才可控。

人物三（Donald Knuth，强调正确性与复杂度）：
你允许任意正则对每条消息做 search，还可能把疑似 JSON 的长文本拼进去；这在复杂度上没有上界保障，ReDoS 不是“可能”，是迟早。要么限制正则能力（白名单语法/长度/超时策略），要么把匹配策略设计成可证明的线性时间（例如 Aho-Corasick 用于关键词、结构化字段精确匹配用于 JSON）。

Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。如果给出的建议无关痛痒请忽略。

---

🔍 审核摘要

统计信息

• 仓库文件总数: 1 个 Python 文件
• 已选择审核文件: 1 / 1
  已发送至 AI 审核的文件清单

main.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。