[Plugin] astrbot_plugin_bilibanshi

[Xuewu-awa]

插件信息

{
  "name": "astrbot_plugin_bilibanshi",
  "display_name": "b站搬石",
  "desc": "让你的bot在b站搬石",
  "author": "雪雾",
  "repo": "https://github.com/Xuewu-awa/astrbot_plugin_bilibanshi"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_bilibanshi

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

main.py

版本与运行环境（Python 3.10 / 异步环境）

• asyncio.get_event_loop() 在协程上下文中使用不佳：多处在协程里调用 asyncio.get_event_loop()（如 _search_videos_by_keyword/_get_video_urls/_download_file）。在 Python 3.10 的异步最佳实践中应使用 asyncio.get_running_loop()，避免在不同运行器/线程策略下拿到非预期的 loop。

---

框架适应性检查

• 数据持久化目录不规范（硬编码路径）：配置与下载目录使用 Path("data") / "plugins" / ... 硬编码；按要求应通过 StarTools.get_data_dir() 获取 data/plugin_data/<plugin_name> 下的规范目录来存放配置与数据，否则在不同部署/多实例/权限环境下容易出问题。
• 网络 I/O 的并发模型存在“伪异步”与资源浪费风险（虽然你用 run_in_executor 避开了阻塞主事件循环，但仍有问题）：
  • 每次请求都新建 requests.Session()（如 _get_video_urls/_download_file），会导致连接复用差、线程池任务频繁创建连接，吞吐和稳定性都受影响。
  • run_in_executor(None, ...) 使用默认线程池，定时任务+群发+下载时可能堆积大量线程池任务；代码未做并发上限控制（例如信号量），高负载时可能拖垮 bot。

---

安全漏洞与最佳实践

• 命令执行存在注入与可移植性风险：_merge_video_audio 使用 asyncio.create_subprocess_shell(cmd) 且 cmd 由字符串拼接得到。尽管你对 title 做了部分清理，但仍不如 create_subprocess_exec([...]) 安全可靠；同时 shell 解析在不同平台行为差异大。
• 对外部内容的解析较脆弱，且缺少防御性校验：
  • _get_video_urls 通过正则抓取 window.__playinfo__=(.*?)</script> 并 json.loads，HTML 结构变动/脚本截断/转义都可能导致解析失败；失败路径目前只返回 None，上层有些地方未完整处理（见“逻辑正确性”）。
  • 未设置任何“可接受的域名/协议”白名单或校验；虽然来源是 B 站页面，但最终下载 URL 来自页面 JSON，理论上可能出现重定向到异常地址时的风险（至少应校验 scheme/host）。

---

功能实现与逻辑正确性（边界条件/明显缺陷）

• 音频 URL 为空时未提前拦截：_download_video 里只检查了 video_url，但没有检查 audio_url。当 audio_url 为 None 时，_download_file(audio_url, ...) 会触发异常或失败，错误日志会变得不直观。
• 临时文件管理可能导致列表无限增长：
  • self.temp_files 会不断 extend([video_temp, audio_temp, output_path])，但成功合并/成功删除后并不会从 self.temp_files 移除；长时间运行会导致该列表持续增长（内存与无效清理尝试）。
• 配置写入存在竞态与损坏风险：
  • on_group_message 在群消息触发时可能高频写 config.json；同时其它命令也可能写配置。当前没有任何锁（如 asyncio.Lock）保护，存在并发写入导致 JSON 文件损坏/写入丢失的风险。
• 取消任务时吞异常过宽：
  • terminate/turn_off 中对 await self.task 使用裸 except: 吞掉所有异常，可能掩盖真实错误；同时也不区分 asyncio.CancelledError 与其它异常，排障困难。
• 定时任务的异常恢复粒度偏粗：
  • _timer_task 把整个 _scan_and_download() 包在一个 try 中，任何异常都会进入 sleep；但内部下载/发送等阶段缺乏更细粒度的错误处理与重试策略，导致偶发网络波动时行为不可控（要么沉默失败，要么频繁重复失败）。

---

代码质量与编码规范（PEP 8 / 可读性）

• 导入与未使用项问题：
  • time 未使用；Any、List 等类型在部分函数未充分使用或不一致（如某些返回值未注解/注解不完整）。
• 函数职责偏重、流程过长：
  • _scan_and_download 同时承担“挑选/提示/下载/发送/清理”等多个职责，且包含 yield 分支使其成为 async generator；维护成本高，出错时定位困难。
• 命名与语义：
  • 部分命令名如 "bilibanshi h" / "bilibanshi -h" 语义不自解释，且 -h 容易与“help”习惯混淆；同时这类“带空格的命令字符串”在不同命令解析器实现下可能存在匹配歧义（取决于 AstrBot 的命令匹配规则）。

---

潜在缺陷 / 性能瓶颈（网络侧）

• 下载与群发缺少并发与速率控制策略：
  • _send_to_all_groups 对每个群 await asyncio.sleep(2) 是固定节流，但当群数量大时会导致“单次任务耗时极长”，下一轮定时扫描可能叠加（尤其当下载也变慢时）。
  • 下载采用线程池执行同步 requests，如果同时触发 /bilibanshi now 与定时任务，可能竞争线程池资源造成整体卡顿。
• 请求超时策略不一致：
  • 搜索 API 用 timeout=10，下载用 timeout=30，但未设置 read/connect 分离超时（requests 支持元组），在网络抖动时可能长时间卡在线程池里。

---

代码评审团

人物一（Linus Torvalds，毒舌直指核心）
你这套“异步 + requests + 线程池”本质是把阻塞 I/O 丢给线程硬扛：能跑，但一旦群多、任务多，线程池就会变成垃圾场。至少给下载与搜索加并发上限（信号量）和全局 Session 复用，不然稳定性靠运气。

人物二（Guido van Rossum，偏语言/可维护性视角）
_scan_and_download 既是业务流程又是 async generator，还混杂了“定时任务”和“命令触发”的两套行为分支，读起来很费劲。建议拆成：选择目标、下载、发送（当前会话/所有群）、清理四个纯协程函数，让控制流更线性，错误处理也更清晰。

人物三（Steve Jobs，偏产品与体验一致性）
路径硬编码到 data/plugins/... 这种细节会在部署时狠狠背刺用户：迁移、备份、多实例都不优雅。按框架规范用 StarTools.get_data_dir() 统一数据目录，才是“装上就能用、用久也不崩”的体验底线。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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