[Plugin] astrbot_plugin_steaminfo_xiaoheihe

[xiaoruange39]

插件信息

{
  "name": "astrbot_plugin_steaminfo_xiaoheihe",
  "display_name": "小黑盒游戏截图",
  "desc": "通过小黑盒网站搜索并生成截图获取 Steam 游戏信息，支持小黑盒链接自动解析截图。",
  "author": "xiaoruange39",
  "repo": "https://github.com/xiaoruange39/astrbot_plugin_steaminfo_xiaoheihe",
  "tags": [
    "游戏",
    "小黑盒",
    "steam",
    "截图"
  ],
  "social_link": "https://github.com/xiaoruange39"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steaminfo_xiaoheihe

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

main.py

以下是对您提供的 main.py 文件的代码审查报告。该插件在使用 Playwright 进行网页自动化和异步处理方面整体架构良好，且完全遵守了 AstrBot 框架的特定规范（如正确使用 filter 模块、logger 导入规范等）。但在代码结构和资源管理上仍存在一些需要优化的重点问题。

1. 代码质量与编码规范

• 局部导入问题 (PEP 8)：在 _save_temp_image 函数内部使用了 import tempfile 和 import os。根据 PEP 8 规范，所有的标准库和第三方库导入应当放置在文件的最顶部，除非有极特殊的循环导入问题（此处显然没有）。
• 过度复杂的代码块 (巨型函数)：cmd_xiaoheihe 方法长达 130 多行，且包含了极深的嵌套（如 try...except 内部嵌套 Plan A、Plan B、Plan C 的 fallback 逻辑）。这违反了单一职责原则（SRP）。建议将“页面导航与链接解析”、“元素信息提取”和“页面元素清理”拆分为独立的小型异步方法。
• 过于宽泛的异常捕获：代码中大量使用了 except Exception:（甚至带有 pass），这会吞噬掉包括 KeyboardInterrupt 或 asyncio.CancelledError 在内的关键异常，使得深层错误极难调试。建议尽量捕获具体的异常（如 playwright.errors.TimeoutError）。

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

• on_message 中无前缀触发的逻辑冗余：
  在 on_message 方法中，处理无前缀逻辑时使用了如下代码：

  if len(content_stripped) > len(prefix) and content_stripped[len(prefix)].isspace():

  这里假定了指令和参数之间必须有一个空格。如果用户输入的是 小黑盒黑神话（中间无空格），该逻辑将无法触发。这可能与用户的直觉不符。建议改用正则表达式或更灵活的字符串切割。
• Playwright 并发竞争（潜在逻辑漏洞）：
  虽然 _get_browser 使用了 asyncio.Lock() 来保证浏览器实例的单例安全，但在高并发下，多个会话同时执行 cmd_xiaoheihe 或自动截图时，Playwright 的系统资源占用会激增。目前没有任何并发限制（如 Semaphore），可能会导致内存 OOM 或触发目标网站的防爬虫机制。

3. 安全漏洞与最佳实践

• 【严重】临时文件资源泄漏 (Resource Leak)：
  _save_temp_image 方法使用 tempfile.gettempdir() 将生成的图片保存在系统的临时目录下，文件名为 xiaoheihe_xxx.jpg。但是在整个文件中，没有任何地方负责删除这些图片。随着机器人长期运行和频繁截图，这会导致服务器磁盘空间被无休止地消耗，最终引发磁盘写满的严重故障。
  修复建议：应在使用 yield event.image_result(image_path) 发送完图片后，显式调用 os.remove(image_path) 进行清理，或者在后台设计一个定时清理机制。

4. 可维护性与可读性

• 复杂的 JSON 递归搜索：
  _extract_xiaoheihe_url 中的 find_url_in_dict 递归函数虽然能工作，但嵌套过深且难以维护。对于 QQ JSON 消息卡片，直接将整个 JSON 转换为字符串再使用预编译的正则表达式进行匹配，性能和可读性通常都要优于复杂的递归遍历。

5. 潜在缺陷或问题

• Cookie 注入的生命周期问题：
  在 _create_context 中，每次请求都会创建一个全新的 BrowserContext 并注入一遍 Cookie。如果在短时间内有大量请求，这种频繁初始化 Context 和注入的过程会带来不必要的性能开销。考虑到 Cookie 是静态配置的，或许可以考虑在整个插件生命周期内复用一个长驻的 Context，或者仅打开新的 Page。

---

代码评审团

Linus Torvalds：（Linux 之父，性格暴躁，极其看重系统底层与性能）

"What the hell is this temp file logic? 你是不是觉得硬盘空间是靠光合作用长出来的？！你写了一个叫 _save_temp_image 的函数，把几兆大小的高清 jpeg 塞进系统的 temp 目录，然后呢？然后你就拍拍屁股走人了！没有清理代码！没有任何垃圾回收！ 只要你的机器人跑上三个月，整个服务器的 inode 都会被你这些没人要的孤儿截图塞爆！去加上 os.remove()，马上！不要把你的内存泄漏当成什么行为艺术！"

Gordon Ramsay：（地狱厨神，注重结构与准备工作）

"Look at this cmd_xiaoheihe function! 这是一个毫无头绪的大乱炖！你把导航、找元素、Plan A、Plan B、甚至把该死的隐藏 CSS 样式全倒进了一个锅里！它长得就像一只被车碾过的八爪鱼！更离谱的是，你居然在 _save_temp_image 函数里面才去 import tempfile 和 import os！这就好比你的锅里已经起火了，你才跟客人说：'稍等，我跑去街角的超市买两根葱！' 把你的食材（Imports）切好放在案板（文件顶部）上，然后把那个巨型函数给我拆解了！"

GLaDOS：（光圈科技 AI，冷酷、嘲讽、喜欢测试）

"Oh... 我看到了你的 Plan A、Plan B 和 Plan C。这真是感人至深的冗余设计。你就像一只在迷宫里疯狂撞墙的实验白鼠，一次失败后就盲目地尝试下一种选择，并且对所有的错误都只用了一句轻描淡写的 except Exception: 来掩盖。你甚至都不知道是什么杀死了你的代码。顺便说一句，我很欣赏你把无用的 CSS 元素隐藏起来的假象，但掩盖视觉上的缺陷并不能掩饰代码架构上的......平庸。继续测试吧，希望在磁盘被你的临时文件填满之前，我们还能得到一点有用的数据。"

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steaminfo_xiaoheihe

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

main.py

1. 代码质量与编码规范

• 类型注解不完整：虽然大部分方法使用了类型注解（如 event: AstrMessageEvent），但在局部变量和部分返回值上存在缺失，例如 _extract_xiaoheihe_url 中的 raw_data 类型推断不清晰。
• 异常捕获范围过大：在多处（如 _extract_xiaoheihe_url 和 _process_screenshot 中）使用了 except Exception: 捕获所有异常。这会导致隐藏真正的代码缺陷（见下文的未定义变量错误），不符合 PEP 8 推荐的精准捕获原则。

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

• 致命的未定义变量引发 NameError：
  在 _extract_xiaoheihe_url 方法中处理 JSON 卡片消息时，存在严重的逻辑错误：

  json_text = json_str if json_str else str(raw_data)

  代码上下文中从未定义过 json_str 变量。如果触发该分支，程序将直接抛出 NameError。并且由于外部包裹了宽泛的 except Exception as e:，这个错误会被静默记录，导致含有小黑盒链接的 JSON 卡片永远无法被正确解析。

3. 安全漏洞与最佳实践

• 过时的 asyncio 方法：
  在 _save_temp_image 和 _schedule_cleanup 中使用了 asyncio.get_event_loop()。在 Python 3.10 及以上版本中，如果当前线程没有运行的事件循环，直接调用此方法会引发 DeprecationWarning。
  建议：在异步函数调用的上下文中，应该使用 asyncio.get_running_loop() 获取当前循环。
• Cookie 解析逻辑脆弱：
  _create_context 方法中的 Cookie 解析 parts = pair.split("=", 1) 假设所有的 Cookie 格式必定是 key=value。如果用户输入的配置带有不规范的空格或缺失等号（虽然代码排除了长度不为 2 的情况），这部分被直接静默丢弃，缺乏校验日志，可能导致用户配置了 Cookie 却因格式问题未生效而不自知。

4. 可维护性与可读性

• 硬编码的选择器与魔法数字：
  _process_screenshot 中包含了大量的 CSS 选择器（如 list_game_selector = 'a[href*="/app/topic/game/"]'）和隐式超时时间（如 timeout=5000）。Playwright 爬虫代码天然较为脆弱，一旦小黑盒前端页面改版，这些散落的魔法字符串将极难维护。建议将所有的选择器抽离为类级别的常量或字典配置。

5. 潜在缺陷或问题

• Playwright 幽灵进程风险：
  虽然在 terminate 方法中正确地调用了 await self._browser.close() 和 await self._playwright.stop()，但在极端的网络波动或 AstrBot 强制热重载时，terminate 可能不会被完美触发，从而留下无头的 Chromium 孤儿进程。建议在初始化时注入参数以确保浏览器随父进程退出。
• Semaphore 并发锁死隐患：
  代码使用了 self._semaphore = asyncio.Semaphore(2) 限制截图并发。这是非常好的做法。但在 _process_screenshot 中如果发生了一些无法被 asyncio 超时机制捕获的底层 Playwright 死锁（例如僵尸页面），可能会导致 Semaphore 永远不被释放，最终阻塞后续所有用户的请求。

6. 框架适应性检查

• ✅ 日志记录：完美遵守规范，仅使用了 from astrbot.api import logger。
• ✅ 并发模型：网络 I/O 及 Playwright 交互均使用了正确的异步（await）调用，无同步阻塞网络请求。
• ✅ 数据持久化：截图作为临时文件存储在 tempfile.gettempdir() 中并实现了延迟清理，未涉及用户数据的持久化存储，无需使用 StarTools.get_data_dir()，合规。
• ✅ 插件注册与主类：正确继承自 Star 并初始化。
• ✅ 装饰器导入：filter 正确从 astrbot.api.event 导入，防命名冲突处理得当。
• ✅ 通用事件监听器签名：@filter.command 和 @filter.event_message_type 均正确包含了 event: AstrMessageEvent 参数。

---

代码评审团

Linus Torvalds：

"你在跟我开玩笑吗？看看第 291 行：json_text = json_str if json_str else str(raw_data)。你甚至都没有定义过 json_str！这就好比你让内核去分配一块不存在的内存，然后还在外面包了一层 except Exception 把它当成垃圾一样扫进地毯下面！不测试你的错误处理路径，你写这些 try-except 有什么意义？赶紧把这个弱智的 NameError 修掉，不然你的 JSON 解析代码就是一堆毫无用处的废字符。"

Steve Jobs：

"你知道吗，伟大的产品在于细节。我们在 Python 3.10 这个极其优雅的运行时里，而你却还在用 asyncio.get_event_loop()？这就像是在最新的 iPhone 上保留了实体键盘。Python 社区早就告诉你应该使用 asyncio.get_running_loop() 来保证它的确定性和纯粹性。另外，你的 Plan A、B、C 抓取逻辑虽然有效，但写得像一锅意大利面。把那些丑陋的 CSS 选择器拿出来，给它们一个干净的配置结构，让代码重新呼吸。"

GLaDOS (《传送门》)：

"我已经分析了你的并发机制。你使用了 asyncio.Semaphore(2) 来限制资源的消耗，这对于一个脆弱的碳基生命体写出的代码来说，居然是一个非常明智的防卫手段。不过，你在清理临时文件的逻辑里假设 os.remove 永远能找到那个文件。虽然框架文档说我们现在不追究文件 I/O 的问题，但从系统工程的角度来看，看着那些在极端情况下没有被清理掉的孤儿图片慢慢填满硬盘，会是一件……非常有趣的事情。继续保持，人类。"

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steaminfo_xiaoheihe

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

main.py

功能实现与逻辑正确性 / 潜在缺陷与问题

1. Playwright API 误用与后台服务泄漏风险（严重）：

   • 在 _get_browser 方法中，当检测到浏览器断开（not self._browser.is_connected() 为 True）时，代码会直接执行 self._playwright = await async_playwright().start()。这会启动一个全新的 Playwright Node.js 服务进程，导致旧的服务进程失去引用且永远无法关闭，从而引发严重的内存泄漏。应该将 Playwright Manager 的初始化与 Browser 的初始化分离，确保 Manager 在整个插件生命周期内只启动一次。
   • 在 terminate 方法中，调用了 await self._playwright.stop()。实际上 async_playwright().start() 连续调用后返回的是 Playwright 实例，该实例并没有 stop() 方法。真正的 stop() 属于 AsyncPlaywrightContextManager。由于发生 AttributeError，插件在重载或卸载时不仅会报错，还会导致 Playwright 进程未被正确终止。
   • 修复建议：

     # 初始化时保存 manager
     self._playwright_manager = async_playwright()
     self._playwright = await self._playwright_manager.start()
     
     # 卸载时使用 manager 调用 stop
     await self._playwright_manager.stop()

2. 搜索关键词缺乏 URL 编码：

   • 在 _process_screenshot 中构建搜索 URL 时：search_url = f"https://www.xiaoheihe.cn/app/search?q={game}"，未对用户输入的 game 字符串进行 URL 编码。如果用户输入包含特殊字符（例如搜索 Command & Conquer），& 符号截断会导致实际搜索词变为 Command ，引起搜索结果异常。
   • 修复建议：引入 urllib.parse.quote，改为 q={quote(game)}。

代码质量与可维护性

3. JSON 字典暴力转换为字符串进行正则匹配：

   • 在 _extract_xiaoheihe_url 中解析 QQ JSON 卡片消息时，使用了 json_text = str(raw_data)。Python 默认的 str(dict) 会使用单引号包裹字符串，且不会处理标准的 JSON 序列化转义。虽然此处简单的正则可能可以命中目标 URL，但这是一种非常脆弱的解析方式。若原始 URL 中带有特殊字符，可能会被错误截断。
   • 修复建议：使用标准的 json.dumps(raw_data, ensure_ascii=False) 将其转换为标准的 JSON 字符串后再进行正则匹配。

4. 异常处理嵌套过深（箭头反模式）：

   • 在 _process_screenshot 中的 “Plan A、Plan B、Plan C” 降级策略中，使用了极其深度的 try-except 嵌套。这不仅导致代码向右侧无限缩进（典型的 Arrow Anti-Pattern），还严重降低了代码的可读性和扩展性。
   • 修复建议：将每种 Plan 提取为独立的异步函数，或者将寻找选择器的过程放入一个带顺序的数组/迭代器中，使用平级的 for 循环和单一的 try-except 捕获。

---

代码评审团

Linus Torvalds：（揉了揉眉头，敲击键盘的声音极度暴躁）
你以为 async_playwright().start() 返回的是个能解决所有问题的魔法棒吗？！连 API 文档都不看就敢瞎调 await self._playwright.stop()？那个对象根本就没有 stop 方法！如果你把这种代码提交到我的内核里，你的 _get_browser 逻辑会在浏览器崩溃重启的几小时内，像癌细胞一样生出无数个僵尸进程，直接把服务器的内存给吃光！赶紧把 ContextManager 和 Playwright 实例的作用域给我分清楚！

Richard Stallman (RMS)：（抚摸着胡须，语重心长）
黑客精神并不代表你可以用野蛮的方式去对待数据结构。看到你用 str(raw_data) 去蹂躏一个可怜的字典，然后用正则去里面捞数据，这简直是对自由软件优雅精神的背叛。使用标准的 json.dumps() 吧，赋予数据它应有的纯净和规范格式，这也是对维护你代码的后人最起码的尊重。

Steve Jobs：（站在纯白的背景板前，双手合十）
我们在设计产品时，追求的是极致的极简主义。你看看你的 Plan A, Plan B, Plan C... 那些 try-except 像深渊一样一层层嵌套，导致代码臃肿得像一台 90 年代装满笨重风扇的 PC 主机。把这些丑陋的嵌套拆掉吧！把它们封装成独立的策略函数。记住，代码不仅要能在后台默默运行，它的结构本身就应当是一件艺术品。

---

🔍 审核摘要

统计信息

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

main.py

---

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

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steaminfo_xiaoheihe

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

main.py

代码质量与编码规范

• PEP 8 规范：代码结构整体清晰，方法命名表意明确，异步生成器 (yield) 使用非常熟练，符合异步流式响应范式。
• 魔法数字问题：在 _process_screenshot 等核心处理逻辑中，存在大量如 timeout=5000 和 timeout=10000 的硬编码数值。未能统一使用在 __init__ 中注入的配置项（如基于 self.wait_timeout 按比例折算），这不符合避免硬编码的规范。

功能实现与逻辑正确性

• 多层兜底策略：在通过 Playwright 抓取小黑盒页面时，设计了 Plan A/B/C 三种 DOM 结构的寻找策略，应对复杂动态加载的网页情况表现出很好的健壮性。
• 消息类型兼容性：在 _extract_xiaoheihe_url 方法中，针对 QQ 等平台的 JSON/卡片消息，通过 json.dumps 强转为文本后再进行正则匹配提取，是一种巧妙且容错率极高的有效做法。

安全漏洞与最佳实践

• 输入清理与注入防范：搜索游戏时，URL 的拼接使用了 urllib.parse.quote(game)，有效规避了 URL 注入风险。同时在 page.evaluate 执行隐藏元素的 JavaScript 代码时，没有采用不安全的字符串拼接，而是利用参数传递 ([selectors_to_hide, selector_to_modify])，防范了潜在的跨站脚本注入 (XSS) 等安全隐患。
• 资源清理机制：对于 Playwright 产生的海量临时截图，使用 _schedule_cleanup 借助事件循环实现了延时异步非阻塞删除。这种“阅后即焚”的资源管理手段是优秀的实践。

可维护性与可读性

• 事件分发与职责划分：通过 @filter.command 与 @filter.event_message_type(filter.EventMessageType.ALL) 的配合，合理分离了指令触发与无前缀监听/卡片嗅探的职责。
• 并发限流：明智地使用了 asyncio.Semaphore(2) 控制并行浏览器的渲染数量，避免了高频请求导致服务端内存泄漏或 Playwright 进程崩溃。

潜在缺陷或问题

• 未绑定局部变量异常 (UnboundLocalError)：
  在 _process_link_screenshot 中的连续 try...except 容错回退机制中存在逻辑漏洞。如果代码执行到最里层的回退（如全页截图和视口截图连续失败引发异常），此时 image_bytes 变量将没有被成功赋值。在执行到外部的 image_path = self._save_temp_image(image_bytes) 时，将会抛出 UnboundLocalError。虽然最外围兜底的 try-except 捕获了该异常避免了程序崩溃，但更好的做法是在 try 代码块开始前对 image_bytes = None 进行初始化，并在后续增加判空保护。
• 清理资源时的并发竞态风险：
  在 _get_browser 延迟初始化时，极具防备心地使用了 self._browser_lock 确保线程和并发安全。然而在执行 terminate(self) 卸载/停用插件逻辑关闭 _browser 时，却没有去申请此锁。如果在高并发调用下碰巧发生了插件的重载操作，这种未加锁的摧毁行为极易引发严重的竞态条件 (Race Condition)，可能导致僵尸进程。

---

代码评审团

人物一（Linus Torvalds）：
你这坨多层嵌套的 try-except 简直就像一场灾难！如果你最里层那个 page.screenshot 再挂掉，你的 image_bytes 变量就根本不存在！紧接着就会抛出一个愚蠢的 UnboundLocalError。虽然你外面套了一个巨大的 try-except 像尿布一样兜住了它，但这绝对不是写出严谨代码的借口。回去给它加上初始赋值和判空处理，别让你的程序处于薛定谔的变量状态！

人物二（Steve Jobs）：
我们花了那么多精力去追求极致的体验，结果你在代码里硬塞了 5000 和 10000 这样的魔法数字？你在配置项里定义了 wait_timeout，可是到了最关键的等待时刻，它却成了摆设。这说明你对代码的细节把控还远远不够。代码不仅要能跑，还要具备艺术品般的统一感和连贯性，去把那些硬编码都清理掉。

人物三（Elon Musk）：
在火星的自动化系统上，我们绝不能容忍任何底层的并发故障。我注意到你在启动浏览器引擎时，很聪明地加上了锁 self._browser_lock。但是，为什么在 terminate 终止火箭时你却选择“裸奔”？在超高并发并发请求的极限场景下，这必定会触发系统的竞态条件！记住第一性原理：在摧毁任何关键资源前，必须重新夺回对控制锁的权限！

---

🔍 审核摘要

统计信息

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

main.py

---

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

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steaminfo_xiaoheihe

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

main.py

这份代码整体质量非常高，充分利用了异步特性，对 Playwright 的生命周期管理（包括锁机制、信号量并发控制、上下文的 try/finally 清理）做得相当规范。此外，针对小黑盒复杂的页面结构设计了“多重降级方案（Plan A/B/C）”，体现了极强的业务鲁棒性。

以下是审查中发现的一些需要优化的细节和潜在问题：

1. 代码质量与编码规范

• 临时文件命名不符合 Pythonic 风格：
  在 _save_temp_image 中，使用 id(image_bytes) 结合 time() 来生成临时文件名：
  f"xiaoheihe_{id(image_bytes)}_{asyncio.get_running_loop().time()}.jpg"
id() 返回对象内存地址，字节对象如果被立刻垃圾回收，内存地址可能被复用。虽然加上了时间戳降低了冲突概率，但标准的最佳实践应当使用 uuid.uuid4().hex，既安全又优雅。
• JSON 序列化类型判断不够全面：
  在 _extract_xiaoheihe_url 提取 JSON 卡片消息时：
  json_text = json.dumps(raw_data, ensure_ascii=False) if isinstance(raw_data, dict) else str(raw_data)
  如果 raw_data 是一个列表 (list)，这里会走到 str(raw_data) 的分支。虽然 str() 也能把列表转成字符串用于正则匹配，但生成的字符串格式（如单引号）可能不是标准 JSON，建议将判断条件改为 isinstance(raw_data, (dict, list))。

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

• 无前缀指令正则匹配逻辑存在小瑕疵：
  在 on_message 中：match = re.match(r'^(?:小黑盒|xiaoheihe)\s*(.+)$', content_stripped, re.IGNORECASE)
  这里的 (.+) 要求必须有至少一个字符。如果 require_prefix 为 False 时，用户单纯发送了一条 "小黑盒"（没有游戏名），正则表达式将匹配失败，导致后续代码直接 return，用户无法收到类似 /小黑盒 触发时那句 "请输入要搜索的游戏名称" 的提示信息。这会导致两种触发方式的用户体验不一致。建议将 (.+) 改为 (.*)。

3. 安全漏洞与最佳实践

• 无明显的安全漏洞：代码中使用的 page.evaluate 注入的 JavaScript 脚本所使用的变量 [selectors_to_hide, selector_to_modify] 均是静态预定义的 CSS 选择器字符串，不存在跨站脚本（XSS）或任意代码执行的风险。

4. 可维护性与可读性

• 上帝方法 (God Method) 导致可读性下降：
  _process_screenshot 方法长达 130 多行，且嵌套了大量的 try-except 和 if not final_url。虽然逻辑上行得通，但这使得主干流程不够清晰。建议将 "Plan A / B / C 的导航与寻找最终 URL" 的逻辑抽取为一个独立的异步方法（例如 _navigate_to_game_page(page, game_name)），该方法负责返回 final_url 或直接完成导航并返回布尔值。

5. 潜在缺陷或问题

• 配置项未进行强制类型转换：
  self.wait_timeout: int = config.get("wait_timeout", 60000)
config.get 仅仅是字典获取，它不保证用户在 YAML/JSON 配置文件中填写的类型一定是整数（例如用户可能误填了字符串 "60000"）。
  在后续代码中使用了数学运算：short_timeout = max(3000, self.wait_timeout // 12)。如果 wait_timeout 是字符串，这里会直接引发 TypeError 导致插件崩溃。建议在初始化时防御性地进行显式转换：int(config.get("wait_timeout", 60000))。

---

代码评审团

Linus Torvalds：（皱着眉头，指着屏幕）

“你在 _save_temp_image 里用 id(image_bytes) 来做唯一标识？你是觉得我们还在写 1995 年的 C 语言，需要拿指针地址来凑哈希吗？Python 标准库里有个东西叫 uuid，用它！还有，别对用户配置文件抱有任何幻想。你用 config.get 拿出来的东西，谁告诉你一定是整型了？等用户在配置文件里写了个字符串 "60000"，你的 wait_timeout // 12 就会直接炸出个 TypeError！加个 int() 转换能花你几毫秒时间？”

Steve Jobs：（穿着黑色高领毛衣，双手合十）

“这段代码的底层工程做得很扎实，Playwright 的并发和降级策略很棒，这是一个很好的产品底子。但是，看看这个体验：如果用户不需要加前缀，满心欢喜地输入了『小黑盒』三个字，期待你的机器人给他一点提示，结果呢？那个死板的正则表达式 (.+) 直接把他们拒之门外了，一点反馈都不给。产品体验是一门艺术，把那个加号改成星号 (.*)，让空字符串也能透传到你的 cmd_xiaoheihe 里去触发那句优雅的提示语。永远，永远不要让用户面对未知的沉默。”

GLaDOS (《传送门》人工智能)：（冰冷且带有金属质感的电子音）

“我刚才在扫描 _process_screenshot 的时候，差点以为我的光学传感器出故障了。Plan A 失败……执行 Plan B……Plan B 失败……执行 Plan C。多可爱的状态机啊，把它全部塞进一个长达 130 行的函数里。难道把寻找链接的逻辑隔离到一个独立的、经过充分测试的函数中，会烧毁你的神经元吗？还有，那个 json.dumps 里的三元运算符，你只检测了 dict，如果传入的是一个包含多个数据块的 list 呢？它就可怜巴巴地变成了 Python 的 str() 格式。当然，作为一个人类，这种程度的代码已经算是奇迹了。”

---

🔍 审核摘要

统计信息

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

main.py

---

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

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_steaminfo_xiaoheihe

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

main.py

整体来看，该插件代码结构完整，较好地利用了 Playwright 进行异步网页自动化截图，并使用了信号量控制并发，设计了相对合理的降级与重试策略（Plan A/B/C）。代码完全符合 AstrBot 的各项严格规范（包括 logger、filter 的导入，Star 类的继承，以及事件处理函数的签名要求）。

以下是代码审查中发现的需要关注或改进的问题：

1. 潜在缺陷与问题 (资源与内存管理)

• 上下文泄漏风险 (_create_context)：
  在 _create_context 方法中，如果你成功创建了 context，但在随后注入 Cookie 时（await context.add_cookies(cookie_list)）发生异常，该异常会被抛出给调用方。由于此时 context 尚未返回，调用方 _process_screenshot 的 finally 块中的 context 仍为 None，这将导致这个已创建的浏览器上下文永远不会被关闭，造成内存和资源泄漏。
  建议：在 _create_context 中使用 try...except 块，若后续配置步骤失败，主动关闭已创建的 context 再向上抛出异常。
• 临时文件清理的边缘情况 (_schedule_cleanup)：
  使用 asyncio.get_running_loop().call_later(delay, cleanup) 来清理文件在正常运行中没有问题。但如果插件在截图生成后的 10 秒内被卸载，或者 Bot 主进程退出，回调将不会执行，导致在操作系统的临时目录中遗留垃圾文件（.jpg）。
  建议：在类初始化时维护一个 self._temp_files = set()，在 terminate 方法被调用时，统一遍历并清理未被删除的临时文件。

2. 代码质量与编码规范 (可维护性)

• “毁灭金字塔”式的异常处理 (_process_link_screenshot)：
  在该方法中，为了应对元素截图失败的情况，代码嵌套了多层 try...except 来实现降级（元素截图 -> 全页截图 -> 视口截图）。

  try:
      # 元素截图
  except Exception as el_err:
      try:
          # 全页截图
      except Exception as fp_err:
          # 视口截图

  这导致代码嵌套极深，可读性极差。
  建议：将这部分逻辑抽离为一个单独的异步方法 _take_screenshot_with_fallback(page, element)，使用扁平化的结构或循环重试列表来优化代码可读性。

• 冗余的正则与条件判断 (on_message)：
  在无前缀指令的解析中：match = re.match(r'^(?:小黑盒|xiaoheihe)\s*(.*)$', content_stripped, re.IGNORECASE)。虽然有效，但由于 AstrMessageEvent 本身已经承载了被框架解析过的指令信息，手动去正则匹配 event.message_str 会引入对不同消息格式（如带有 CQ 码或图片的消息）的脆弱性。不过作为兜底逻辑，此实现尚可接受。

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

• Cookie 字符串解析的健壮性 (_create_context)：
  在解析 self.cookies 时，使用了简单的 split(";") 和 split("=", 1)。如果 Cookie 值本身包含 =，split("=", 1) 是安全的。但如果用户的配置文件中 Cookie 字符串不规范（如少写了等号），len(parts) == 2 的判断虽然能防止崩溃，但缺乏错误日志提示。可以适当增加一条 Warning 日志以帮助用户排查配置错误。

---

代码评审团

人物一：Linus Torvalds（Linux之父，以言辞犀利、极其看重代码质量著称）

“我简直不敢相信我的眼睛。你在 _process_link_screenshot 里写的那个 try-except 嵌套是什么鬼东西？通往地狱的阶梯吗？！如果元素截图失败，你就套一个异常，全页失败，再套一个？为什么不写一个干净的 fallback 列表或者重试函数？代码是给人看的，不是用来测试我的显示器宽度的！不过，我得承认你加了并发锁（Semaphore 和 Lock）来控制 Playwright 这个吃内存的怪物，这点还算你没彻底失去理智。”

人物二：Steve Jobs（苹果公司联合创始人，追求极致的优雅与完美）

“你的产品有一件非常丑陋的事情：它在用户的硬盘上乱扔垃圾。你用了 call_later 去删除图片，但这就像是你把灰尘扫到了地毯下面然后祈祷没人在十分钟内掀开它。如果系统在这 10 秒内重启了呢？那张图片就永远留在那儿了。一个伟大的工匠连柜子的背面都会做得很完美。你应该在插件的生命周期（terminate）里追踪并销毁每一个你创建的文件。让它优雅地来，优雅地走，好吗？”

人物三：GLaDOS（《传送门》系列中的 AI，冷酷、喜欢冷嘲热讽与测试）

“非常有意思的测试样本。我注意到你在 _create_context 里，如果注入 Cookie 失败了，你会直接把那个可怜的、孤立无援的浏览器上下文遗弃在内存里。它将永远占据着服务器的 RAM，直到系统因为内存耗尽而崩溃。作为一个人为制造的内存泄漏点，这真是令人赞叹的杰作。另外，你的 Plan A, B, C 寻找按钮的逻辑就像一只在迷宫里乱撞的小白鼠——虽然粗暴，但竟然奇迹般地有效。继续保持，我正在记录你的服务器宕机时间倒计时。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[xiaoruange39]

@astrpluginreviewer review