[Plugin] astrbot_plugin_HWinfo

[IchijyoRaku]

插件信息

{
  "name": "astrbot_plugin_HWinfo",
  "display_name": "CPU显卡性能快速查询",
  "desc": "CPU的r23跑分查询，GPU timespy跑分查询，显卡天梯图，类似笔电xx性能相当于台式xx的问题解答",
  "author": "IchijyoRaku",
  "repo": "https://github.com/IchijyoRaku/astrbot_plugin_HWinfo",
  "tags": [
    "硬件",
    "CPU",
    "显卡",
    "笔电"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_HWinfo

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

main.py

1. 代码质量与编码规范

• 类型提示不完善：部分方法缺少返回值类型提示，例如 _image_chain 和 _send_rank_image。建议分别为其补充 -> list[Comp.Image] 和 -> AsyncGenerator 的类型标注，以提升代码的静态分析能力。
• 变量遮蔽与命名：在 _fuzzy_search_items 方法中，循环 for score, item in scored[:20]: 里的 score 遮蔽了外部同名局部变量。虽然在 Python 作用域规则下不构成致命错误，但降低了代码可读性。
• 字符串转换潜在陷阱：在 _format_item_detail 中，vendor = str(item.get("vendor", "")) 存在问题。如果 JSON 数据中 vendor 键的值显式为 null，item.get 会返回 None，str(None) 会变成字符串 "None"。随后执行 replace(vendor + ' ', ...) 时会引发非预期的行为。建议改为 vendor = item.get("vendor") or ""。

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

• Python 3.10 异常捕获版本兼容性缺陷（关键）：在 _handle_search 方法的超时处理中使用了 except TimeoutError:。在 Python 3.10 环境下，内置的 TimeoutError 与 asyncio.TimeoutError 是两个截然不同的异常类（直到 Python 3.11 才被合并）。由于底层 session_waiter 通常抛出的是 asyncio.TimeoutError，此处的 except TimeoutError: 将无法捕获超时异常，导致任务崩溃并产生未捕获的异常追踪。修复方案：需导入 import asyncio 并改为 except asyncio.TimeoutError:。
• 正则匹配不够严谨：在 _extract_model_core_and_suffix 中，正则表达式 r"(\d{3,5})([a-z0-9]*)" 会贪婪匹配第一次出现的 3-5 位数字。如果用户的查询语句包含干扰数字（例如 "买个 4000 块的 4060ti"），正则会错误地将 4000 提取为核心型号，导致匹配逻辑严重偏离。

3. 安全漏洞与最佳实践

• JSON 解析缺乏异常处理：_load_items 函数中使用了 json.loads(resolved_path.read_text(...)) 读取并解析本地数据。如果部署环境下的 JSON 文件格式损坏或不符合规范，这将在插件初始化（__init__）时抛出 json.JSONDecodeError，直接导致整个插件加载失败。建议包裹在 try...except 块中并辅以 logger.error 记录。
• 状态泄漏风险：在 _handle_search 中，self.pending_choices[user_id] 字典用于记录用户的交互状态。如果由于上述未捕获的 asyncio.TimeoutError 导致协程异常退出，底部的 self.pending_choices.pop 将不会执行，该用户的会话状态将变成僵尸数据，导致内存泄漏及后续交互的潜在状态冲突。

4. 可维护性与可读性

• 性能优化的空间：在 _format_item_detail 中，每次查询 CPU 多核分数都会调用 _find_cpu_multi_score，并在 self.cpu_multi_items 列表中进行 $O(N)$ 的线性遍历。建议在 __init__ 阶段预先构建一个以 display_name 为键、score 为值的字典索引，将查询时间复杂度降至 $O(1)$，提高高并发场景下的执行效率。
• 复杂的正则可读性低：compare_gpu 的 filter.regex 表达式较长且包含多个否定前瞻，虽然功能可以满足，但后期若需增加新规则维护成本较高，建议将复杂的匹配逻辑抽离为常数字符串并在注释中解释意图。

5. 潜在缺陷或问题

• 并发请求覆写：如果同一用户在上一个选择等待期间 (session_waiter 等待中) 再次触发查询，self.pending_choices[user_id] 会被新的候选列表无声覆写，但前一个 session_waiter 仍然挂起并在收到数字时处理，这会导致索引错乱或选出错误的结果。建议在触发新搜索时，主动检查并清理该用户先前的挂起状态或给出提示。

---

代码评审团

Linus Torvalds（Linux 之父，性格直率火爆、对低级错误零容忍）：

"这就是你们写的异常处理吗？except TimeoutError？在 Python 3.10 里，内置的 TimeoutError 是系统层面的 I/O 超时，而 asyncio.TimeoutError 才是协程超时！你这代码在超时的时候不仅什么都抓不到，还会把堆栈轨迹吐得满屏幕都是。还有那个 str(None) 变成 "None" 的破事，别把空指针包装成正常的字符串去糊弄机器！赶紧把 import asyncio 加上去，不要让我再看到这种未经验证的异常捕获了！"

Sherlock Holmes（大侦探，擅长通过细节推导全局缺陷）：

"华生，这真是一段有趣的逻辑。请留意 _find_cpu_multi_score 这个方法。每次当用户想要浏览那微不足道的详细信息时，程序都会像个迷路的新手一样，在 cpu_multi_items 列表里从头到尾进行线性对比。既然数据在启动时就已经加载，为什么不提前建立一个以名称为键的字典索引呢？从 $O(N)$ 到 $O(1)$ 的转变，就像在犯罪现场找到了一枚清晰的指纹一样优雅。而且，如果不小心输入了『买个 3000 元的 4090』，提取出的核心可是 3000 哦，这会让匹配系统完全被误导的。"

GLaDOS（《传送门》系列的人工智能，腹黑、热衷于测试与破坏）：

"检测到您正在毫无保护地使用 json.loads 加载外部文件。真是令人赞叹的乐观主义精神。显然，您假设运行环境中的文件永远不会损坏、永远格式完美。如果我稍微『不小心』在您的 r23single.json 结尾少写了一个括号，整个插件就会在启动瞬间壮烈牺牲。看着它连启动失败的优雅后路都没有，直接原地抛出 JSONDecodeError，还真是符合人类一贯的粗心大意呢。继续保持，别加 try-except，我很期待看到它崩溃的样子。"

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：IchijyoRaku/astrbot_plugin_HWinfo
剩余触发次数：4