[Plugin] astrbot_plugin_banpass

[oculr]

插件信息

{
  "name": "astrbot_plugin_banpass",
  "display_name": "BanPass（Ban黑名单插件）",
  "desc": "黑名单插件，支持临时解禁，支持全局封禁、临时解禁",
  "author": "oculr",
  "repo": "https://github.com/oculr/astrbot_plugin_banpass",
  "tags": [
    "ban",
    "封禁",
    "黑名单"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_banpass

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

main.py

1. 指令文档与实现不一致（功能正确性）
   extract_args() 仅从 At 组件提取目标用户，不支持文档中声明的 UID（QQ号） 纯文本形式。

   • 影响：/ban 123456 这类写法会被识别为“没有指定目标用户”。

2. 参数解析丢失信息（功能正确性）
   extract_args() 中 reason 仅取 split[1]，多词理由会被截断；且文档提到的 [UMO] 参数完全未解析。

   • 影响：实际行为与帮助文本不一致，管理员输入复杂理由会被 silently 截断。

3. 潜在 ID 类型不一致导致封禁失效（逻辑边界）
   目标用户在封禁写入时被转为 str，但过滤时 event.get_sender_id() 未显式转为 str。如果框架返回的是 int，会出现查不到记录。

   • 影响：已封禁用户可能绕过封禁检查。

4. 封禁过滤存在绕过口子（安全/逻辑）
   filter_banned_users() 里用 if "bancheck" in event.message_str.strip(): return 做豁免，只要消息中包含该子串就跳过封禁拦截。

   • 影响：被封禁用户可通过构造包含 bancheck 的任意消息绕过过滤器。

5. 查询结果语义不准确（功能正确性）
   ban_check() 中只要有 bp 记录且 not is_baned() 就显示 passed_user，即便 pass_ 和 ban_ 都已过期。

   • 影响：过期记录会被误展示为“已解限”，误导管理员判断。

6. 可维护性问题：四个命令处理流程高度重复
   ban/ban-all/pass/pass-all 大量重复参数解析、错误处理、目标校验、消息拼接逻辑。

   • 影响：后续修复/改规则时容易出现漏改和行为漂移。

---

banpass_manager.py

1. 异步场景下的竞态风险（潜在缺陷）
   update() 是典型的 read-modify-write：先 get、再修改、再写回；无任何并发保护。

   • 影响：并发执行多个封禁/解限操作时可能发生“最后写入覆盖”，导致记录丢失。

2. 空值鲁棒性不足（潜在运行时异常）
   BanPass.is_baned() 直接访问 self.pass_.get_expire_at() 和 self.ban_.get_expire_at()，若历史脏数据/异常数据导致任一字段为 None，会抛 AttributeError。

   • 影响：查询/拦截流程可能因单条坏数据中断。

3. 命名拼写错误影响可读性与一致性（代码质量）
   多处使用 is_baned（应为 is_banned）。

   • 影响：接口语义不专业，后续维护和检索成本增加。

4. 全局更新复杂度偏高（性能/可维护性）
   is_global=True 时会遍历并重写用户下所有 UMO 记录。随着 UMO 数量增长，单次操作成本线性增加。

   • 影响：大量历史会话时管理命令性能退化明显。

---

strings.py

未发现需要报告的问题。

---

time_utils.py

未发现需要报告的问题。

---

代码评审团

人物一：Linus Torvalds（硬核直给派）
你这段封禁过滤里 if "bancheck" in message 真是“把后门写成了功能”。规则系统最怕这种子串豁免，应该做严格命令匹配，不是模糊包含。还有 is_baned 这种拼写，后期 grep 和协作会让人抓狂。

人物二：Steve Jobs（体验洁癖派）
文档说支持 UID、支持理由，结果实现里 UID 不支持、多词理由被截断。用户“看到的承诺”和“实际体验”不一致，是最伤产品信任的。接口设计要“说到做到”，否则再好的功能也像半成品。

人物三：Ada Lovelace（结构与长期主义）
ban/pass 四个命令流程高度重复，今天看着能跑，明天改一条规则就会出现行为分叉。把“参数解析 + 校验 + 状态更新 + 回包”抽成统一管线，才能保证策略一致性，并降低未来引入回归 bug 的概率。

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

---

🔍 审核摘要

统计信息

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

main.py
banpass_manager.py
strings.py
time_utils.py

---

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

当前仓库：oculr/astrbot_plugin_banpass
剩余触发次数：4