[Plugin] astrbot_plugin_bilibili_push

[ZASENJC]

插件信息

{
  "name": "astrbot_plugin_bilibili_push",
  "display_name": "B站解析推送助手",
  "desc": "一个简洁的 Bilibili 视频被动解析与订阅推送插件，支持扫码登录持久化 Cookie、视频/图文双发送策略。",
  "author": "ZASENJC",
  "repo": "https://github.com/ZASENJC/astrbot_plugin_bilibili_push",
  "tags": [
    "B站",
    "推送",
    "解析"
  ],
  "social_link": "https://github.com/ZASENJC"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_bilibili_push

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

main.py

1. 代码质量与编码规范

• 类型提示现代化 (Python 3.10+): 既然运行环境严格限定为 Python 3.10，代码中大量使用了 typing.List, typing.Dict, typing.Optional, typing.Tuple 等旧版类型注解。在 Python 3.10 中，推荐遵循 PEP 585 和 PEP 604，使用原生的 list, dict, tuple 以及管道符 |（如 str | None 代替 Optional[str]），以提升代码简洁度和可读性。
• 单文件体积过大 (God File): main.py 单个文件超过 1100 行，将数据模型（Dataclasses）、API 客户端（BilibiliService）、凭证管理（BilibiliCredentialManager）、业务逻辑（LinkResolver）以及插件主类（Main）全部耦合在一个文件中。建议按功能拆分为多文件结构（如 models.py, services.py, utils.py, main.py），以提升可维护性。

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

• 配置持久化逻辑失效: 在 _save_plugin_config 方法中：

  def _save_plugin_config(self) -> None:
      if hasattr(self.config, "save_config"):
          try:
              self.config.save_config()
          ...

  根据 AstrBot 插件标准，__init__ 中传入和保存的 self.config 是一个标准的 Python dict。原生 dict 并不存在 save_config 方法。因此，通过指令（如 /bili_parse_on 和 /bili_parse_off）修改的黑白名单仅在内存中生效，一旦机器人重启或插件重载，这些配置将会丢失。AstrBot 目前不支持插件侧直接通过方法写回 config.yaml，若需持久化动态黑白名单，建议将其存入类似 self.state_file 的本地 JSON 文件中。

3. 安全漏洞与最佳实践

• 子进程可能导致的资源泄漏 (FFmpeg): 在 merge_av 函数中调用了 FFmpeg 进行音视频合并：

  _, stderr = await process.communicate()

  尽管使用了安全的 create_subprocess_exec 避免了 Shell 注入，但缺少超时控制。如果下载的媒体流损坏导致 FFmpeg 挂起，或者因异常输入导致 FFmpeg 陷入等待状态，communicate() 将永远阻塞，进而导致僵尸进程和协程泄漏。最佳实践：应使用 asyncio.wait_for(process.communicate(), timeout=...) 包装它，并在超时后显式杀死进程（process.kill()）。

4. 潜在缺陷或问题

• 全局异常捕获可能掩盖关键错误: 在 extract_json_url 和 _attach_qq_emoji_reaction 中存在过度宽泛的异常捕获（except Exception: 且直接 pass 或返回 None），没有记录具体的错误堆栈。这在排查由于上游 API 结构变更导致的解析失败时会非常困难。建议至少使用 logger.debug 记录异常信息。
• 并发控制与请求频率: 监控轮询任务 _run_monitor_cycle 中使用了 await asyncio.sleep(...) 进行抖动延迟，这很好。但针对单次含有大量监控目标（Targets）的情况，_send_card_to_targets 内的 await self.context.send_message 是串行执行的。如果推送群组较多，由于缺乏并发（如 asyncio.gather），完成一轮推送的耗时可能会显著拉长。

---

代码评审团

Linus Torvalds：
“你把 1100 多行的代码塞进一个单一的 main.py 里，是打算让维护这玩意儿的人眼睛流血吗？这叫‘大泥球’架构！另外，那个 hasattr(self.config, "save_config") 是什么鬼？你指望一个标准的 Python 字典凭空长出保存方法来？这就像你对着一块石头喊‘自己把自己雕刻成雕像’一样荒谬。把你的持久化逻辑写进你自己管理的 JSON 里，别指望魔法发生。”

Gordon Ramsay (化身技术总监)：
“你在 merge_av 里的 FFmpeg 子进程简直就是一场灾难！IT'S RAW! 你没给它设置 timeout！如果视频流有问题，FFmpeg 挂起了怎么办？你的协程就会像平底锅上忘了翻面的牛排一样，永远卡在那里直到烧焦，拖垮整个内存！加上 asyncio.wait_for，如果它在 60 秒内没搞定，就给我把它 kill() 掉！立刻马上！”

GLaDOS：
“我已经扫描了你的代码。看到你还在坚持使用 typing.Optional 和 typing.List，让我感到十分欣慰——人类总是这么念旧，即使 Python 3.10 早就提供了更优雅的 | 和原生类型。这说明你的大脑在接受新语法方面存在令人遗憾的延迟。哦，顺便一提，你的黑白名单在下次系统重启时就会全部灰飞烟灭。不过没关系，反正人类的记忆也不比这持久多少。祝你在排查为什么配置不生效时度过愉快的一天。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：ZASENJC/astrbot_plugin_bilibili_push
剩余触发次数：4

[ZASENJC]

@astrpluginreviewer review

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_bilibili_push

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

main.py

1. 存在短链解析 SSRF 风险（高）

   • 位置：LinkResolver._normalize_candidate() → BilibiliService.resolve_short_url()
   • 问题：当前仅通过正则判断字符串形态后就直接 httpx.get(..., follow_redirects=True)。
     若构造如 https://b23.tv@127.0.0.1/ 这类 URL（userinfo 混淆），可能绕过“看起来是 b23.tv”的检查，实际请求内网主机。
   • 建议：在发起请求前用 urlparse 严格校验 hostname 必须属于白名单（b23.tv、bili2233.cn 等），并拒绝包含异常 userinfo/端口的 URL。

2. 监控基线初始化逻辑会导致重启后漏推送（高）

   • 位置：Main._check_uid_videos()
   • 问题：条件 if last_aid == 0 or uid not in self.session_initialized_uids 会在每次进程重启后首次轮询直接“重置基线并返回空”，即使状态文件已有 last_aid，仍会吞掉停机期间的新视频。
   • 建议：仅在 last_aid == 0 时初始化；若已有持久化基线，应按基线比较并推送差量。

3. 凭证锁粒度过大，异步并发下会造成串行阻塞（中）

   • 位置：BilibiliCredentialManager.get_credential()
   • 问题：在 asyncio.Lock 内执行多个网络 await（check_valid/check_refresh/refresh/get_self_info 间接触发），导致所有调用方（消息解析、轮询推送）排队等待，容易放大延迟。
   • 建议：将“共享状态读写”与“网络校验”拆分，缩小锁区间；或采用双重检查策略，避免锁内长耗时 I/O。

4. 登录凭证明文落盘且无权限收敛（中，安全）

   • 位置：BilibiliCredentialManager._save_credential()
   • 问题：Cookie 直接写入 JSON，未设置文件权限（如仅 owner 可读写），在多用户环境存在凭证泄露风险。
   • 建议：保存后显式设置最小权限（例如 POSIX 0o600），并在日志中避免输出任何敏感字段。

5. 媒体缓存清理与发送流程缺乏并发协调，存在竞态删除风险（中）

   • 位置：Main._cleanup_media_cache() 与 _send_card_to_targets() / on_message() 并发调用路径
   • 问题：多个协程可同时触发清理，keep_paths 只保护当前调用上下文路径，可能删除其他协程正在发送的视频文件，造成偶发发送失败。
   • 建议：为缓存清理增加全局异步锁，或引入“使用计数/租约”机制，发送完成后再释放并允许回收。

6. 主类职责过载，可维护性较差（中）

   • 位置：class Main(Star)
   • 问题：Main 同时承担配置、状态持久化、会话策略、指令处理、轮询调度、缓存管理、消息组装等大量职责，后续变更风险高、测试困难。
   • 建议：按职责拆分为独立组件（如 StateStore、MonitorScheduler、MessageBuilder、CacheManager），降低耦合。

---

代码评审团

人物一：Linus Torvalds（直球工程派）
“你这插件能跑、功能全，但 _check_uid_videos 这类基线逻辑把‘重启’这个最常见场景搞漏了，属于会让用户骂街的 bug。先把状态机理顺，再谈花活。”

人物二：Steve Jobs（产品体验派）
“用户不在乎你内部有多少配置项，他们只在乎‘为什么我漏了一条推送’。重启漏推送 + 偶发文件被删发送失败，都会直接损害信任感。把关键路径做成‘可预期’比做成‘功能多’更重要。”

人物三：Geralt of Rivia（猎魔人式风险嗅觉）
“我闻到了短链里的陷阱味道。凡是会主动请求外部 URL 的代码，都该先验明正身。域名白名单不严格，就像在夜里不点银剑灯——迟早出事。”

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

当前仓库：ZASENJC/astrbot_plugin_bilibili_push
剩余触发次数：3