[Plugin] astrbot_plugin_at_check

[Foolllll-J]

插件信息

{
  "name": "astrbot_plugin_at_check",
  "display_name": "谁艾特我",
  "desc": "记录群聊中最近@你的消息，支持单独@的上下文获取。",
  "author": "Foolllll",
  "repo": "https://github.com/Foolllll-J/astrbot_plugin_at_check",
  "tags": [
    "工具"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_at_check

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

main.py

1. 代码质量与编码规范

• 混合路径处理方式: 代码中通过 StarTools.get_data_dir() 获取的 data_dir 是一个 pathlib.Path 对象，但后续却使用了 os.path.join 和 os.makedirs 进行处理。虽然 Python 3.10 中 os 模块函数通常支持 PathLike 对象，但这种混合使用 pathlib 对象和 os.path 字符串操作的风格不够 pythonic。建议直接利用 Path 对象的特性，例如 self.db_file = data_dir / "at_records.db"。
• SQLite 连接管理: 代码在 _db_write_records、_db_fetch_records 等方法中频繁创建和关闭数据库连接 (with sqlite3.connect(...))。虽然这保证了线程安全，但在高频写入时会带来不必要的 I/O 开销。
• 导入规范: 导入语句清晰，遵循了 PEP 8 的基本排序和分组建议。

2. 功能实现与逻辑正确性

• 异步数据库操作: 开发者正确地意识到了 SQLite 操作是阻塞的，并使用了 self.loop.run_in_executor(None, ...) 将数据库操作放入线程池执行，避免了阻塞主事件循环，这是一个很好的实践。
• 消息解析逻辑: _components_to_segments 和 record_at_message 中对于消息组件的解析逻辑较为严谨，考虑了 At、Face、Image 等多种类型。
• Napcat/OneBot 依赖: 代码中直接调用了 get_group_msg_history 和 send_group_forward_msg，这些是 OneBot 11 (Napcat) 特有的 API。代码逻辑上是正确的，但这意味着该插件强依赖于特定的协议端实现。

3. 安全漏洞与最佳实践

• SQL 注入防护: 所有的 SQL 操作都使用了参数化查询（如 VALUES (?, ?, ...)），有效地防止了 SQL 注入攻击。这是非常关键的安全实践。
• 数据目录获取: 正确使用了 StarTools.get_data_dir 获取插件数据目录，避免了硬编码路径。

4. 可维护性与可读性

• 类结构清晰: AtRecorderNapcat 类结构合理，辅助方法（如 _is_reply_component）封装得当。
• 配置处理: 对 config 的读取有默认值处理和类型转换，增加了代码的健壮性。

5. 潜在缺陷或问题

• 事件循环获取时机: 在 __init__ 中调用 asyncio.get_running_loop()。虽然在 AstrBot 的加载机制下通常是在异步上下文中初始化的，但如果插件在非运行循环的上下文中实例化，这行代码会抛出 RuntimeError。
• 白名单逻辑: group_whitelist 默认为空列表 []。在 record_at_message 中，如果 self.group_whitelist 为空（即 if self.group_whitelist: 为假），则跳过白名单检查，意味着所有群都会记录。这通常符合预期，但需要确认是否符合插件设计的默认行为（即默认全开启）。
• run_in_executor 与共享状态: 虽然使用了 run_in_executor，但 _db_cleanup_records 和 _db_write_records 可能会并发运行（尽管 SQLite 自身有锁）。在高并发下可能会遇到 database is locked 错误，建议在应用层增加简单的锁或队列机制。

6. AstrBot 框架适应性检查

• 日志记录: 正确使用了 from astrbot.api import logger。
• 插件注册: 正确继承了 Star 类，且使用了 @register 装饰器（虽然新版推荐直接继承，但旧版语法兼容）。
• Filter 导入: 正确使用了 from astrbot.api.event import filter。
• 事件参数: 监听器方法 record_at_message 和 who_at_me 都正确包含了 event: AstrMessageEvent 参数。

---

代码评审团

Linus Torvalds:
“这代码里的 os.path.join(Path_object, string) 看着真让我难受。既然你都拿到了一个 Path 对象，为什么不用 / 运算符？这就好比给了你一把电锯，你却非要把它当手动锯子用。不过，我也得承认，你居然知道用 run_in_executor 来处理 SQLite 那些慢得要死的阻塞操作，这在 Python 脚本小子里算是难得的清醒。至少你没有阻塞整个事件循环，这点通过了。”

Steve Jobs:
“不仅要能用，还要优雅。看看这个 who_at_me 功能，用户问‘谁艾特我’，你返回一个精美的合并转发消息，还原了上下文，这是一种很好的用户体验。但是，你对 Napcat 的依赖太重了。如果用户用的是其他协议端怎么办？真正的艺术是通用的。还有，数据库连接每次都重新打开又关闭，这就像每次打开电灯都要重新接线一样，不够高效，不够简洁。”

Bertram Gilfoyle (Silicon Valley):
“你的数据结构设计还可以。用 JSON 字符串存储 raw_message 和 context_msg_ids 在 SQLite 这种轻量级数据库里是合理的权衡。但是，_single_at_watchers 这个字典在内存里随着时间推移可能会膨胀，虽然你写了超时清理逻辑，但依赖于下一次消息触发清理（Lazy Expiration）总是有风险的。如果机器人长时间没人说话，那些过期的 watcher 就会像僵尸一样占着内存。写个定时任务去主动清理它，别偷懒。”

---

Disclaimer

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

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

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