[Plugin] astrbot_plugin_sts2_data

[YuWan886]

插件信息

{
  "name": "astrbot_plugin_sts2_data",
  "display_name": "STS2 Data",
  "desc": "查询杀戮尖塔2数据库信息。",
  "author": "YuWan886",
  "repo": "https://github.com/YuWan886/astrbot_plugin_sts2_data",
  "tags": [
    "杀戮尖塔",
    "查询工具"
  ],
  "social_link": "https://github.com/YuWan886"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sts2_data

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

main.py

1. 异常信息直接回显给用户，存在信息泄露风险

   • 代码：yield event.plain_result(f"Request failed: {exc}")
   • 问题：会把底层异常细节直接暴露到聊天侧，可能泄露请求参数、网络错误细节、内部实现信息。
   • 建议：对外返回通用错误文案，对内保留 logger.exception(...) 详细日志。

2. 查询解析逻辑存在误判风险

   • 代码：or "sts2" in first
   • 问题：只要首词包含 sts2 子串就会被当作命令前缀剥离，例如 mysts2test 也会触发，导致解析错误。
   • 建议：改为严格匹配命令词（如集合匹配），避免子串匹配。

3. 空关键词路径下可能触发“大列表请求 + 详细端点只展示首条”的逻辑偏差

   • 当用户只输入 endpoint（无 keyword）时会请求全量列表；而 format_response 对详细端点仅展示 data[0]。
   • 影响：用户看到的是“第一条”而不是“匹配结果”；同时可能造成不必要的大网络开销。
   • 建议：无 keyword 时优先提示补充关键词，或统一走列表展示并限制条数。

4. 编码规范问题（PEP 8）

   • 文件中多处顶层定义之间缺少标准空行（例如 import 块与装饰器/类定义之间），可读性和规范性受影响。

---

api_client.py

1. 每次请求都新建 aiohttp.ClientSession，连接复用不足

   • 问题：在异步高并发下频繁创建/销毁 session 会增加开销，影响性能和连接管理效率。
   • 建议：将 ClientSession 设计为客户端级长生命周期对象，在插件初始化/销毁阶段管理其创建与关闭。

2. 响应结构判断过于严格，易导致“静默空结果”

   • 代码：仅当 payload 是 list 才使用，否则直接 items = []。
   • 问题：若 API 返回 {"data": [...]} 或其他合法结构，将被误判为空，造成功能性错误且不易排查。
   • 建议：根据 API 实际协议做兼容解析，无法识别时记录明确告警日志。

3. 过宽的兜底异常捕获降低可维护性

   • except Exception as e 在已捕获多种 aiohttp 异常后仍存在，价值有限，且容易掩盖未预期错误类别。
   • 建议：保留必要异常分支，兜底异常至少增加上下文信息（endpoint/params）并谨慎使用。

4. 编码规范问题（PEP 8）

   • import 区块、类定义之间空行不足，建议按规范整理。

---

constants.py

1. EndpointConfig 使用 total=False 与使用方式不一致

   • 问题：类型上允许缺失 path，但业务代码中直接使用 endpoint_meta['path']，潜在 KeyError 风险被类型系统掩盖。
   • 建议：将必填字段改为必需（如 total=True 或拆分必填/可选配置类型），提高静态检查有效性。

2. 编码规范问题（PEP 8）

   • 顶层定义之间空行不足，影响可读性。

---

formatters.py

1. 详细端点展示策略可能导致结果误导

   • 代码：if endpoint in DETAILED_ENDPOINTS: yield from self._format_detailed(endpoint, data[0], event)
   • 问题：多条匹配时只展示第一条，没有任何“还有更多结果”提示，用户容易误解为唯一命中。
   • 建议：多结果时先返回候选列表，再允许二次查询详情；或至少提示总命中数。

2. 未对外部文本进行安全/展示层处理

   • 问题：description、name 等远端字段原样拼接输出，若平台支持 at/markdown/特殊控制字符，可能触发非预期展示或消息污染。
   • 建议：在输出前做基础转义/清洗（按 AstrBot 消息渲染规则）。

3. _format_list 的 endpoint 参数未使用

   • 问题：接口签名与实现不一致，增加维护噪音。
   • 建议：移除无用参数，或用于输出上下文信息（如“当前类型”）。

4. 编码规范问题（PEP 8）

   • 顶层 import、类定义之间空行不足。

---

models.py

1. 存在未被使用的模型映射与宽泛类型别名，维护收益较低

   • ENDPOINT_MODELS、ItemData、ItemList 当前未体现实质约束，且业务层主要使用 dict[str, Any]。
   • 影响：增加认知负担，类型定义与实际使用脱节。
   • 建议：要么在调用链中真正用起来（提升类型约束），要么精简无效抽象。

2. 编码规范问题（PEP 8）

   • 顶层定义间空行不足。

---

代码评审团

人物一：Linus Torvalds
“'sts2' in first 这种匹配方式太‘玄学’了。字符串子串判断不是命令解析器，严格 token 匹配才是工程化做法。把边界搞清楚，bug 数量能直接掉一截。”

人物二：Steve Jobs
“用户输入 /sts2 cards 却看到一条‘随机首项详情’，这是很糟糕的产品体验。交互应当可预期：要么要求关键词，要么返回可选择列表。体验不是附属品，是功能的一部分。”

人物三：GLaDOS（Portal）
“你每次请求都新建 ClientSession。真可爱。对于高并发来说，这像每次出门都重新造一辆车。复用连接池，不然性能测试会给你一块‘科学失败纪念蛋糕’。”

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

---

🔍 审核摘要

统计信息

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

main.py
api_client.py
constants.py
formatters.py
models.py

---

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

当前仓库：YuWan886/astrbot_plugin_sts2_data
剩余触发次数：4

[YuWan886]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sts2_data

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

以下是对您提供的 Slay the Spire 2 数据插件代码的审查报告。

main.py

• 功能实现与逻辑正确性 / 潜在缺陷或问题：
  • 严重的生命周期管理遗漏：在 Sts2DataPlugin 的构造函数中实例化了 STS2APIClient。该客户端类内部明确要求调用异步方法 start() 来初始化 aiohttp.ClientSession，并调用 close() 来释放资源。然而，在当前插件的 initialize() 和 terminate() 异步钩子中，完全没有调用这两个方法。这会导致用户发起任意指令时，self.api_client._get_session() 会直接抛出 RuntimeError("API client session is not initialized")，使插件功能完全不可用。
  • 修改建议：在 initialize 中添加 await self.api_client.start()，在 terminate 中添加 await self.api_client.close()。

api_client.py

• 潜在缺陷或问题：
  • 缺少 JSON 解析容错：在 fetch_endpoint 方法中，代码直接调用了 payload = await response.json()。虽然上方有 response.raise_for_status() 拦截了 HTTP 错误状态码，但如果服务端由于网络节点、反爬网关等原因，在 200 状态码下返回了 HTML 或文本内容，该操作会抛出异常。建议捕获 aiohttp.ContentTypeError，以便于更精确地记录异常原因而不是向外抛出泛型错误。
• 代码质量与编码规范：
  • 异常重抛姿势不规范：在处理超时异常时写了 except asyncio.TimeoutError as exc: raise exc。Python 的最佳实践要求在此类场景下直接使用无参数的 raise，这样能最原汁原味地保留原始的上下文追踪栈（Traceback），虽然 Python 3 在此有所优化，但保持 raise 仍是遵循 PEP 8 和社区规范的做法。

formatters.py

• 代码质量与编码规范：
  • 不必要的局部导入：在 format_help 静态方法内部使用了局部导入 from .constants import ENDPOINTS。考虑到该文件顶部已经存在 from .constants import DETAILED_ENDPOINTS, MAX_LIST_ITEMS，且并不存在循环导入（Circular Import）的风险，建议将 ENDPOINTS 移至文件顶部的全局导入部分，以保持代码头部的整洁性和依赖的可见性。

constants.py

• 审查通过。未发现明显质量、安全或逻辑问题，变量常量分离得很好。

models.py

• 审查通过。未发现明显问题，TypedDict 使用得当，结构清晰。

---

代码评审团

Linus Torvalds：
看看你的 main.py！你费尽心思在 api_client.py 里写了优雅的 start() 和 close() 去管理异步会话池，结果在生命周期里连调用都懒得调用？你是觉得 ClientSession 会在运行时靠环境中的游离电子完成自我初始化吗？这代码一跑起来就直接吃 RuntimeError，下次提交前先自己把代码跑通！

Steve Jobs：
你的代码大体上很有条理，我喜欢你将请求和格式化拆分开的设计哲学。但是，在 api_client.py 里的细节还不够“完美”。当你捕获一个 asyncio.TimeoutError 的时候，为什么还要画蛇添足地写个 raise exc？优雅的做法是只需轻轻敲下 raise，让底层的栈自然地流露出来。另外，别轻易相信服务端永远会给你返回漂亮的 JSON，加个 ContentTypeError 保护一下用户的体验好吗？

罗永浩：
这个 models.py 和 constants.py 里的 Type Hint 用得还是很讲究的，体现了现代 Python 开发的“工匠精神”，给你点个赞。不过那个 formatters.py 里，你在函数内部去 import ENDPOINTS 是怕谁偷了你的常量吗？既然顶部已经 import 了同一个文件里的东西，就大大方方全放上面去，整整齐齐地看着不好吗？少点这种局部的小心思，代码看着会更敞亮。

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

---

🔍 审核摘要

统计信息

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

main.py
api_client.py
constants.py
formatters.py
models.py

---

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

当前仓库：YuWan886/astrbot_plugin_sts2_data
剩余触发次数：3

[YuWan886]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sts2_data

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

main.py

1. 异步取消信号被吞掉的风险
   • sts2_query 中使用了 except Exception: 兜底，这在 Python 3.10 下会把 asyncio.CancelledError 一并捕获，可能导致任务取消失效，影响框架的协程调度与优雅退出。
   • 建议：单独 except asyncio.CancelledError: raise，其余异常再统一记录并返回用户提示。

---

api_client.py

1. start() 存在并发竞态，可能造成 Session 泄漏

   • start() 里先判断 _session is None or closed 再创建 ClientSession，若并发调用，可能创建多个 session，后创建者覆盖前创建者引用，前者无法被正常关闭。
   • 建议：为 start()/close() 增加 asyncio.Lock 保护，或在插件生命周期中确保只会串行调用。

2. 返回数据结构缺少运行时校验，后续可能触发 AttributeError

   • _extract_items() 在 payload 为 list 时直接返回，未校验元素是否为 dict；而后续 _filter_items() 与 formatter 大量使用 item.get(...)。
   • 一旦 API 返回混合列表（如字符串、数字），会在运行时崩溃。
   • 建议：在 _extract_items() 或 _filter_items() 过滤非 dict 元素，保证返回类型与注解一致。

---

constants.py

未发现需报告的问题。

---

formatters.py

1. 列表格式化对元素类型过度信任
   • _format_list() 使用列表推导直接 item.get(...)，若上游传入非 dict 元素会抛异常。
   • 建议：在此处增加 isinstance(item, dict) 防御式判断，避免因上游异常数据导致整个指令失败。

---

models.py

未发现需报告的问题。

---

代码评审团

人物一：Linus Torvalds
“你这异常处理有点像 catch-all and pray。except Exception 在异步代码里很容易把取消语义干碎。让取消就取消，别跟调度器对着干。把 CancelledError 放行，这是基本礼貌。”

人物二：Steve Jobs
“用户看到的是‘请求失败，请稍后重试’，但工程上你需要更精致的内部质量。ClientSession 并发初始化竞态会制造‘看不见的脏东西’——这种问题最伤产品稳定性。把生命周期打磨到‘it just works’。”

人物三：Geralt of Rivia（猎魔人）
“怪物图鉴里混进了假目标（非 dict 数据）你就直接挥剑（.get）——容易砍空。先验明正身再出手，类型守卫做了，战斗才稳。”

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

---

🔍 审核摘要

统计信息

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

main.py
api_client.py
constants.py
formatters.py
models.py

---

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

当前仓库：YuWan886/astrbot_plugin_sts2_data
剩余触发次数：2

[YuWan886]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sts2_data

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

main.py

1. 潜在生命周期缺陷：依赖 initialize() 先于命令执行
   • sts2_query() 直接调用 self.api_client.fetch_endpoint(...)，而 fetch_endpoint 内部依赖已初始化的 session。
   • 若框架在某些场景下未先调用 initialize()（或初始化失败后仍触发命令），会触发 RuntimeError("API client session is not initialized")，当前仅被通用 except Exception 吞掉并返回“请求失败”。
   • 影响：问题定位困难、用户侧表现为随机失败。
   • 建议：在 fetch_endpoint 中做懒初始化，或在 sts2_query 前显式确保 start() 已完成（带并发安全保护）。

---

api_client.py

1. 返回数据结构校验不一致，可能导致上游格式化阶段崩溃

   • _extract_items() 对 payload 为 list 时会过滤为 dict；但对 payload["data"] / payload["items"] 为 list 时未过滤元素类型，可能返回非 dict 项。
   • 上游 formatters 的详细格式化路径会直接 item.get(...)，若 item 非字典会抛异常。
   • 建议：统一对所有 list 分支做 isinstance(item, dict) 过滤。

2. 图片 URL 规范化缺少协议白名单

   • normalize_image_url() 对非 / 开头 URL 直接原样返回，未限制 scheme（如 javascript:、data:、file:）。
   • 影响：若上游数据源异常/被污染，可能把危险 URL 传给 event.image_result（具体风险取决于 AstrBot/客户端实现）。
   • 建议：仅允许 http:// 与 https://（必要时再加可信域名校验）。

---

constants.py

未发现需要报告的问题。

---

formatters.py

1. 空消息输出风险

   • _format_list() 仅收集 dict 项；若 items 全是非 dict，lines 将为空，最终 yield event.plain_result("")。
   • 影响：用户看到空响应，体验与可观测性较差。
   • 建议：当 lines 为空时返回明确提示（例如“数据格式异常，请稍后重试”）。

2. 与 api_client 的类型契约过于脆弱

   • 详细格式化函数默认 item 为 dict[str, Any]，未做运行时保护；一旦上游返回脏数据（见 api_client 问题），会触发异常。
   • 建议：在 format_response 或 _format_detailed 前增加 isinstance(item, dict) 防御式检查。

---

models.py

未发现需要报告的问题。

---

代码评审团

人物一：Linus Torvalds
“你这异步结构总体干净，但类型边界有点‘想当然’。_extract_items 一半严谨一半随缘，后面 formatter 就只能赌运气。建议把输入契约守死：不合格数据一律过滤或告警，不要把雷埋给下游。”

人物二：Steve Jobs
“用户不该看到空白回复，也不该只得到‘请求失败’这种笼统反馈。产品体验是细节堆出来的：初始化失败、数据格式异常、网络错误，应该给用户不同但简洁的提示。”

人物三：Tony Stark（钢铁侠）
“normalize_image_url 这块像是把门禁卡借给陌生人。至少做协议白名单，最好再做域名可信校验。安全这件事，别等出事了再‘紧急修复 Mark 42’。”

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

---

🔍 审核摘要

统计信息

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

main.py
api_client.py
constants.py
formatters.py
models.py

---

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

当前仓库：YuWan886/astrbot_plugin_sts2_data
剩余触发次数：1

[YuWan886]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_sts2_data

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

main.py

1. 可维护性问题（命令解析分支可能“不可达”）
   _parse_query() 中支持了 yw-sts2、/yw-sts2 前缀，但当前仅注册了 @filter.command("sts2")。在常见命令路由模型下，这些别名前缀未必会进入该处理器，导致这部分解析逻辑可能成为“死分支”，增加后续维护认知成本。

2. 异常处理过宽导致可观测性不足
   sts2_query() 里使用 except Exception: 统一兜底并返回“请求失败”，会掩盖可区分的错误场景（如超时、上游 4xx/5xx、数据格式错误），不利于排障与精细化用户提示。

---

api_client.py

1. 潜在安全风险（外部 URL 信任过宽）
   normalize_image_url() 对绝对 URL 只要是 http:// 或 https:// 就直接放行，未限制域名来源。若上游数据被污染，可能输出攻击者控制的 URL；在某些平台存在服务端拉取图片时，可能引入 SSRF/内网探测风险。

2. 健壮性问题（响应体大小无保护）
   fetch_endpoint() 中直接 await response.json()，未设置响应体大小保护策略。若上游异常返回超大 JSON，可能在异步 worker 中造成内存压力。

---

constants.py

未发现符合本轮审查规则的明确问题。

---

formatters.py

1. 输出一致性问题（中英混用）
   _format_list() 中尾部提示使用英文 "...and N more"，与整体中文输出风格不一致，影响用户体验一致性与可维护性（后续国际化时也更难统一）。

2. 消息长度控制缺失
   多处直接拼接 description/options 等字段，未做单字段或整条消息长度上限控制。遇到超长文本时可能导致平台发送失败、截断不可控或刷屏风险。

---

models.py

未发现符合本轮审查规则的明确问题。

---

代码评审团

人物一：Linus Torvalds
“你这异常处理像把所有编译错误都写成 something went wrong。能跑不代表好维护。把超时、HTTP错误、解析错误拆开，日志和用户提示都能精准很多，后面你自己会感谢现在的你。”

人物二：Steve Jobs
“产品体验在细节里：大部分文案是中文，却突然来一句 ...and N more，这会破坏质感。统一语言风格，用户会觉得这个插件是‘被设计过的’，而不是‘凑出来的’。”

人物三：Deadpool（死侍）
“我看到你信任所有 http(s) 图片链接就像信任反派说‘我这次真的改邪归正’。建议只放行白名单域名，不然某天你会把用户带去一个‘惊喜’页面——而且不是彩蛋那种。”

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

---

🔍 审核摘要

统计信息

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

main.py
api_client.py
constants.py
formatters.py
models.py

---

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

当前仓库：YuWan886/astrbot_plugin_sts2_data
剩余触发次数：0

[astrbot-plugin-copybara]

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

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