[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

代码质量与编码规范

• 存在未使用的函数/代码：_check_audio_magic() 定义后未被调用；同时 _detect_audio_format() 已覆盖其用途，建议删除或真正集成到流程中，避免“死代码”增加维护成本。
• 部分类型标注过于宽泛：例如 SessionData.results: list、_resolve_hostname_async() -> list、_set_session_results(results: list) 等。长期维护时不利于 IDE/静态检查，建议细化为 list[dict[str, Any]] 或定义 TypedDict/dataclass 表达 API 返回结构。
• URL 拼接方式不稳健：api_endpoint = f"{api_url}/api" 在 api_url 末尾带 / 时会产生双斜杠（//api）。多数服务器能处理但属于隐性兼容性问题；建议使用 urljoin(api_url.rstrip('/') + '/', 'api')。

功能实现与逻辑正确性

• 重定向状态码覆盖不全：_download_song() 仅处理 301/302/307/308，但常见的 303 See Other 未处理，可能导致部分站点下载失败。
• 音频格式探测对“首包过短”不鲁棒：_download_song() 只用第一个 chunk 做魔数检测；若首包小于 8 字节（尤其在某些分片/代理场景），mp4 等格式会被误判为非音频从而失败。更稳妥做法是累积到最少 N 字节（如 32/64 bytes）再检测，或在检测失败时继续读若干 chunk 直到达到阈值。
• 会话粒度可能导致“串台”：session_id = event.unified_msg_origin 往往是“群/会话维度”，不是“用户维度”。在同一群里多人同时点歌：后搜索的人会覆盖 results，其他人再发 点歌1 可能播放到别人的搜索结果。若框架允许，建议把 key 设计为“会话+用户”的复合维度，或在结果中标注发起人并校验。

安全漏洞与最佳实践

• SSRF 防护存在“DNS 复解析/重绑定”缺口：你在 _validate_url() 中做了 hostname 解析并检查私网 IP，这很好；但实际发起请求时由 aiohttp 再次解析 DNS，理论上存在 DNS rebinding 风险（校验时解析到公网 IP、请求时解析到内网 IP）。更严格的做法是：
  • 解析后固定使用解析出的安全 IP发起连接（并设置 Host 头为原 hostname），或
  • 使用自定义 aiohttp resolver/connector，在连接阶段再次校验解析结果。
• 允许的 Content-Type 过宽：白名单包含 application/octet-stream，虽然你后续做了文件头魔数检测，但配合“首包过短误判”会放大失败率/异常分支复杂度；并且对非音频但伪造头部的内容仍可能下载大量数据（直到大小上限）。建议更偏向“更窄的类型 + 更稳健的魔数累积检测”。
• 未限制 API 返回体大小：search_song() 会 await resp.json() 直接把响应完整读入内存；若 API 异常返回超大 JSON（或被恶意利用），可能导致内存压力。建议加：
  • aiohttp ClientSession 级别的 read_bufsize/响应大小限制策略（或手动读取并限制长度），或
  • 至少对 Content-Length 做上限检查（不可信但能挡一部分情况）。
• 临时文件清理策略存在“误删风险/碰撞风险”：你用固定前缀在系统 temp 目录扫描删除，虽然前缀较独特，但仍属于“按名字模式删除”。若其他程序意外使用相同前缀，可能被误删。更安全的方式是为插件建立独立子目录（仍在 temp 下）或在文件名中加入更强的命名空间标识（如插件名+随机 token）。

可维护性与可读性

• 类职责偏重，单文件过大：MetingPlugin 同时承担：会话管理、SSRF 校验、下载器、音频切片、发送节流、清理任务。建议拆分为若干内部组件（Downloader/Validator/SessionStore/AudioProcessor），减少“修改一处牵动全身”的风险。
• 错误处理分支较多但语义有重叠：例如 _download_song() 的异常链路里，DownloadError/UnsafeURLError/AudioFormatError 与通用 Exception 的边界有些混杂；建议统一错误语义（下载失败/不安全/格式不支持）并保证每条路径都能带上足够上下文（URL、状态码、content-type、已下载字节数）。
• 初始化/终止后的对象状态不完全复位：terminate() 里将 _initialized=False，但 _sessions_lock/_audio_locks_lock/_download_semaphore/_init_lock 等未置空。若框架存在“同实例二次 initialize/terminate”或热重载边界情况，可能出现难复现的问题（锁绑定旧 loop 等）。建议在 terminate 时把相关异步对象引用也清理或确保不会复用。

潜在缺陷、性能与异步实践（按“仅指出网络 I/O 阻塞”规则）

• 网络 I/O 未见明显同步阻塞调用：整体使用 aiohttp 异步请求，符合异步环境要求。（此项无问题不展开）
• 并发控制粒度可能影响吞吐：下载用 Semaphore(3) 是好的，但音频处理锁是“会话级别串行”。如果 unified_msg_origin 是群级别，会导致同群同一时间只能处理一个音频切片发送，其他点歌会排队，表现为“机器人卡住”。建议重新审视锁粒度（按用户、按消息任务、或按发送通道限流）。

框架适应性检查（按题目要求）

• logger 导入符合要求：from astrbot.api import logger 没问题。（无问题不展开）
• filter 导入符合要求：from astrbot.api.event import ... filter 没问题。（无问题不展开）
• @register 装饰器的兼容性提醒：代码使用了 @register(...)，在题述的 v3.5.20+ 中属于“已废弃但可用”的旧方式；如果目标环境确实是新版本，可能出现加载方式差异带来的维护成本（不是要求你更换库，而是建议跟随框架推荐写法以减少未来问题）。

---

代码评审团

人物一：Linus Torvalds（毒舌但务实）
你写了不少“看起来很安全”的 SSRF 检查，但真正发请求的时候 DNS 还能变，这就像你在门口查了身份证却让人从窗户爬进来。要么连接阶段复验解析结果，要么把解析到的安全 IP 固定下来，不然这些校验更像心理安慰。

人物二：Grace Hopper（偏工程与可维护性）
这个类承担了太多职责：会话、下载、校验、音频处理、清理任务全塞一起，未来你每改一次下载逻辑都得担心会话锁和清理任务会不会被误伤。把 downloader/validator/audio processor 拆开，你的测试也会立刻变得可写、可测、可复用。

人物三：Donald Knuth（偏正确性与边界条件）
首个 chunk 就做格式判断是个典型的“对实现细节做了不可靠假设”。网络分片不保证你第一次就拿到足够的头部字节，导致你把正确输入判成错误输入。累积到固定字节数再检测，这类 bug 会少一大半——这比加十个异常分支更优雅。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

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

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