[Plugin] astrbot_plugin_niji

[iamfromchangsha]

插件信息

{
  "name": "astrbot_plugin_niji",
  "display_name": "Niji Diary Sync",
  "desc": "自动将聊天记录同步到你的日记网站，支持每日自动上传和手动触发同步。",
  "author": "iamfromchangsha",
  "repo": "https://github.com/iamfromchangsha/astrbot_plugin_niji",
  "tags": [
    "你的日记",
    "日记保存"
  ],
  "social_link": "https://github.com/iamfromchangsha"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_niji

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

main.py

代码质量与编码规范（PEP 8 / 可读性）

• 存在明显“调试残留”与日志噪音：_do_incremental_upload()、_normalize_messages()里用 logger.info("[DEBUG] ...") 输出调试信息，且包含消息内容预览与键列表；应使用 logger.debug 并可配置开关，否则生产环境日志会被刷屏且泄露隐私。
• 死代码/无效分支：list_is_descending = False 固定常量导致上方分支永远不走，建议删除或改为真实配置项，否则增加维护成本与阅读负担。
• 类型标注不一致：_safe_get_full_contexts() 标注返回 List[Dict]，但内部把“取不到”视为 []；语义上区分“取不到/失败”和“就是空历史”会更清晰（见后面的逻辑问题）。

功能实现与逻辑正确性

• “取历史失败”与“历史为空”被混淆：_safe_get_full_contexts() 判断 if contexts:，当历史确实为空列表时会被当作“无法获取历史”并告警，造成误报；更合理的是用 None 表示失败、[] 表示确实为空，或用额外状态返回值区分。
• 增量同步算法基于“消息总数”存在天然不可靠性：用 last_message_count 做切片（all_messages[start_idx:]）假设历史列表只会追加且不会截断/重排。但在实际对话系统里常见：
  • 历史被截断（例如只保留最近 N 条）→ 会把 start_idx 变小/错位，导致漏传或重复。
  • 历史被重排（按时间/按角色过滤变化）→ “计数切片”会错位。
    更稳的做法是保存最后一条消息的唯一标识（id/timestamp/hash）并按该标识增量。
• _perform_daily_upload() 的异常归属可能错位：你先用 list(self._niji_users.items()) 构造任务，但回收异常时用 list(self._niji_users.keys())[i] 来反查用户 id；如果在并发执行期间字典发生变化（例如用户登录/解绑），索引与 key 顺序可能不一致，导致把错误记录到错误的用户。应在构造 tasks 时同步保存 user_id 列表或用 task -> user_id 映射。
• 当日“只上传一次”的逻辑可能掩盖失败重试：last_uploaded_date 一旦被写入（例如“无新消息”时也会写入），当天后续即使新增消息也可能被 last_uploaded_date == today_str 跳过（取决于你期望的策略）。现在的行为是：当天 23:50 触发后若认为“无新消息”，会把 last_uploaded_date 置为今天，之后当天新增消息需要手动 /sync force 才会进（因为 /sync 也会提示已同步）。这可能不是用户想要的“每天持续增量”。

安全漏洞与最佳实践

• 高风险：用户密码可能被同步进日记/被记录
  /login <用户名> <密码> 这条消息本身很可能会进入“聊天历史”，而你的插件目标就是“上传聊天记录到日记”。结果是：用户的明文密码极可能被上传到 nijiweb 的日记内容里（以及可能出现在本地日志预览里）。
  建议至少在格式化上传前过滤敏感指令（如以 /login 开头的消息、包含 token/cookie 的消息），或引导用户在不被记录的私聊/临时会话中绑定。
• 敏感信息落盘且明文存储：token 写入 niji_users.json 明文保存（你有 warning，但风险依旧）；在可行情况下应至少做：
  • 文件权限校验/强制收紧（类 Unix 下 chmod 600 级别）；
  • 或提供“解绑/清除凭据”命令；
  • 或把 token 与用户标识分离并加密（即便是对称加密+本机密钥也比纯明文强）。
• 日志泄露隐私：_normalize_messages() 输出“第一条消息预览”，这可能包含隐私、口令、验证码、cookie 等。生产环境中不应记录用户对话内容，至少需要脱敏/截断/仅在 debug 模式启用。

异步与资源管理（网络 I/O / 并发模型）

• 在 __init__ 中直接 asyncio.create_task(...) 有潜在运行时风险：如果插件初始化发生在“当前线程没有运行中的事件循环”的上下文（不同宿主/加载时机可能存在），create_task 会抛 RuntimeError: no running event loop。更稳妥的方式是放到框架提供的异步启动钩子（如 on_astrbot_loaded 之类）里创建后台任务，或用 asyncio.get_running_loop() 明确依赖。
• HTTP 请求缺少更细的超时与失败策略：目前是 ClientTimeout(total=30)，但未区分 connect/read；且 _periodic_upload_loop 捕获异常后固定睡 60 秒，无指数退避/熔断，可能在站点故障时形成固定频率重试。

数据持久化与框架适配性检查

• StarTools 数据目录使用存在“插件名不确定性”风险：你使用 StarTools.get_data_dir() 并 str() 化是对的，但要确认该 API 是否保证返回当前插件专属目录；否则可能与其他插件冲突（这取决于框架实现）。如果框架要求传入插件名/或从 context 推导，需要按框架规范补齐。
• 凭据存储结构缺少版本迁移/校验：NijiUser.from_dict 默认空字符串/0，数据文件被破坏或字段变更时容易产生“半初始化用户”，后续请求带空 token 发起，形成大量失败请求和日志噪音；建议加载时对 token/user_id 做基本校验，不合法就跳过或要求重新绑定。

---

代码评审团

人物一（Linus Torvalds｜毒舌务实）
你这个“增量同步”用消息数量当游标，属于典型的“看起来能跑、迟早出事”。历史一旦截断/重排就会重复或漏传。别偷懒：存一个稳定的消息标识（时间戳/ID/hash），或者直接把“今天的消息”按日期筛出来再上传，别拿计数当真相。

人物二（Guido van Rossum｜风格与可维护性洁癖）
logger.info("[DEBUG] ...") 这种写法会让人抓狂：调试信息和业务日志混在一起，而且还把用户消息预览打印出来。请用合适的日志级别、明确的开关，并把“可能包含隐私的内容”默认从日志里移除；这比再加十个功能都重要。

人物三（GLaDOS｜冷幽默的安全审计视角）
把 /login 用户名 密码 作为普通聊天消息，然后再把聊天记录上传到日记站点——这是一条非常优雅的“自助式泄密流水线”。建议：在上传前过滤敏感指令、对命令消息不入库、或提供独立的“安全绑定流程”。顺便把 token 明文落盘这件事也一起处理掉，否则你会得到一份“非常完整的事故复盘材料”。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

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

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