[Plugin] astrbot_plugin_pseudo_people_chat_actively

[HeartEase1]

插件信息

{
  "name": "astrbot_plugin_pseudo_people_chat_actively",
  "display_name": "伪人主动回复",
  "desc": "基于人设与对话上下文的智能主动回复插件，默认适配QQ(aiocqhttp)平台，强制北京时间，支持定时问候、未活跃触达、日常事件分享等全场景主动聊天能力",
  "author": "Heart Ease1",
  "repo": "https://github.com/HeartEase1/astrbot_plugin_Pseudo_people_chat_actively",
  "tags": ["主动回复","拟人"],
  "social_link": "https://github.com/HeartEase1"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_pseudo_people_chat_actively

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

main.py

• 代码质量与编码规范：
  • 配置项散落与硬编码：虽然在 _validate_config 中对部分关键配置进行了校验和回填，但代码中其他多处地方仍充斥着类似 self.config.get("enable_plugin", True)、self.config.get("enable_inactive_1d_touch", True) 等带硬编码默认值的调用。建议在 __init__ 或专用的配置加载环节将所有必需的默认值合并，确保业务逻辑代码更清爽，减少不一致风险。
• 潜在缺陷或问题：
  • 任务被垃圾回收的风险：在 __init__ 中使用了 asyncio.create_task(self._async_init())。在 Python 3.10+ 中，如果未能保留对 Task 对象的强引用，它可能会在执行完成前被垃圾回收器意外终止。建议修改为 self._init_task = asyncio.create_task(self._async_init())。
  • 大规模任务调度的性能瓶颈：在 _generate_daily_events 和 _scan_inactive_users 中，使用了 await asyncio.gather(*[process_user(user_id) for user_id in users], return_exceptions=True)。当系统用户量激增时，这种方式会一次性实例化并调度所有用户的协程任务，即使内部有 self._llm_semaphore 进行限制，大量的协程挂起依然会消耗过多的内存并给事件循环带来不必要的压力。建议将列表切片进行分批执行，或者使用有界队列的 Worker 池模型。

database.py

• 安全漏洞与最佳实践：
  • 线程安全与数据库损坏风险（高危）：代码中广泛使用了 asyncio.to_thread 来包装底层的 sqlite3 查询，并且在 __init__ 中将连接设置为 check_same_thread=False 以绕过抛错机制。然而，Python 标准库中的 sqlite3.Connection 在默认情况下并不是真正的线程安全的。你的代码仅对少部分写操作加了 self._write_lock = asyncio.Lock()，而对众多读操作（如 get_pending_tasks）未使用锁。在多线程异步并发环境下，多个线程同时读/写同一个 sqlite3.Connection 会引发严重的并发安全问题，甚至导致内部状态崩溃或触发 database is locked。
  • 优化建议：在纯异步环境强烈建议使用 aiosqlite 替代同步的 sqlite3 + to_thread 方案；如果必须使用当前方案，请针对所有读写数据库的方法建立全局的异步锁或在单个专用的线程/队列中统一处理以保障线程安全。

scheduler.py

• 代码质量与逻辑正确性：
  • 本文件职责单一，封装了 apscheduler 且逻辑结构清晰，对跨天时段判断和最小时间间隙调整（check_task_interval）的处理符合预期。未发现明显的逻辑缺陷或安全漏洞，代码保持了较好的可读性和可维护性。

---

代码评审团

Linus Torvalds：
"我就直说了吧。你在 database.py 里用 asyncio.to_thread 把同一个 sqlite3.Connection 对象抛给了多线程环境并发乱跑？而且读操作还不加锁？你以为写了个 check_same_thread=False 就可以无视 SQLite 在 Python 里的非线程安全本质了？这就像是在高速公路上闭着眼睛开车！如果不想你的数据库在并发访问时变成一坨不可燃垃圾，立马去换成 aiosqlite，或者老老实实地加全局的异步锁限制并发访问！另外，你在 main.py 里的 asyncio.create_task() 连个强引用都不留，等着 Python 的垃圾回收器把它无声无息地收走吗？加个 self._init_task = ... 会死吗？"

乔布斯：
"一款真正伟大的产品，它的内部代码也应当像其外部一样优雅。你在 main.py 里的配置获取逻辑不够‘极简’。我看到了太多的 self.config.get(...) 散落在各个角落，带着丑陋的硬编码默认值。这很不优雅！为什么不在 _validate_config 里，把所有默认值都完美地初始化到你的配置字典里？让其他模块去享受一个纯净、可靠的 self.config['key'] 吧。记住，不要把复杂留给你的业务逻辑，要在源头就把它们规整好。"

Rick (瑞克和莫蒂)：
"Wubba Lubba Dub Dub！听着，莫蒂，这家伙在 _generate_daily_events 和扫描未活跃用户的时候，居然把成千上万个用户的 task 一把 gather 丢进了事件循环里！虽然他聪明地在里面加了个 Semaphore(5)，但这只限制了 LLM 并发，好几千个挂起的协程对象就像培养皿里的外星异形卵一样挤爆了你的内存空间！听我的，聪明人会写个有界限的 Worker 队列，或者用 itertools.islice 乖乖分批次去 gather，别让你的事件循环因为处理这些僵尸协程而发出痛苦的尖叫，好吗？"

---

🔍 审核摘要

统计信息

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

main.py
database.py
scheduler.py

---

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

当前仓库：HeartEase1/astrbot_plugin_Pseudo_people_chat_actively
剩余触发次数：1