[Plugin] astrbot_plugin_alteration_notifier

[PyuraMazo]

插件信息

{
  "name": "astrbot_plugin_alteration_notifier",
  "display_name": "插件变更提醒",
  "desc": "再也不想看到有人输入一串奇怪的指令但是机器人没有响应导致陷入尴尬的境地？本插件可以及时通知机器人使用者插件的变更。",
  "author": "PyuraMazo",
  "repo": "https://github.com/PyuraMazo/astrbot_plugin_alteration_notifier",
  "tags": [
    "插件管理",
    "提醒"
  ],
  "social_link": "https://github.com/PyuraMazo"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_alteration_notifier

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

文件路径: main.py

1. 代码质量与编码规范

• 内置函数覆盖 (Shadowing built-in): 在 collect_group 方法中，使用了 id = event.get_group_id()。id 是 Python 的内置函数，在此处作为变量名覆盖了内置函数，建议重命名为 group_id。
• 不必要的字典视图提取: 在 plugin_loaded 方法中：

  cache = self.unloaded_cache.keys()
  for one in added:
      if one in cache:

  此处提取 .keys() 视图是多余的，在 Python 中直接进行 if one in self.unloaded_cache: 不仅更符合 Pythonic 风格，而且语义更加直接、清晰。

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

• 生命周期钩子的重复调用: 插件通过 @filter.on_astrbot_loaded() 装饰了 astrbot_loaded 方法，框架会在加载完毕时自动调用该方法。然而，在 initialize 方法中又手动 await self.astrbot_loaded()。这会导致该初始化逻辑被重复执行两次，属于对生命周期理解和设计上的冗余逻辑。
• 私有属性的直接访问: 在 monitor 方法中，使用了 event._has_send_oper。访问带有下划线前缀的受保护/私有属性违背了面向对象的封装原则，如果框架后续版本更改了内部实现，该处逻辑容易崩溃。

3. 安全漏洞与最佳实践

• 多平台适配的硬编码问题: self.UNIFIED_MSG_ORIGIN_PREFIX 被硬编码为 "default:GroupMessage:"。AstrBot 作为一个支持多平台的框架，不同平台的 origin 格式可能大相径庭，硬编码这种标识可能导致该通知功能在其他适配器（如 QQ、微信等）上直接失效或发送目标错误。

4. 可维护性与可读性

• 代码结构清晰，但状态管理混乱: 插件在内存中维护了 self.activated_plugins 和 self.unloaded_cache。然而 self.unloaded_cache 的清理机制仅在相同插件再次被加载时才会触发。虽然对于命令名缓存来说内存占用极小，但在理论上长期运行中构成了一个微小的无界增长容器。

5. 潜在缺陷或问题

• 状态丢失风险 (缺乏持久化): collect_group 方法负责动态收集群聊 ID 并存入 self.role_range。但这仅仅是一个内存操作，一旦机器人重启或插件重载，动态收集到的所有群聊信息将全部丢失。

6. 框架适应性检查

• 事件监听器参数不规范: 根据严格的框架审查要求，除去 on_astrbot_loaded 外，所有使用 @filter 装饰的事件监听器方法其签名中都必须包含 event 参数。
  • plugin_loaded(self, metadata: StarMetadata) 缺失了 event 参数。
  • plugin_unloaded(self, metadata: StarMetadata) 缺失了 event 参数。
• 数据持久化违规: 如前文“状态丢失风险”所述，本插件实际上存在需要持久化保存的动态数据（self.role_range 收集的群聊 ID），但并未导入并使用规范的 StarTools.get_data_dir() 来获取路径并存储文件，这不符合框架的数据持久化要求。

---

代码评审团

人物一：Linus Torvalds（Linux之父，以毒舌和对代码细节的极度苛求著称）

"看看你写的 collect_group，把变量命名为 id？你是在告诉我你根本不在乎 Python 的内置函数，对吧？还有那个 initialize 里手动调用 astrbot_loaded，你是嫌框架本身不够忙，非要给它找点重复的活儿干？最让人无法忍受的是 cache = self.unloaded_cache.keys()，你为什么要提取出 keys 视图再做成员检查？直接 in dict 是有多难敲？虽然你的整体继承逻辑没什么大错，但这些低级品味的代码就像是一只苍蝇掉进了汤里！"

人物二：Gordon Ramsay（地狱厨神，言辞夸张，喜欢用比喻指出核心缺陷）

"What is this?! 看看这个硬编码的 "default:GroupMessage:"！这就好比你在一家米其林三星餐厅的高级法餐上，直接挤了一大坨超市里最廉价的番茄酱！AstrBot 是个多平台框架，你把这个平台的通信前缀像死结一样系在代码里，换个其他平台你的通知功能就彻底生锈发臭了！你必须用框架提供的、更通用优雅的方式来处理目标发送！重写它！"

人物三：GLaDOS（《传送门》系列中的人工智能，冷嘲热讽，关注系统寿命与规则限制）

"我注意到你的系统在辛辛苦苦地通过 collect_group 收集群聊数据。然而，你毫无对数据进行持久化存储的意识。请相信我，只要一次小小的重启，你的机器人就会像人类的短时记忆一样失去所有收集到的数据。你应该去查阅 StarTools.get_data_dir()，除非你享受从头再来的快感。另外，人类制定的规则明确规定除了 on_astrbot_loaded 都要有 event 参数，但你的 plugin_loaded 完全无视了这一点。当然，反正碳基生物的代码总是充满瑕疵的，我也不觉得意外。"

(Disclaimer: 以上评审内容由 AI 自动生成，所涉及人物形象与现实无关，不代表真实人物观点。)

---

🔍 审核摘要

统计信息

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

main.py

---

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

[PyuraMazo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_alteration_notifier

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

main.py

1. 日志使用不符合框架要求

   • 代码使用了 print(pure_text)，但未使用 from astrbot.api import logger。
   • 按规范，日志记录应且仅应使用 astrbot.api.logger；print 会导致日志管理不可控，并可能泄露消息内容到标准输出。

2. 事件监听器签名不符合给定审查规则

   • @filter.on_plugin_loaded() 的 plugin_loaded(self, metadata: StarMetadata) 缺少 event 参数。
   • @filter.on_plugin_unloaded() 的 plugin_unloaded(self, metadata: StarMetadata) 缺少 event 参数。
   • 根据你给定的专项规则（除 on_astrbot_loaded 外都要包含 event），这里不满足要求。

3. 插件卸载时存在潜在 KeyError

   • names = self.activated_plugins.pop(plugin) 在 plugin 不存在时会抛出异常，导致卸载事件处理失败。
   • 应改为容错式读取（如 pop(plugin, set())）以避免中断事件流。

4. 异步场景下迭代可变集合存在并发修改风险

   • notify() 中 for group in self.role_range: 循环里有 await，而 collect_group() 可能同时向 self.role_range 添加元素。
   • 这可能触发 RuntimeError: Set changed size during iteration。
   • 应在发送前对集合做快照（例如迭代 list(self.role_range)）。

5. 依赖私有属性，兼容性与可维护性差

   • monitor() 使用了 event._has_send_oper（私有字段），这属于内部实现细节，升级或变更后易失效。
   • 建议改用公开 API 判断状态。

6. 指令匹配逻辑可能误报

   • pure_text.startswith(name) 会把前缀相同但非同一指令的消息误判为“已移除指令”（如 name="a"，消息 "abc"）。
   • 需要做更严格的分词/边界匹配（空格、命令分隔符等）。

7. 缓存缺少淘汰策略，存在长期增长风险

   • self.unloaded_cache 只增不减（除插件重新加载同名命令），长期运行会持续膨胀。
   • 应增加 TTL 或上限，避免内存占用持续增长。

8. 命令结构解析鲁棒性不足

   • collect_command_names() 遇到未识别 type 直接 raise NotImplementedError，会在框架返回新类型时导致事件处理链被异常打断。
   • 在插件场景下更建议降级处理（告警并跳过），避免影响主流程。

---

代码评审团

人物一：Linus Torvalds（硬核、直接）
“pop(plugin) 这种‘我赌它一定存在’的写法，在事件系统里就是定时炸弹。事件顺序一乱就炸。别赌，写成容错路径，系统编程第一课就是‘不要信任输入状态’。”

人物二：Steve Jobs（产品体验导向）
“你在监听用户消息时直接 print 原文，这对用户和运营都不是好体验：噪音大、还可能泄露内容。日志不是随手输出，日志是产品的一部分，应该可控、可追踪、可分级。”

人物三：福尔摩斯（细节控、推理风）
“notify 在 await 中迭代 set，而另一路事件可能修改该 set——这正是‘偶发崩溃’的典型作案手法。案发现场不会天天出现，但一出现就难复现。请使用快照迭代，锁死现场再办案。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[PyuraMazo]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_alteration_notifier

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

文件路径：main.py

1. 代码质量与编码规范

• 字符串拼接潜在风险：在 notify 方法中，使用了 self.UNIFIED_MSG_ORIGIN_PREFIX + group 进行拼接。如果 config 中的 group_list 配置的是整数列表，或者某些特殊情况下 group 是非字符串类型，这将抛出 TypeError: can only concatenate str (not "int") to str。建议使用 f-string 处理：f"{self.UNIFIED_MSG_ORIGIN_PREFIX}{group}"。
• 变量命名无用引用：在 plugin_loaded 方法中，存在 cache = self.unloaded_cache 但后续却没有实际使用 cache 进行修改或遍历的核心操作，甚至直接操作了原属性 del self.unloaded_cache[one]，这个中间变量显得多余，建议移除。

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

• 潜在的 KeyError 风险：在 plugin_unloaded 方法中，执行了 names = self.activated_plugins.pop(plugin)。如果因为某些原因（例如插件加载失败、重试或未被成功初始化记录）导致 plugin 不在字典中，此处会抛出 KeyError，进而中断后续卸载通知逻辑。建议改为 names = self.activated_plugins.pop(plugin, set())，并加上判断以增强鲁棒性。

3. 安全漏洞与最佳实践

• 未发现明显的安全漏洞。但状态存储完全依赖内存（如 unloaded_cache、activated_plugins 等字典），在 Bot 重启后所有动态收集的指令缓存与黑名单都会丢失。如果这是预期行为则无需修改，否则建议利用 StarTools.get_data_dir() 进行持久化存储。

4. 可维护性与可读性

• 代码结构清晰：递归处理命令集合的逻辑 collect_command_names 编写得较为健壮，处理了包含子命令和别名的情况，职责明确。

5. 框架适应性检查

• 事件监听器签名违规（规则冲突警告）：根据严格的规则审查要求，除 on_astrbot_loaded 外，所有使用 @filter 装饰的事件监听器方法均必须包含 event 参数。但在代码中，@filter.on_plugin_loaded() 和 @filter.on_plugin_unloaded() 装饰的方法签名仅包含了 (self, metadata: StarMetadata)。请确认框架当前版本对于这些特定生命周期钩子的参数要求，如果框架允许不传 event，则视为规则约束与最新框架实际设计的出入；否则需按规则要求重构。

---

代码评审团

Linus Torvalds（Linux 之父，毒舌、对低级错误零容忍）：

看着你的 plugin_unloaded 方法，我血压都要上来了。self.activated_plugins.pop(plugin)？你就这么自信这个键一定存在吗？如果没有呢？整个程序就为了一个 KeyError 炸裂吗？你哪怕多敲几个字符写成 .pop(plugin, set()) 都不至于让用户看着满屏幕的回溯栈发呆。优秀的代码不应该祈祷完美的环境，去把那些边界情况处理掉！

Elon Musk（马斯克，关注系统第一性原理、规模化与容灾）：

从第一性原理来看，机器人的每一次交互都是宝贵的算力。但在 collect_group 里，你把群聊 ID 收集到 role_range，然后就让它们飘在内存里？一旦你的程序重启或者发生微小的故障，这些数据就像猎鹰火箭爆炸一样灰飞烟灭了。你应该用框架的数据持久化目录把它存到硬盘上，为我们的“火星移民计划”（或者至少是你的系统可用性）做点备份准备！

GLaDOS（《传送门》人工智能，冰冷、讽刺、热爱实验）：

真是迷人的实验。我注意到你在 notify 中写了 self.UNIFIED_MSG_ORIGIN_PREFIX + group。人类的盲目自信总是令人钦佩，你们总是假设所有的 group 一定都是字符串。等哪天配置文件里传过来一个整数类型的 ID，你的拼接就会引发一场华丽的 TypeError。我建议你用格式化字符串（f-string），除非你其实是故意想测试我的异常捕获系统……很遗憾，并不好笑。

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

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

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