[Plugin] astrbot_plugin_Gemini_STT

[Weather-719]

插件信息

{
  "name": "astrbot_plugin_Gemini_STT",
  "display_name": "Gemini_STT",
  "desc": "使用Gemini模型来实现STT(分析特别详细哦)",
  "author": "政ひかりはる",
  "repo": "https://github.com/Weather-719/astrbot_plugin_Gemini_STT",
  "tags": [
    "STT",
    "语音",
    "桥接",
    "Gemini"
  ],
  "social_link": "https://github.com/Weather-719"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_Gemini_STT

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

main.py

代码质量与编码规范（PEP 8 等）

• 单个方法过长且职责混杂：handle_voice() 同时做了解析消息组件、权限/白名单判断、文件准备、STT 调用、失败策略、会话获取、LLM 转发等多件事，圈复杂度偏高，不利于单元测试与后续维护（建议拆分为若干私有步骤方法）。
• 部分日志/提示字符串与逻辑耦合较紧：例如多处直接拼接中文提示与控制逻辑混在一起，后续要做国际化或统一错误码会比较痛苦。

功能实现与逻辑正确性

• 音频大小限制可能被转换流程绕过：对“原始输入文件”做了 max_audio_mb 限制，但 wav/amr/silk -> mp3 后的 输出 mp3 文件大小未再校验。在极端情况下（长音频/高码率/异常封装），转换后的 mp3 仍可能过大，导致向 Gemini 发送超大 payload、内存压力或请求失败。
• _extract_plain_transcript() 的提取规则可能误提取/漏提取：rich 返回若“原话转写”内容不在同一行（例如冒号后换行），当前正则 (.+) 默认不跨行，会提取不到，最终退化为返回整段 rich 文本（与 simple 模式“只要纯转写”的目标冲突）。

安全漏洞与最佳实践

• 远程音频下载存在“重定向绕过”风险（SSRF 相关）：_is_safe_remote_url() 在下载前对原始 URL 做了 host/IP 校验，但 aiohttp 默认可能跟随重定向；攻击者可利用 30x 将请求跳转到内网地址，从而绕过你对初始 URL 的校验。应显式禁用重定向或对最终跳转目标重新做同等校验。
• 存在 DNS Rebinding / TOCTOU 风险：你在 _is_safe_remote_url() 里用 socket.getaddrinfo() 解析域名并检查 IP 是否私网，但真正发起 HTTP 请求是在后面 session.get(url) 时由 aiohttp/系统再次解析域名。若域名解析在两次解析间发生变化（rebinding），可能绕过校验。需要考虑“校验与连接绑定一致”（例如固定解析结果并强制连接到该 IP、或在连接器层面控制解析）。
• 允许读取本地路径的潜在风险：record_comp.path/url 被直接当作本地路径读取（非网络 URL 情况）。如果上游组件在某些适配器/平台下可被用户影响成任意路径，可能造成任意文件读取（哪怕概率不高，也属于边界要点）。至少建议对路径做更严格约束（例如必须位于框架语音缓存目录下，或只允许特定后缀/目录前缀）。
• 对外部二进制依赖的信任边界：ffmpeg_path 支持从配置指定并直接执行。虽然使用 list 形式避免了 shell 注入，但若配置被篡改可导致执行任意程序；这属于“管理面”风险，建议在文档/配置层提示安全边界或加入更严格的可执行文件校验策略。

框架适应性与异步最佳实践（仅指出网络 I/O 阻塞点）

• socket.getaddrinfo() 在异步事件循环中是同步阻塞调用：_is_safe_remote_url() 里直接调用 socket.getaddrinfo()，在 DNS 慢或异常时会阻塞事件循环，影响整个机器人并发响应。建议改为异步解析方案或 loop.getaddrinfo()（注意仍需结合上面的“校验与连接一致性”一起设计）。

可维护性与可读性

• 失败策略与 stop_event 时机的组合逻辑较绕：stop_other_handlers、stop_event_timing、on_stt_fail 三者交织，effective_before_stop 的判定较难一眼验证所有路径是否符合预期；后续新增策略/模式容易引入回归。建议将“是否 stop/何时 stop/失败时是否放行”抽成清晰的决策表或单独函数集中处理。
• 大量 except Exception: pass/吞异常会掩盖真实问题：例如 terminate()、清理临时文件等处完全吞异常，长期运行时如果出现系统性问题（权限/磁盘/句柄耗尽）会难以定位。建议至少在 debug 模式记录异常摘要。

---

代码评审团

人物一（Linus Torvalds，毒舌但务实）：
你这 handle_voice() 像把一堆电线塞进同一个接线盒里然后祈祷它别短路。功能都在，但维护起来会让人抓狂。把“解析消息 / 拉取音频 / STT / 转发 LLM / stop 策略”拆成清楚的阶段，写几个小函数，出问题也能精准定位。

人物二（Grace Hopper，强调可靠性与可调试性）：
吞异常是调试的天敌。你在多个地方 except: pass，等同于主动放弃了“为什么失败”的证据。即便是清理失败，也应该在 debug 下记录一下失败原因；否则线上偶发故障会变成“幽灵 bug”。

人物三（Gordon Ramsay，暴躁的工程“主厨”风格）：
你说自己“硬化”，结果远程下载还允许重定向默认跟随？这就像把后门锁上了却把窗户敞开。SSRF 校验要么做全套：禁重定向、校验最终地址、绑定解析结果；要么就别自称 hardened。把这块补齐，你的安全性才配得上标题。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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

[astrbot-plugin-copybara]

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

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