[Plugin] astrbot_plugin_r6states

[Diekeng]

插件信息

{
  "name": "astrbot_plugin_r6states",
  "display_name": "彩虹六号查询工具",
  "desc": "查询彩虹六号的玩家战绩、游戏百科和电竞信息，nonebot-plugin-R6States的astrbot移植版",
  "author": "Throstle",
  "repo": "https://github.com/Diekeng/astrbot_plugin_r6states",
  "tags": [
    "游戏",
    "查询工具",
    "彩虹六号"
  ]
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_r6states

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

main.py

1. 硬编码敏感信息（高风险）
   r6m_command 和 query_r6_esports_matches 中使用了硬编码的 Pandascore API Key 默认值：

   self.config.get("pandascore_api_key", "fWWv_...")

   这会导致密钥泄露风险，并且一旦代码公开，密钥可被滥用。

2. 命令权限控制缺失（安全/运维风险）
   @filter.command("r6dapi") 允许任何可调用该命令的用户直接修改 API Key。
   代码注释写“管理员或WebUI配置”，但实现中没有权限验证，存在配置被恶意篡改风险。

3. 参数定义与实际逻辑不一致（功能正确性）
   argparse 中定义了 -m/--map 和 -f/--full，但后续逻辑完全未使用。
   这会导致用户误以为参数生效，实际行为与帮助文本不一致。

4. 异常处理方式不规范（可维护性）
   query_player_overview 中混用 logger.error(...) 与 traceback.print_exc()。
   后者会直接向标准输出打印堆栈，无法统一到框架日志管线，不利于线上排障与日志收敛。

5. 组队查询串行执行（性能）
   -g 模式下对多个 ID 逐个 await，最多 5 个请求全部串行。
   在异步环境下会增加总体响应时间，尤其是外部 API 延迟较高时。

6. 未使用导入（代码质量）
   List 与 format_operator_stats 被导入但未使用，增加噪音并降低可读性。

---

fetcher.py

1. 裸 except 吞异常（高优先级）
   fetch_pandascore_matches 内部 _fetch 使用：

   except:
       return None

   会吞掉所有异常（包括编程错误），导致故障根因被掩盖，且上层只能得到“找不到队伍/赛区”的误导性结果。

2. 异常语义被错误降级（功能正确性）
   _fetch 出错返回 None 后，主流程常落入“未找到匹配”分支，网络错误/鉴权失败会被误报为查询词不存在。

3. response.json() 解析异常未覆盖（潜在崩溃）
   fetch_r6data 只捕获 httpx.HTTPError，若服务端返回非 JSON 或 JSON 结构异常，response.json() 可能抛异常，导致调用链失败。

4. 重复创建 httpx.AsyncClient（性能）
   每次请求都新建 AsyncClient，无法复用连接池，增加 TLS/连接开销。
   在高频命令场景会放大延迟和资源消耗。

5. 未使用导入（代码质量）
   asyncio、List 未使用。

---

formatter_wiki.py

1. 类型假设不稳健（潜在运行时异常）
   format_operator_info/format_weapon_info/format_map_info 注解为 List[Dict]，但实际也接收错误字典。
   若传入的是非预期结构（例如普通 dict 且不含 "error"），_find_exact 中 item.get(...) 可能触发异常。

2. 错误判断不严谨（逻辑边界）
   多处使用 if not data or "error" in data:。
   当 data 类型不符（如 None 或非 mapping/list）时，"error" in data 可能触发 TypeError。

3. PEP8 可读性问题
   存在单行复合语句（如 if not data: return None），降低可维护性。

4. 未使用导入（代码质量）
   datetime 未使用。

---

formatter.py

1. 深层索引未做防御式访问（高优先级）
   format_new_overview 中多处直接索引：

   board["full_profiles"][0]
   ops_data["split"]["pc"]["playlists"]

   一旦 API 返回结构缺失/为空，会触发 KeyError/IndexError，导致整条命令失败。

2. 输出文案格式错误（功能细节）
   文本：

   "🔫 [本赛季或生涯最常用干员喵"

   缺失右括号，属于可见的格式缺陷。

3. 宽泛异常捕获（可维护性）
   format_match_history 中 except: 未限定异常类型，可能掩盖非预期编程错误。

4. 未使用代码/导入（代码质量）
   clean_number 未被调用；Dict、List 导入未使用。

---

formatter2.py

1. 对外部数据结构的强耦合导致高崩溃风险（高优先级）
   函数直接访问：

   data["split"]["pc"]["playlists"]["quickmatch"]["operators"]

   无任何空值或键存在性校验，API 轻微变动或字段缺失即 KeyError。

2. 缺乏错误返回分支（功能健壮性）
   未处理 "error"、空数据、非 dict 输入等情况；在真实网络环境中稳定性不足。

---

formatter3.py

1. 宽泛异常捕获（可维护性）
   时间解析处使用 except:，会吞掉所有异常类型，降低问题定位能力。

2. 输入健壮性不足（边界问题）
   若 data 非 dict（如 None），"error" in data 会触发 TypeError；函数未做类型防御。

3. PEP8 可读性问题
   存在单行条件拼接语句（if serie_name: ... / if tourn_name: ...），在复杂文本构建逻辑中可读性偏弱。

---

代码评审团

人物一：Linus Torvalds
“你这异常处理有点‘把灰尘扫地毯下面’的味道。except: 到处抓，最后用户只看到‘没找到’，开发者却找不到为什么。建议：把网络错误、鉴权错误、数据解析错误分开处理，不要拿同一个‘None’糊过去。”

人物二：Steve Jobs
“用户体验层面最大问题是‘承诺了功能但没兑现’：-m、-f 参数写在说明里却不生效。产品上这会直接损伤信任。建议：要么尽快实现参数语义，要么从帮助里删掉，保持界面与行为一致。”

人物三：Geralt of Rivia（杰洛特）
“我见过的怪物里，最棘手的是‘看起来正常，突然暴毙’。board["full_profiles"][0] 这种写法就是。接口一抖就炸。建议：所有外部 JSON 都先做结构探测（get + 类型判断），宁可返回‘数据不完整’，也别直接抛 KeyError 让用户挨刀。”

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

---

🔍 审核摘要

统计信息

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

main.py
fetcher.py
formatter_wiki.py
formatter.py
formatter2.py
formatter3.py

---

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

当前仓库：Diekeng/astrbot_plugin_r6states
剩余触发次数：4

[Diekeng]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_r6states

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

main.py

1. 帮助信息与参数解析不一致（功能正确性）

   • -h 帮助文本中写了 -m, --map，但 argparse 实际并未定义该参数。
   • 结果是用户按帮助使用会触发“参数解析错误”，属于明显的 UX/逻辑不一致。

2. /r6dapi 缺少权限控制（安全性）

   • 方法注释写“管理员配置”，但实现上没有任何权限装饰器或鉴权判断。
   • 任意用户可覆盖 API Key，存在配置污染和服务可用性风险。

3. 部分命令缺少缺参兜底（边界条件）

   • r6h_command/r6op_command/r6map_command/r6w_command 直接要求位置参数。
   • 当用户漏参时，依赖框架层报错，插件内没有统一友好提示，容易出现不可控报错体验。

4. 聚合查询时对 ops_data 错误无显式处理（逻辑完整性）

   • query_player_overview 只判断 stats_data["error"]，ops_data 出错会被静默吞掉并继续格式化，可能输出“看似成功但内容残缺”的结果。

---

fetcher.py

1. 每次请求都新建 httpx.AsyncClient（性能/资源效率）

   • _fetch 内部每次调用都 AsyncClient(...)，高频调用下会反复创建/销毁连接池，增加延迟和资源开销。
   • 在异步场景下这会明显影响吞吐和响应时间。

2. 错误被“降级吞没”，导致误导性结果（逻辑正确性）

   • fetch_pandascore_matches 在多个分支中把 _fetch 的错误结果（dict + error）转换为空列表继续流程，最终可能返回“找不到队伍/赛区”，掩盖真实 API 故障。

3. 异常信息透传给用户（安全最佳实践）

   • _fetch 的兜底异常返回 {"error": f"系统内部错误: {str(e)}"}，把内部异常细节暴露到用户可见层，不利于安全与运维隔离。

4. fetch_r6_wiki 未做空 API Key 前置校验（边界处理）

   • 与 fetch_r6data 的校验策略不一致，空 key 会直接发请求并触发远端鉴权错误，增加无意义网络请求和噪音日志。

---

formatter_wiki.py

1. _find_exact 找不到精确匹配时直接返回首项（功能正确性）

   • 这会把“未命中查询”伪装成“命中结果”，容易返回错误实体（尤其同类数据较多时）。

2. format_weapon_info / format_map_info 未处理后端错误字典（错误可观测性）

   • 当上游返回 {"error": ...} 时，这两个函数会统一返回“未找到”，丢失真实错误信息（如鉴权失败、网络异常）。

3. format_seasons_info 对数据结构假设过强（健壮性）

   • ', '.join(s.get('operators', [])) 在 operators 非 list[str]（如 None、数字列表）时可能抛异常或输出异常内容。

---

formatter.py

1. format_match_history 对数值类型缺少防御（潜在运行时异常）

   • curr_val - prev_val 默认假设两者可做减法；若上游返回字符串或 None，将触发 TypeError，且未捕获。

2. clean_number 与 Dict 导入未使用（可维护性）

   • 存在未使用函数/导入，增加维护噪音，降低代码可读性。

3. 干员胜率计算对脏数据不鲁棒（逻辑边界）

   • losses = p_count - w 默认 w <= p_count，上游若给出异常数据会出现负数并导致不合理胜率。

---

formatter2.py

1. 深层字典直接索引，缺少任何容错（稳定性）

   • data["split"]["pc"]["playlists"]["quickmatch"]["operators"] 任一层缺失都会 KeyError。
   • 在外部 API 数据结构变动/字段缺失时会直接崩溃。

2. 对输入类型和字段类型无校验（边界条件）

   • operators.values()、op["rounds"]["lifetime"] 等均假设结构绝对正确，异常数据会触发连锁异常。

---

formatter3.py

1. 实体类型判定默认回落“赛区”（语义正确性）

   • t_type = "战队" if type == "team" else "赛区"，当 type 缺失或为未知值时会误标为赛区，输出语义不准确。

2. 比赛列表中无有效项时仍输出“近期赛事”标题（结果一致性）

   • matches 列表存在但元素都非 dict 时，会返回空内容标题而非“无有效赛事数据”，对调用方/用户有误导性。

---

代码评审团

人物一：Linus Torvalds
“你这代码能跑，但有几处‘静默失败’太危险了。最糟糕的 bug 不是崩溃，而是给出看起来正常、实际上错误的结果。_find_exact 回退首项、PandaScore 错误被吃掉，这类问题会让排查地狱化。建议：错误就明确报错，不要猜。”

人物二：Steve Jobs
“用户体验上有个硬伤：帮助文案告诉用户 -m，实际却不支持。这个会直接摧毁信任感。接口层要做到‘所见即所得’，命令提示、参数解析、错误提示三者必须统一。你离‘It just works’只差这些细节。”

人物三：Geralt（利维亚的杰洛特，虚拟角色）
“我见过很多怪物，最难杀的是‘偶发异常’。formatter2.py 这种深层硬索引，一旦上游数据抖一下就会爆。给每层加防具（.get + 类型检查）再上战场，不然每次 API 变动你都得喝药重开。”

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

---

🔍 审核摘要

统计信息

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

main.py
fetcher.py
formatter_wiki.py
formatter.py
formatter2.py
formatter3.py

---

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

当前仓库：Diekeng/astrbot_plugin_r6states
剩余触发次数：3

[astrbot-plugin-copybara]

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

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