[Plugin] astrbot_plugin_endfield

[bvzrays]

插件信息

{
  "name": "astrbot_plugin_endfield",
  "display_name": "终末地协议终端",
  "desc": "基于森空岛 API 的终末地插件，支持便签、理智、干员面板等查询。移植自 endfield-plugin。",
  "author": "bvzrays & 熵增项目组",
  "repo": "https://github.com/Entropy-Increase-Team/astrbot_plugin_endfield",
  "tags":  [
    "游戏",
    "终末地",
    "数据查询"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_endfield

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

main.py

代码质量与编码规范

1. 局部导入过多违反 PEP 8 规范：代码中多处使用了函数内嵌的 import 语句，例如在 calendar_cmd 中 import datetime，在 operator_list 中 import random，在 sync_panel 中 import asyncio as _asyncio。这些导入应该统一移动到文件顶部，以提高代码的可读性和执行效率。
2. “巨无霸”函数与高圈复杂度：如 global_gacha_stats、calendar_cmd、operator_panel 等方法动辄上百行，内部嵌套了极深的 if-else、for 循环和局部函数定义（如 build_pool_section 等）。函数职责严重过载，应当将其拆分为独立的数据解析和格式化函数。
3. 破坏封装的越权调用：在 get_activity_banner 中，直接调用了 self.client._get(f"/api/wiki/items/{entry_id}")，强行访问了内部受保护方法，违背了面向对象的封装原则，应在 client.py 中提供对应的公开方法。

可维护性与可读性

1. 跨平台兼容性硬编码：在 _send_and_get_msg_id 方法中，使用了对 aiocqhttp 平台的强依赖与硬编码判断，并直接调用其底层 API（send_group_msg）。这破坏了 AstrBot 旨在跨平台适配的设计初衷，一旦用户更换为其他平台适配器，此段追踪逻辑会彻底失效。

潜在缺陷或问题

1. SSRF 防御存在 TOCTOU 漏洞：get_b64 函数虽然对 URL 进行了主机名解析并拦截了内网 IP，但后续仍交由 httpx.AsyncClient 进行访问。这会产生经典的 TOCTOU (Time-of-Check to Time-of-Use) 漏洞和 DNS 重绑定风险，因为验证时的 DNS 解析结果与实际请求时的 IP 可能不同。
2. 粗暴的字符串处理易引发异常：在 qr_login 方法中解码二维码图片时使用了 base64.b64decode(qr_b64.split(",")[-1])。若接口异常返回未带有 data:image... 前缀的内容，.split(",")[-1] 会获取错误数据，引发 binascii.Error 导致当前协程崩溃且没有适当的异常提示。
3. 异常处理覆盖不均：许多 @filter.command 修饰的指令函数内部（如 phone_login）调用网络接口后缺乏外层 try-except 兜底，网络剧烈波动时可能导致机器人无响应卡死在当前处理上下文中。

---

core/client.py

潜在缺陷或问题

1. 过于宽泛的异常捕获：底层的 _request 拦截了 except Exception as e: 返回 None，这不仅吞没了网络异常，还可能掩盖内部代码的 KeyError 或 TypeError。调用端在接收到 None 后也没有完整的追溯链路，难以排查具体问题。
2. 隐式的空值扩散：大量 API 访问函数声明为 -> Optional[Dict]，但部分业务逻辑层并没有严谨的非空检查链，在极端弱网环境下可能引发 AttributeError: 'NoneType' object has no attribute 'get'。

---

core/render.py

代码质量与编码规范

1. 危险的“正则模板编译器”：_adapt_template 和 _inline_assets 方法中企图用大段复杂的正则表达式（如 re.sub(r'\{\{if\s+(.+?)\}\}', ...) 和 \{\{([^%\}]+?)\}\}）将非标准的模板语法强制转换为 Jinja2 语法。这在遇到存在干扰字符的合法 HTML 结构、甚至稍有变化的空格或嵌套标签时极其容易失效，且潜藏引发灾难性回溯（Catastrophic Backtracking）的风险。

潜在缺陷或问题

1. 浏览器实例缺乏健康检查：Playwright 的 _browser 实例在第一次被 launch 后会一直作为常驻进程运行。尽管有锁控制了上下文的创建，但在面对大规模高并发渲染任务或是网页长时间无响应导致超时崩溃后，并未设计对浏览器实例假死进行心跳检测与重启的机制，可能引发不可预期的阻塞。

---

core/user.py

潜在缺陷或问题

1. Windows 平台下的写入风险：_save 方法使用了 os.replace(temp_path, self.path) 来保证写入的原子性。但 os.replace 在 Windows 环境下，若目标文件恰好正在被其他进程（诸如杀毒软件、索引服务）短暂持有或扫描，会抛出 PermissionError 并直接中止更新操作，可能造成配置文件的新数据丢失。

---

代码评审团

人物一（Linus Torvalds）：
"我真的无法理解，为什么有人会觉得在函数内部塞 import datetime 是个好主意？你是觉得 Python 解析器每次执行函数时都去查一遍模块表很好玩吗？还有 render.py 里那一坨正则表达式——你这是在写模板引擎还是在写不可读的古埃及象形文字？不要试图用正则去解析嵌套的语言结构，这在计算机科学的第一天就应该有人教过你！唯一的亮点是，你们至少没在主线程里塞满同步阻塞的网络请求，勉强算有点脑子。"

人物二（Robert C. Martin - Uncle Bob）：
"看到 main.py 里那些几百行的怪兽级函数（比如 global_gacha_stats），我的 Clean Code 报警器响个不停。一个函数做了数据拉取、数据清洗、多套异常处理还要负责拼装渲染上下文，这违背了单一职责原则（SRP）。你完全可以把它拆解为干净、有描述性的短方法。整洁的代码读起来应该像是一篇优美的散文，而你们现在的代码像是在翻阅一本胡乱装订的说明书。"

人物三（John Carmack）：
"让我们谈谈安全和鲁棒性。你们在 SSRF 防御上做了一次 DNS 校验，但 httpx 在真正发起请求时可是会有它自己的生命周期的，这种设计在恶意 DNS 服务器下根本防不住 TOCTOU 攻击。至于那个依靠强行捕获全局 Exception 然后吞掉错误的 API 客户端，在遇到真正的底层架构灾难时，连个有用的崩溃现场都不会留给你。不过，基于 Playwright 的服务端渲染架构构思本身不错，只要管好那个可能随时内存泄漏的无头浏览器。"

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

---

🔍 审核摘要

统计信息

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

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

---

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

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

[astrbot-plugin-copybara]

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

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