[Plugin] astrbot_plugin_welcome_verification

[oujunhaoyueling]

插件信息

{
  "name": "astrbot_plugin_welcome_verification",
  "display_name": "入群欢迎与验证",
  "desc": "入群欢迎与验证插件，支持自定义欢迎文本、图片，支持自定义题库",
  "author": "Yueling",
  "repo": "https://github.com/oujunhaoyueling/astrbot_plugin_welcome_verification",
  "tags": [
    "入群验证",
    "入群欢迎"
  ],
  "social_link": "https://github.com/oujunhaoyueling"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_welcome_verification

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

main.py

1. 数据持久化目录获取方式不符合规范（框架适配）
   当前代码通过 CORE_DATA_DIR / context.data_dir / 插件目录 三段回退来确定数据目录，未使用 StarTools.get_data_dir()。
   这会导致插件数据目录行为与框架规范不一致，影响部署一致性和可维护性。

2. 验证状态以 user_id 作为唯一键，存在跨群串扰风险
   self.user_states、self.secondary_tasks 都用 user_id 做 key。
   当同一用户在多个群同时触发验证时，状态会互相覆盖，导致：

   • 验证题目/答案错配
   • 任务被错误取消或覆盖
   • 管理提醒发错群上下文

3. 普通验证答案校验未校验群上下文，可能被“跨群作答”绕过
   _check_answer 仅按 user_id 取状态，没有校验 event.message_obj.group_id == state["group_id"]。
   用户可在其他群发送数字消息触发当前群的验证 future，存在逻辑漏洞。

4. on_group_increase 直接 await _start_verification，长流程阻塞事件处理
   _start_verification 包含多次 wait_for(timeout)，最长可持续数分钟。
   在异步事件系统中，这类入群后长生命周期流程应独立 task 化，否则会占用当前处理链路，增加延迟和拥塞风险。

5. _warning_loop 在“仅有群主、无管理员”时会崩溃
   逻辑中 owner 通知后进入管理员循环：

   available = admins[:]  # 可能为空
   chosen = random.choice(available)  # 空列表抛 IndexError

   这会导致二级验证后续提醒任务异常终止。

6. 部分路径未清理用户状态，产生脏状态残留
   _secondary_verification 在 not owner and not admins 分支中踢人后直接返回，没有 pop user_states[user_id]。
   结果是状态字典残留（尽管 future 可能被外层 finally 移除），长期运行会积累无效状态。

7. 在持锁期间执行 await event.send(...)，增加锁竞争与潜在阻塞风险
   _check_answer 中 async with self._lock: 作用域内存在 await event.send(...)。
   网络发送期间锁被长期占用，会阻塞其他状态读写协程，放大并发延迟。

8. 二级提醒任务生命周期管理不完整，secondary_tasks 可能泄漏
   task 创建后存入 self.secondary_tasks[user_id]，但任务自然结束后没有回收该字典项。
   长期运行下会残留大量已完成任务引用，影响内存与可维护性。

9. API 参数类型不一致风险：踢人接口 user_id 直接传字符串
   _kick_user 中 user_id 可能是 str，而同文件私聊接口使用了 int(target_id)。
   若底层接口严格校验类型，可能导致踢人失败（隐蔽运行时问题）。

10. 使用 eval 生成算式结果，不符合安全与可维护性最佳实践
    _generate_question 中对字符串表达式使用 eval，虽然当前输入受控，但仍属不必要高风险习惯。
    更稳妥做法是显式运算，避免未来改动引入注入面。

11. 多处裸 except: 吞异常，降低可观测性
    例如 _send_warning_private 获取群信息和成员信息时使用裸 except。
    会掩盖真实错误根因，给线上排查带来困难。

---

代码评审团

人物一（Linus Torvalds 风格）：
“状态管理做成 user_id -> state 这种‘全局单桶’，在并发系统里就是等着互相踩。把键升级为 (group_id, user_id)，再把检查逻辑统一按这个复合键走，否则你永远在修‘偶发鬼畜 bug’。”

人物二（Steve Jobs 风格）：
“你现在的流程体验不‘丝滑’：入群事件一路 await 到几分钟后，产品感受会变差。把验证流程后台任务化、把锁粒度缩小、把异常明确记录，用户体验和运维体验都会漂亮很多。”

人物三（Tony Stark 风格）：
“random.choice([]) 这种爆炸点就像把反应堆保险丝拆了。再加上 eval 和裸 except，这套系统‘能飞’，但也‘能炸’。建议：去 eval、补空管理员分支、任务完成自动回收，顺便把脏状态清理做成统一函数。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：oujunhaoyueling/astrbot_plugin_welcome_verification
剩余触发次数：4

[oujunhaoyueling]

已处理

[astrbot-plugin-copybara]

插件信息已同步到集合仓库。
PR: AstrBotDevs/AstrBot_Plugins_Collection#401
已自动合并 PR #401

该插件已上架。
This plugin is now published.