[Plugin] astrbot_plugin_rocom

[bvzrays]

插件信息

{
  "name": "astrbot_plugin_rocom",
  "display_name": "洛克王国数据查询",
  "desc": "基于 WeGame API 的洛克王国数据查询插件，支持扫码登录和凭证导入，涵盖档案、战绩、背包宠物图鉴等查询渲染。",
  "author": "bvzrays & 熵增项目组",
  "repo": "https://github.com/Entropy-Increase-Team/astrbot_plugin_rocom",
  "tags": [],
  "social_link": ""
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_rocom

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

main.py

• 功能实现与逻辑缺陷（严重潜在崩溃风险）
  在 rocom_profile 和 rocom_battle_record 方法中，你使用了 asyncio.gather(..., return_exceptions=True) 来并发执行多个网络请求。当使用 return_exceptions=True 时，如果有任务失败，其返回值将是一个 Exception 的实例对象。
  代码中仅针对 role_res 做了 isinstance(role_res, Exception) 的检查。然而，对其他的返回值，却直接使用了 ev = eval_res or {} 这种默认回退逻辑。
  问题在于：在 Python 中，Exception 对象的布尔求值是 True。因此，如果 eval_res 返回了一个异常对象，ev 将被赋值为这个异常对象，而不是空字典。随后代码调用了 ev.get("strength", 0)，这会直接抛出 AttributeError: 'Exception' object has no attribute 'get'，导致整个事件处理函数崩溃。
  修复建议：必须对所有从 gather 返回的子任务结果进行类型或异常判定，例如 ev = eval_res if isinstance(eval_res, dict) else {}。

• 安全漏洞与最佳实践（异常捕获）
  在 rocom_qq_login 和 rocom_wechat_login 方法中，撤回消息的代码段出现了裸露的 except: （即 except: pass）。
  这违反了 PEP 8 规范 (E722)，且在异步环境中是危险的。裸露的 except: 不仅会捕获常规的程序错误，还会拦截 KeyboardInterrupt、SystemExit 以及至关重要的 asyncio.CancelledError，从而可能打断协程正常的取消逻辑。
  修复建议：请将其修改为 except Exception:。

core/client.py

• 代码质量与类型注解规范
  文件中有大量的接口定义方法（例如 get_role, get_evaluation, get_pet_summary, get_battle_list 等），其参数默认值设为了 None，但类型注解却使用了基础类型，例如 account_type: int = None 或 zone: int = None。
  根据 Python 的类型提示规范，如果参数允许接收 None，应当明确标记其为可选。在 Python 3.10 中，应使用更标准的写法 account_type: int | None = None 或 Optional[int] = None，以保证代码的规范性和类型检查工具（如 MyPy）的顺利运行。

core/render.py

• 潜在的异步资源泄漏（生命周期管理冲突）
  _cache_cleanup_task 在 Renderer 类中被定义为类属性（Renderer._cache_cleanup_task）。在 __init__ 构造函数中，如果任务未开启则通过 asyncio.create_task 创建并赋值给该类属性。
  问题在于：如果运行环境中在不同时间或由于插件热重载机制，实例化了超过一个 Renderer 对象，后初始化的实例会直接覆盖掉 Renderer._cache_cleanup_task 指向的 Task 对象引用。此时，旧实例开启的后台清理任务会失去引用而变成“游离态”。当调用 close() 时，这些丢失引用的任务无法被 cancel()，导致它们在后台永远地处于 while True 的休眠和轮询中（内存泄漏及冗余的磁盘 I/O）。
  修复建议：后台任务应该和对象实例的生命周期绑定。将 _cache_cleanup_task 改为实例属性 self._cache_cleanup_task 来独立管理每个渲染器的后台任务，或者彻底将渲染器改造为受控的单例模式。

---

代码评审团

Linus Torvalds：
老天啊，你居然在使用 asyncio.gather(return_exceptions=True) 之后，期望一个 Exception 对象能像个小狗一样乖乖地响应 .get() 方法？当异常对象跑到你的 ev.get(...) 里炸开的时候，那种 AttributeError 简直是在嘲笑你的并发设计。永远、永远要对可能返回的异常进行显式的类型检查，不要给那些假装成字典的 Exception 任何可乘之机！

银狼 (Silver Wolf)：
哈，被我抓到 bug 了吧！你的 except: pass 就像是给系统开了一个毫无底线的黑洞，它连协程的 CancelledError 都会一口吞掉。写游戏外挂……啊不，写插件，最忌讳的就是不留退路。如果不指定 except Exception:，你的异步任务在被取消时就会像卡模一样的卡在死循环里。而且把类型注解写成 int = None？这在我的编译器里可是要扣大分的哦。

Steve Jobs：
伟大的艺术品在于细节和内部设计的一致性。你看看 core/render.py 里对于任务的追踪逻辑：你把后台清理任务放在了“类”的层面去管理，却把它交给“实例”的生命周期去销毁。如果有两个实例，第一个任务的灵魂将被永远抛弃。设计应该是完美的、从一而终的，把属于实例的状态还给实例吧，不要用类属性去糊弄事，我们需要的是纯粹的工程美学。

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

---

🔍 审核摘要

统计信息

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

main.py
__init__.py
core/__init__.py
core/client.py
core/render.py
core/user.py

---

此报告由AI自动生成，旨在提供初步反馈和改进建议，不能完全替代人工审核。最终决策以社区维护者的人工审核为准。目前自动审核（仓库地址）处于试验阶段，如遇问题请向维护者反馈。评论 @astrpluginreviewer review 来重新触发 review，请不要重复提交插件发布 issue。

当前仓库：Entropy-Increase-Team/astrbot_plugin_rocom
剩余触发次数：4