[Plugin] astrbot_plugin_meting

[chuyegzs]

插件信息

{
  "name": "astrbot_plugin_meting",
  "display_name": "初叶🍂MetingAPI 点歌",
  "desc": "基于 MetingAPI 的点歌插件，自定义API地址，支持QQ音乐、网易云、酷狗、酷我音源",
  "author": "初叶🍂竹叶-Furry控",
  "repo": "https://github.com/chuyegzs/astrbot_plugin_meting",
  "social_link": "www.chuyel.cn"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_meting

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

main.py

代码质量与编码规范

• 未使用的导入/常量/异常类
  • APIResponseError、AUDIO_EXTENSIONS 未被使用。
  • 这会增加维护成本，建议清理或补齐对应逻辑（例如用扩展名白名单做二次校验）。
• 类型标注与真实返回不一致
  • async def _download_song(...)-> str：函数在失败路径上可能返回 None（末尾 return None），类型应改为 -> str | None，或在失败时始终 raise 并移除 None 返回。
• 部分逻辑块过长、职责偏多
  • _download_song 同时承担：重试、重定向处理、SSRF 校验、内容类型判断、写文件与大小限制等，复杂度较高；建议拆分成更小的私有方法以提高可读性与可测试性。

功能实现与逻辑正确性

• 重定向 Location 处理不正确（可能导致下载失败）
  • 在 _download_song 中手动跟随重定向时：current_url = redirect_url。
  • 若 Location 为相对路径（常见于 Location: /path），_validate_url 会因“缺少主机名”判定不合法，从而导致本应成功的下载失败。
  • 建议使用 urllib.parse.urljoin(current_url, redirect_url) 合成绝对 URL。
• FFmpeg 检测逻辑与 pydub 实际使用之间可能不一致
  • _find_ffmpeg() 只检查 shutil.which("ffmpeg")，但 _split_and_send_audio 仅判断 self._ffmpeg_path 非空就继续；然而 pydub 仍可能因未正确配置 converter 或运行环境差异而找不到可执行文件。
  • 更稳妥做法：在导入 pydub 后显式设置 AudioSegment.converter = self._ffmpeg_path（或同时设置 ffprobe），并在异常信息中输出具体失败原因。

安全漏洞与最佳实践

• SSRF 防护存在“DNS 复绑定（DNS rebinding）”窗口
  • _validate_url 先解析 hostname 并校验是否为私网 IP，但真实 HTTP 请求由 aiohttp 再次解析/连接，期间 hostname 的解析结果可能变化（恶意 DNS 复绑定场景）。
  • 更严格的做法是：解析后固定使用已校验的 IP 进行连接（或自定义 resolver / 连接器策略），并校验最终连接的 peer IP；否则属于“校验与使用分离”的典型风险点。
• 允许 application/octet-stream 作为音频类型，存在内容伪装面
  • 这会允许任意二进制内容以音频名义下载，后续交给解码器处理，虽然不一定直接 RCE，但会增加攻击面与资源消耗风险。
  • 建议：对 octet-stream 增加更严格的二次判定（例如基于文件头 sniff、或限制必须为已知音频扩展/魔数之一）。
• 下载文件落在系统临时目录，未做磁盘配额/清理兜底
  • 虽然限制了 max_file_size，但并发多用户/频繁失败场景仍可能导致临时目录堆积（尤其在某些早退路径未清理，见下文“资源泄漏”）。
  • 建议增加：异常与早退路径统一清理；以及定期清理本插件产生的临时文件前缀（如 meting_song_）。

可维护性与可读性

• 会话字典 _sessions 的并发访问缺少保护
  • 多个事件处理器可并发读写 _sessions（例如并发搜索/切换音源/播放），当前没有锁保护，可能出现时间戳覆盖、结果集互相覆盖、或清理与写入竞态。
  • 建议：为 _sessions 操作增加 asyncio.Lock（或使用 collections.defaultdict + 统一入口并加锁），至少保证“写操作 + 清理”是原子的。
• 全局音频锁 _audio_lock 会导致所有会话串行播放
  • _split_and_send_audio 用同一个 _audio_lock，意味着任意群/私聊同时点歌会互相阻塞，表现为“只能同时处理一首歌”。
  • 如果这是非预期，建议改成按 session_id 粒度的锁（例如 dict[session_id, Lock]），或仅对 CPU 密集/ffmpeg 调用段加更细粒度锁。

潜在缺陷、资源泄漏与异步实践（按要求仅关注网络 I/O 阻塞点之外的风险）

• 严重：_split_and_send_audio 早退时不会删除已下载的 temp_file
  • 下面两条路径会 yield ...; return，但没有进入最后的 finally 清理（因为 finally 在 async with self._audio_lock: 块内部）：
    • if not self._ffmpeg_path: ... return
    • except ImportError: ... return（pydub 缺失）
  • 结果：下载成功后如果环境缺 ffmpeg 或缺 pydub，会在系统临时目录留下歌曲文件，长期运行会堆积。
  • 建议：把 temp_file 清理 finally 提升到函数最外层，确保任何路径都能删除；或在上述两个早退分支也显式 os.remove(temp_file)。
• terminate() 未将 _initialized 复位/未清空会话
  • 如果框架存在“卸载后重载同一实例/或复用对象”的情况，可能产生状态残留（_sessions、_initialized、_http_session）。
  • 建议在 terminate() 中清空 _sessions，并将 _initialized=False、_http_session=None。

---

代码评审团

人物一：Linus Torvalds（毒舌但务实）
你这套下载函数把“重试/重定向/校验/落盘/限额”全塞一个锅里炖，读起来像在看事故报告。先把重定向用 urljoin 修了，不然相对 Location 直接把功能干废；再把逻辑拆开，否则以后你自己都不敢改。

人物二：Guido van Rossum（偏语言与可读性）
类型标注写了 -> str 却在失败时返回 None，这会让调用方和静态检查都很难受。要么“失败就抛异常”，要么把签名改成 str | None 并明确契约。还有 _sessions 的并发访问没有锁，在异步环境里这属于“早晚会出怪事”的代码形态。

人物三：GLaDOS（冷幽默、专挑边界条件）
恭喜你制造了一个临时文件生成器：当 ffmpeg 不存在或 pydub 没装时，下载下来的音频会永远住在临时目录里，直到磁盘尖叫。把清理放到最外层 finally，让垃圾回收真正发生；顺便别用全局 _audio_lock 把所有用户的播放体验排成一条队。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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