[Plugin] astrbot_plugin_xbox

[xiaoruange39]

插件信息

{
  "name": "astrbot_plugin_xbox",
  "display_name": "Xbox Game Pass 入库提醒",
  "desc": "获取微软 Xbox Game Pass 最新入库游戏列表，支持后台定时推送新游提醒和手动查询。",
  "author": "xiaoruange39",
  "repo": "https://github.com/xiaoruange39/astrbot_plugin_xbox",
  "tags": [
    "Xbox",
    "游戏",
    "推送",
    "微软",
    "主机",
    "XGP",
    "西瓜皮"
  ],
  "social_link": "https://github.com/xiaoruange39"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_xbox

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

main.py

1. 数据持久化目录不符合框架规范（高优先级）
   当前使用 os.path.dirname(__file__) 作为 JSON 持久化目录（known_games.json / new_discovery.json / last_pushed_games.json）。
   按要求应通过 StarTools.get_data_dir() 获取 data/plugin_data/<plugin_name> 目录。
   影响：

   • 可能写入插件安装目录失败（只读环境常见）；
   • 升级/部署时数据易丢失；
   • 不符合 AstrBot 插件持久化约定。

2. 后台任务取消不完整，存在资源清理风险（中优先级）
   terminate() 里只 cancel() 了 poll_task 和 cron_task，但未 await 任务收尾（如 asyncio.gather(..., return_exceptions=True)）。
   影响：

   • 任务可能在取消后仍短暂运行；
   • 关闭阶段可能出现未处理取消异常日志噪音。

3. 多处使用裸 except，掩盖真实错误（中优先级）
   如删除临时文件处 except: pass。
   影响：

   • 调试困难，真实故障被静默吞掉；
   • 难以定位磁盘权限、文件占用等问题。

4. 状态集合与列表可能长期不一致（中优先级）
   known_games_list 被裁剪到 1000，但 known_games_set 只增不减。
   影响：

   • 内存集合持续增长；
   • “已知游戏”判定与持久化列表语义不一致，后续重新入库检测可能失真。

5. 新游戏顺序不稳定（低优先级）
   new_ids = [gid for gid in all_current_ids if gid not in self.known_games_set] 基于 set 迭代，顺序非确定。
   影响：

   • 推送内容顺序每次可能不同，不利于可预期展示。

6. 代码风格与可读性问题（低优先级）
   存在多处单行复合语句（如 if ...: ...）和过长函数（_fetch_game_details 逻辑过重）。
   影响：

   • 可维护性下降，后续改动风险增加。

7. 未使用导入（低优先级）
   MessageEventResult、Image 未被使用。
   影响：代码噪音，增加维护成本。

---

image_utils.py

1. 日志输出未接入框架 logger（中优先级）
   _find_chinese_font() 使用 print(...) 输出告警。
   影响：

   • 日志无法统一纳入 AstrBot 日志体系；
   • 线上排障可观测性弱。

2. 图片下载客户端创建方式低效（中优先级）
   _download_image() 每次调用都新建 httpx.AsyncClient()，且在 gather 并发下载时会创建多个短生命周期连接池。
   影响：

   • 连接复用差；
   • 并发时资源开销增大，易触发连接抖动。

3. 并发下载缺少限流控制（中优先级）
   asyncio.gather(*(fetch_poster(...) ...)) 无并发上限。
   影响：

   • 当 games 数量升高时，可能突发大量外部请求；
   • 触发远端限流或本地资源压力。

4. 异步函数中包含大量 CPU 密集图像处理（中优先级）
   generate_announcement_image() 在事件循环内执行大量 Pillow 绘制/缩放/合成。
   影响：

   • 阻塞事件循环；
   • 影响同进程其他异步任务响应。

5. 异常处理过宽，错误信息丢失（低优先级）
   多处 except Exception: pass/return None（如字体查找、logo 加载、图片下载）。
   影响：

   • 出错原因不可见；
   • 线上问题定位困难。

6. 渐变计算存在边界精度问题（低优先级）
   _draw_vertical_gradient() 使用 y / height，底部像素达不到理论终点色值（应考虑 height - 1）。
   影响：视觉上可能有轻微色差。

---

代码评审团

人物一：Linus Torvalds（暴躁务实流）
“把持久化文件扔在 __file__ 旁边是典型‘在我机器上能跑’写法。部署到只读目录你就知道什么叫痛。先把数据目录规范化，再谈功能。”

人物二：Steve Jobs（产品体验流）
“顺序不稳定的‘最近入库’会让用户觉得产品不可靠。信息展示应该稳定、可预期，否则再漂亮的海报也像随机广告墙。”

人物三：GLaDOS（冷幽默压测流）
“你把并发下载和图像重处理都塞进同一事件循环里，真是对延迟的勇敢实验。建议加并发闸门，并把重 CPU 绘图移出主 loop。这样系统会‘更不容易爆炸’。”

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

---

🔍 审核摘要

统计信息

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

main.py
image_utils.py

---

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

当前仓库：xiaoruange39/astrbot_plugin_xbox
剩余触发次数：4

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_xbox

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

main.py

1. 已知库裁剪导致“重复发现”误报（逻辑正确性）
   位置：_background_check
   问题：known_games_list 被限制为最多 1000 条（self.known_games_list = self.known_games_list[:1000]）。当真实库规模超过 1000 时，较老游戏会被“遗忘”，后续轮询又会被当作新入库。
   影响：定时推送/查询结果出现假阳性，长期运行后准确性下降。
   建议：将“去重基线”与“展示缓存”分离；基线集合应完整保留（或至少持久化更大窗口并标记首次发现时间）。

2. 临时文件清理缺少 finally 兜底（资源泄漏风险）
   位置：_perform_scheduled_push、_handle_xgp_query
   问题：临时图片文件在发送后才删除，但删除逻辑不在 finally。若中途异常/任务取消，文件可能残留。
   影响：长期运行可能积累临时文件。
   建议：将临时文件路径放入 try...finally，确保无论成功/失败/取消都清理。

3. JSON 加载缺少数据结构校验（健壮性）
   位置：_load_json_list
   问题：json.load 后直接返回，未验证是否为 list[str]。若文件被污染为 dict/嵌套结构，后续 set(...)、成员判断可能异常或行为错误。
   建议：加载后进行类型检查和元素类型过滤，不合法则回退为空列表并记录告警。

4. 批量详情请求串行执行，响应时间可明显变慢（性能瓶颈）
   位置：_fetch_game_details
   问题：按 20 个一批但串行请求；在网络波动时总体耗时线性增长。
   建议：为批次请求增加并发（如 asyncio.gather + 限流信号量），缩短命令响应和定时推送时延。

5. 共享状态无一致性保护（并发一致性）
   位置：self.new_discovery / self.last_pushed_games 在后台轮询、定时推送、指令查询之间共享
   问题：多个协程在不同 await 间交替读写同一列表，可能出现“读取快照不一致”（例如推送判断与实际详情列表不一致）。
   建议：读取前做快照副本，或用 asyncio.Lock 包裹关键读写区间。

---

image_utils.py

1. 远程图片未做体积/像素上限控制（安全与稳定性）
   位置：_download_image
   问题：对远程响应直接 Image.open + convert，未限制 Content-Length、像素总量或解码资源。
   影响：若遇到超大图/压缩炸弹，可能触发高内存占用或渲染阻塞。
   建议：下载前检查响应头大小，解码前后限制尺寸/像素，必要时拒绝异常大图。

2. 类型标注与实际返回不一致（可维护性）
   位置：_download_image(self, url: str) -> Image.Image
   问题：函数在异常分支返回 None，但签名声明只返回 Image.Image。
   影响：静态检查与阅读预期不一致，易引入误用。
   建议：改为 -> Image.Image | None（Python 3.10 合法）。

3. 并发下载聚合缺少容错隔离（健壮性）
   位置：generate_announcement_image 中 asyncio.gather(...)
   问题：若某个任务抛出未捕获异常，gather 会整体失败，导致整张公告图生成失败。
   建议：使用 return_exceptions=True 或在 fetch_poster 内做更严格异常兜底，保证“单图失败不拖垮整体”。

4. PEP 8 小问题：尾随空格
   位置：BADGE_GREEN = "#00a300" 、若干行末空格
   影响：影响代码整洁度与 lint 结果。
   建议：移除尾随空格，统一格式化。

---

代码评审团

人物一：Linus Torvalds（直球毒舌流）
“你这 known_games_list[:1000] 是把历史记忆主动删了，再惊呼‘怎么又是新游戏’。这不是发现，这是失忆。把‘历史基线’和‘展示窗口’分开，别让业务正确性给缓存策略背锅。”

人物二：Steve Jobs（产品体验流）
“用户只关心一件事：‘这条推送准不准、稳不稳。’ 临时文件清理不在 finally、详情请求串行拖慢响应，这些都在悄悄伤害体验。把失败路径设计成一等公民，产品质感会立刻上一个台阶。”

人物三：Tony Stark / 钢铁侠（工程实战流）
“远程图片直接吃进 PIL？兄弟，这就像给反应堆随便接来路不明的燃料。加尺寸阈值、像素上限、异常隔离，系统才能‘炸了一个组件但整机还飞得起来’。”

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

---

🔍 审核摘要

统计信息

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

main.py
image_utils.py

---

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

当前仓库：xiaoruange39/astrbot_plugin_xbox
剩余触发次数：3

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_xbox

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

main.py

1. 后台轮询在网络异常时会“破坏性清空”发现列表（逻辑缺陷）
   在 _background_check 中，无论本轮抓取是否成功，都会执行：

   self.new_discovery = [gid for gid in self.new_discovery if gid in all_current_ids_seen]

   当外部接口临时失败导致 all_current_ids_seen 为空时，会把历史 new_discovery 清空并持久化，造成状态回退/误判“无新游戏”。

2. 定时推送与手动查询的市场过滤不一致（功能正确性）
   new_discovery 来源于 US/HK/CN 多市场；但 _perform_scheduled_push 和 _handle_xgp_query 只用 US 的 PC/Console 列表做交集过滤。
   结果是：某些仅在 HK/CN 列表可见的条目会被错误过滤掉，导致“发现了但无法展示/推送”。

3. 临时图片文件删除时机可能过早（潜在资源/并发问题）
   在 _handle_xgp_query 和 _perform_scheduled_push 中，发送后仅 sleep(2/5) 就删除文件。若底层框架异步上传/延迟读取文件，可能出现“消息已发但文件已删”的竞态，导致发图失败。

4. display_limit 未做上限约束（稳定性风险）
   display_limit 来自配置，未限制最大值。若配置过大，会触发大量详情请求与超大图渲染，可能造成内存占用过高、渲染超时或阻塞事件循环可用性。

5. 初始化即创建长期后台任务，缺少启动失败回滚保护（可维护性）
   __init__ 中直接 asyncio.create_task(...) 启动两个无限循环任务；若后续初始化步骤抛异常，可能留下悬挂任务，增加排障复杂度。

---

image_utils.py

1. 下载图片存在 SSRF/内网探测面风险（安全）
   _download_image(url) 对 URL 来源未做域名白名单/协议约束（尽管当前来源看似官方接口）。一旦上游数据被污染，可能被用于访问内部地址（如云元数据地址）或异常目标。

2. Pillow 解码炸弹防护不完整（安全与稳定性）
   先 Image.open() 再检查像素，仍有触发解码炸弹/异常内存压力的窗口。建议显式处理 DecompressionBombError 或设置全局像素上限策略，而不只在打开后自行判断 w*h。

3. 图片渲染规模缺少硬限制（性能风险）
   _render_image 的画布尺寸随 games 数量线性增长；若上游传入过多条目，可能生成超大位图导致内存峰值过高（尤其在 JPEG 编码阶段）。

4. 字体探测在初始化阶段执行同步子进程调用（可用性）
   _find_chinese_font() 里 subprocess.run(fc-list...) 在对象初始化时同步执行。插件运行于异步系统中，这会拉长启动路径并影响并发响应（虽非网络 I/O，但会造成启动卡顿）。

---

代码评审团

人物一：Linus Torvalds（直球型）
“你这个 _background_check 在网络抖动时清空 new_discovery，这不是‘优雅降级’，这是‘优雅自毁’。状态机要抗失败，不是把失败写进数据库。建议：抓取失败时保留旧状态，只有当关键数据源成功返回后再提交新快照。”

人物二：Steve Jobs（产品体验型）
“用户看到的是‘怎么昨天还有入库，今天全没了？’ 这就是体验灾难。还有，发图后靠 sleep 再删文件是脆弱交互。建议：把图片转内存对象直传，或拿到底层发送完成回调再删除，确保‘它就是会稳定地工作’。”

人物三：Geralt of Rivia（猎魔人式务实）
“怪物不止一种：有的是 SSRF，有的是解码炸弹。你现在只是拿银剑砍了半截。建议：

• 限定可下载域名（微软 CDN 白名单）；
• 限定协议为 https；
• 对图像解码异常做专门拦截；
• 给 display_limit 设硬上限。
  打怪要补刀，别留后患。”

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

---

🔍 审核摘要

统计信息

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

main.py
image_utils.py

---

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

当前仓库：xiaoruange39/astrbot_plugin_xbox
剩余触发次数：2

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_xbox

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

main.py

1. known_games_set 可能无限增长（内存与状态漂移风险）

   • 你对 known_games_list 做了 5000 上限裁剪，但 known_games_set 只增不减。
   • 长期运行后，known_games_set 会持续膨胀，且与持久化文件内容不一致，影响可维护性与内存占用。
   • 建议：每次裁剪 known_games_list 后，重建 known_games_set = set(self.known_games_list) 并落盘。

2. 定时推送在“无有效 target_ids”场景可能重复空转

   • _perform_scheduled_push() 中若 push_on_update_only=True 且 new_discovery != last_pushed_games，会进入推送流程。
   • 但若 target_ids 为空会直接 return，且不会更新 last_pushed_games。结果是下次 cron 仍判定“有更新”，持续重复无效执行。
   • 建议：当确认本轮无可推送目标时，也应更新一个“已检查快照”或“最后检查版本戳”。

3. 后台任务共享状态缺少一致性保护

   • _background_check 会修改 self.new_discovery，同时命令查询与定时推送也会读取它。
   • 虽然是单线程事件循环，但跨 await 的并发切换仍可能造成读取到中间态（例如先过滤后追加期间）。
   • 建议：用 asyncio.Lock 包裹 new_discovery / known_games_* 的读写关键段，或统一采用不可变快照替换赋值。

4. JSON 持久化缺少原子写入，存在文件损坏窗口

   • _save_json_list 直接覆盖写，若进程中断/崩溃，可能写入半截文件，导致下次启动 JSON 解析失败。
   • 建议：写入临时文件后 os.replace 原子替换。

5. 异常捕获过宽，排障成本高

   • 多处 except Exception（如 _background_check, _perform_scheduled_push, _fetch_gamepass_lists）会吞掉具体故障类型，日志信息粒度不足。
   • 建议：优先捕获 httpx.TimeoutException、httpx.HTTPError、json.JSONDecodeError 等明确异常，并保留关键上下文（URL、market、batch ids）。

6. API 请求串行过多，整体时延偏高

   • _background_check 与 _fetch_all_library_ids 对多个 market/list 组合是顺序请求。
   • 异步环境下这会拉高周期执行时间，容易造成任务堆积或延迟推送。
   • 建议：用 asyncio.gather 并发拉取（注意控制并发上限）。

---

image_utils.py

1. 字体探测使用 subprocess.run 同步阻塞

   • _find_chinese_font 在非 Windows 下调用 fc-list 是同步阻塞，可能卡住事件循环启动阶段。
   • 虽非网络 I/O，但在异步插件场景会放大初始化延迟。
   • 建议：将探测放到线程（asyncio.to_thread）或增加缓存机制（首次探测后持久化路径）。

2. 重复下载重试策略过于粗糙，造成额外网络负载

   • fetch_poster 对同一 URL 固定重试 2 次，无退避、无错误类型区分。
   • 在远端限流/网络抖动时会放大失败流量。
   • 建议：仅对可重试错误（超时、5xx）重试，并加入短退避。

3. content-length 解析异常日志语义不准确

   • int(content_len) 若失败会落入 except (OSError, ValueError)，日志却写成“open downloaded image failed”，误导排障。
   • 建议：把 header 解析与图像解码异常分开捕获并分别记录。

4. Logo 读取未使用上下文管理器

   • Image.open(self.xbox_logo_path) 未用 with，依赖对象回收关闭资源。
   • 长期运行/频繁重载时，文件句柄释放时机不可控。
   • 建议：with Image.open(...) as im: 后再 convert/复制。

---

代码评审团

人物一：Linus Torvalds（直球工程派）
“你这插件逻辑能跑，但状态管理有点‘野生’：known_games_list 有上限，known_games_set 却无限长，这就是典型的‘看起来优化了，实际上没优化’。把数据结构一致性先做对，再谈功能迭代。”

人物二：Steve Jobs（产品体验派）
“用户只关心：‘为什么我每天都收到空推送检查，却没有结果？’ 这就是流程闭环没做完。target_ids 为空时不更新推送快照，会让系统反复做无意义动作。优秀产品是让无结果也有明确状态。”

人物三：Geralt of Rivia（猎魔人式务实派）
“我闻到了‘混沌异常捕获’的味道。except Exception 到处都是，战斗日志却不给线索。你得知道怪物是超时、限流还是坏数据，不然下次猎魔还是瞎砍。”

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

---

🔍 审核摘要

统计信息

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

main.py
image_utils.py

---

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

当前仓库：xiaoruange39/astrbot_plugin_xbox
剩余触发次数：1

[xiaoruange39]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_xbox

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

main.py

1. 并发读写共享状态存在竞态风险（逻辑一致性问题）
   self.new_discovery、self.known_games_list、self.known_games_set 会被多个协程同时访问/修改（_background_check、_cron_loop -> _perform_scheduled_push、xgp 查询）。
   当前仅在读取时做了浅拷贝快照，但没有任何锁保护，可能出现：

   • 推送时读取到“半更新”状态；
   • 后台更新与推送写入 last_pushed_games 交错，造成“漏推/重复推”。

2. push_on_update_only 的比较逻辑可能误判“无更新”
   使用 set(self.new_discovery) == set(self.last_pushed_games) 会忽略顺序变化。
   当“最近入库顺序变化但集合相同”时会被判定为无需推送，可能不符合“最近入库”场景预期。

3. 定时循环对配置变更响应不及时
   _cron_loop 在计算下次触发后直接 sleep(wait_seconds)，若期间管理员修改 cron_time/关闭推送，任务不会立刻感知，可能继续按旧计划执行一次。

4. 网络调用鲁棒性偏弱（易受瞬时失败影响）
   核心接口（列表与详情）失败后多数仅记录日志并返回空结果，缺少最基本重试/退避策略；在外部 API 抖动时，容易导致：

   • 误判“暂无新游戏”；
   • 定时推送直接跳过并刷新状态（可见性下降）。

---

image_utils.py

1. 异步环境中存在同步阻塞调用
   __init__ 中 _find_chinese_font() 调用了 subprocess.run(...)（fc-list），这是同步阻塞操作，会卡住事件循环线程，影响并发响应。

2. 图片解码后的内存峰值风险较高
   虽然限制了下载体积（10MB）和 MAX_IMAGE_PIXELS=25_000_000，但单张图解码后仍可能接近百 MB 内存。
   在一次生成中并发下载多张并统一持有 posters_raw，存在明显内存峰值压力，极端情况下可能触发 OOM 或性能抖动。

3. 异常可观测性不足（问题定位困难）
   generate_announcement_image() 里 asyncio.gather(..., return_exceptions=True) 后直接把异常结果当 None 丢弃，没有记录具体异常来源，线上排障会比较困难（只能看到“无封面”结果，看不到失败原因）。

4. 资源关闭不够显式
   多处 Image.open(...) 未使用上下文管理器（如 logo 加载、下载后打开），依赖 GC 回收文件句柄/底层资源。多数时候可用，但在高频生成场景下会增加资源回收不确定性。

---

代码评审团

人物一：Linus Torvalds（直给型）
你这主流程能跑，但共享状态不加锁这事属于“迟早踩坑”。异步不是魔法，竞态不会因为你写了 await 就消失。建议把 new_discovery/known_games 更新收敛到单入口，或者最少加 asyncio.Lock。

人物二：Steve Jobs（产品体验型）
你做的是“提醒”，用户在乎的是“为什么这次没提醒”。现在异常被吞、更新判定用 set，结果就是“看起来没问题，体验却不稳定”。建议强化可观测性：记录关键失败原因、保留推送决策日志链路。

人物三：Geralt of Rivia（猎魔人务实派）
怪物通常死于细节：fc-list 阻塞、图片内存峰值、批量下载后统一渲染。建议把“找字体”放到线程、对图片像素再降采样上限、必要时分批渲染，先保活，再谈华丽图效。

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

---

🔍 审核摘要

统计信息

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

main.py
image_utils.py

---

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

当前仓库：xiaoruange39/astrbot_plugin_xbox
剩余触发次数：0

[xiaoruange39]

已修改