[Plugin] astrbot_plugin_char

[zhongyu0306]

插件信息

{
  "name": "astrbot_plugin_char",
  "display_name": "多功能生活助手",
  "desc": "多功能生活助手（char 合集），对原 char 系列多个热门插件进行整合，一套插件搞定日常查询、提醒、记账、搜索等高频需求，统一配置、统一指令、统一维护。",
  "author": "char",
  "repo": "https://github.com/zhongyu0306/MyAstrBot",
  "tags": [
    "助手",
    "股票",
    "提醒"
  ],
  "social_link": "QQ群 1071693895"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_char

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

main.py

1. LLM Tool 事件包装不完整，导致部分工具复用命令失败（功能正确性）
   _CmdWrappedEvent 只重写了 get_message_str()，但 bookkeeping_utils.py 中 record_expense/record_income 使用的是 event.message_str 属性。
   结果：tool_bookkeeping_add_expense / tool_bookkeeping_add_income 伪造指令后，实际解析到的仍可能是原始消息，出现“格式错误”或记账失败。

2. 全局共享配置 _shared_config 存在实例间覆盖风险（可维护性/潜在缺陷）
   AllCharPlugin._shared_config 是类变量，若插件在多实例/热重载场景下被重新初始化，后实例会覆盖前实例配置，FunctionTool 读取的配置可能错乱。

3. 日限额检查与计数递增分离，存在并发超限窗口（逻辑正确性）
   SmartSearchTool/WebSearchTool 先 _get_daily_counts() 再 _increment_daily_count()，并发请求下会突破每日上限（TOCTOU）。

---

bookkeeping_utils.py

1. 用户名直接拼接文件名，存在路径穿越与非法文件名风险（安全）
   _get_user_file(self, user_name) 直接使用 f"{user_name}_bookkeeping.json"。若用户名含 ../、路径分隔符或特殊字符，可能写入非预期路径或导致 I/O 异常。

2. “查账详情”展示的是旧记录而非最新记录（逻辑错误）
   records = sorted(..., reverse=True) 后使用 records[-20:]，这会取“最旧的20条”。
   delete_record 同样依赖该切片，导致“显示序号”与“用户直觉（最新）”不一致。

3. 异步环境下无并发写保护，账本数据可能丢失（潜在缺陷）
   _load_records + _save_records 是典型读改写流程，多个请求并发记账时会互相覆盖。

4. 与包装事件兼容性差（可维护性）
   使用 event.message_str 而非统一 event.get_message_str()，增加与代理事件/中间件不兼容风险（已在 main.py 的 LLM 工具触发）。

---

config_utils.py

1. ensure_flat_config 返回类型注解与实际不一致（可维护性）
   注解返回 AstrBotConfig，实际可能返回内部 _FlatConfig 代理对象，容易误导调用方并导致静态检查失效。

2. _FlatConfig 仅实现 __getattr__，缺少 get/items 等常见接口（可维护性/兼容性）
   下游若按映射风格访问（config.get(...)）会失败，配置适配行为不一致。

---

epic_utils.py

1. handle_epic_command 的 config 参数未使用（代码质量）
   这会增加误导性，建议删除未使用参数或显式保留注释说明用途。

---

jrys_utils.py

1. 持久化文件 jrys.json 写在插件代码资源目录（框架适配/可维护性）
   _load_jrys_data/_save_jrys_data 使用 self.data_dir (jrys_assets)，未使用 StarTools.get_data_dir() 的规范持久化目录；部署为只读目录时会直接失败。

2. 头像下载使用 HTTP 明文（安全）
   http://q.qlogo.cn/... 存在中间人篡改风险，建议改 HTTPS（若服务支持）。

3. jrys() 对 avatar_path is None 未做显式校验（逻辑正确性）
   asyncio.gather 后仅判断 Exception，None 会进入图片生成流程并在后续异常失败，错误定位不清晰。

4. 全局单例 _JRYS_PLUGIN 未区分上下文（潜在缺陷）
   多上下文或重载场景可能复用旧 context/config/session，引发状态污染。

---

ocr_utils.py

1. 存在 SSRF 风险（安全）
   _extract_image_from_event + _fetch_image_as_base64 会直接请求消息中的 URL，未限制协议目标、内网地址或 host 白名单，攻击者可诱导访问内网资源。

2. 缺少下载体积上限与类型校验（安全/稳定性）
   下载图片时未限制 Content-Length、未验证真实 MIME，可能被大文件拖垮内存或触发资源耗尽。

3. 每次请求均新建 aiohttp.ClientSession（性能）
   高频 OCR 时会增加连接建立开销，影响吞吐。

---

qianfan_search_utils.py

1. 每日限额存在并发超限（逻辑正确性）
   和 main.py 中工具同源问题：_get_daily_counts 与 _increment_daily_count 分离，不能保证“检查+递增”原子性。

2. 配置 API Key 的“模糊猜测”逻辑可能误取值（安全/可维护性）
   _get_qianfan_api_key 通过遍历字段并按字符串特征猜测 key，可能误把非密钥字段当密钥，导致不可预期行为与潜在泄露风险。

---

stock_utils.py

1. 数据目录 fallback 路径拼写错误（框架适配）
   _data_dir() fallback 使用 data/plugins_data/...，规范应为 data/plugin_data/...。当前会导致目录不一致、迁移困难。

2. 文件级读改写缺少并发锁（潜在缺陷）
   自选股、提醒、价格提醒均是 _load_watchlist → 修改 → _save_watchlist，并发下有覆盖丢数据风险。

3. 提醒轮询中重复拉取行情，存在不必要网络开销（性能）
   _run_reminders 对同一 session_id 的多个到时提醒会重复 await _fetch_quotes(stocks)，可合并一次请求。

---

sy_scheduler_utils.py

1. 到期提醒发送使用 asyncio.create_task 且不追踪结果（潜在缺陷）
   _run_due_reminders 中 fire-and-forget，发送失败仅在 _send_one 内记录，任务生命周期不可控，关闭时可能丢提醒或出现悬挂任务。

2. 全局 _REMINDER_CENTER 未区分上下文（可维护性/潜在缺陷）
   多插件实例/重载后可能绑定旧 context，造成消息发送到错误上下文。

---

train_utils.py

1. 在异步流程中直接执行 PIL 绘图（性能/并发）
   _do_query 中直接调用 _draw_train_image（CPU 密集），会阻塞事件循环；应下放到 asyncio.to_thread。

2. NamedTemporaryFile 句柄未显式关闭（潜在缺陷）
   _draw_train_image 中 fp = tempfile.NamedTemporaryFile(...) 后仅用 fp.name，未关闭文件对象；在部分平台可能导致句柄泄漏或文件占用问题。

---

weather_utils.py

1. 日志泄露敏感信息（安全）
   _query_weather_text/_query_weather_image 直接日志输出完整 URL，apikey 在 query string 中会被明文写入日志。

2. 临时图片文件在 yield event.image_result 后立即删除，存在发送竞态（逻辑/稳定性）
   若框架在后续阶段异步读取文件，finally 中 os.unlink 可能导致“文件不存在”发送失败（train_utils 也有同类风险）。

3. 每次查询都新建 aiohttp.ClientSession（性能）
   高频调用下连接复用不足，增加开销。

---

代码评审团

人物一：Linus Torvalds（毒舌工程派）
“你这套功能很全，但有几处是‘看起来能跑，实际上会咬人’：最典型是记账 LLM 工具伪造消息却没覆盖 message_str 属性。接口契约不统一就是技术债炸弹。先把 event 访问统一成 get_message_str()，别让这种隐式差异继续扩散。”

人物二：Steve Jobs（产品体验导向）
“用户不会关心你用什么框架，他们只会看到‘怎么有时成功有时失败’。比如天气 API key 被打进日志、图片临时文件可能被提前删，这些是会直接损害信任感的细节。把‘稳定且可信’当产品功能去做，不只是技术修补。”

人物三：Geralt of Rivia（冷静实战派）
“怪物名单很清楚：路径穿越、SSRF、并发覆盖。先银剑砍安全（文件名净化、URL 限制），再钢剑砍一致性（计数原子化、文件锁）。你已经有不错的模块化了，下一步是把边界收紧，不然夜里总会出警。”

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

---

🔍 审核摘要

统计信息

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

main.py
bookkeeping_utils.py
config_utils.py
epic_utils.py
jrys_utils.py
ocr_utils.py
qianfan_search_utils.py
stock_utils.py
sy_scheduler_utils.py
train_utils.py
weather_utils.py

---

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