[Plugin] astrbot_plugin_ntts

[Radiant303]

插件信息

{
  "name": "astrbot_plugin_ntts",
  "display_name": "果粒语音",
  "desc": "基于火山引擎的文本转语音插件",
  "author": "Radiant303",
  "repo": "https://github.com/Radiant303/astrbot_plugin_ntts",
  "tags": [
    "语音",
    "火山引擎",
    "豆包"
  ],
  "social_link": "https://github.com/Radiant303"
}

插件检查清单

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

[astrpluginreviewer]

🤖 AI代码审核报告 for astrbot_plugin_ntts

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

main.py

代码质量与编码规范

• 变量命名误导：wav_file 实际承载的是 audio_format="mp3" 的 base64 数据，命名与真实格式不一致，后续维护容易产生误用（例如按 wav 处理）。
• 重复取值与局部变量冗余：tts_synthesize() 内部把 self.xxx 再赋值到一堆局部变量（speaker/app_id/...），可读性下降且没有带来明显收益；on_decorating_result() 里 event.get_result() 也取了两次。
• 配置解析不够严谨：self.enable_tts = bool(config.get("enable_tts", False)) 若配置是字符串（如 "false"/"0"），在 Python 中 bool("false") is True，会导致开关逻辑与用户期望不一致。

功能实现与逻辑正确性

• 消息链提取文本的方式可能不完整/不准确：只要组件有 text 属性就拼接，可能把某些非“自然语言回复”的文本字段也拼进去（取决于 AstrBot 的组件实现）。另外，组件顺序/间隔符处理全靠 "".join，可能造成语义粘连（比如本应带空格/换行的地方被吞掉）。
• 直接覆盖 result.chain 可能造成信息丢失：result.chain = [Comp.Record.fromBase64(wav_file)] 会把原本 LLM 输出的文字完全替换为语音。若下游平台/适配器需要文本兜底或同时展示文本+语音，这里会导致不可用（至少应确认这是预期行为）。
• 长度上限按字符数截断策略偏硬：超过 max_length 直接跳过，不做截断/分段合成，会导致“长回复永远没语音”。这可能是设计选择，但从插件体验角度属于明显边界行为问题。

安全漏洞与最佳实践

• 可能泄露隐私/敏感内容到日志：logger.info(f"正在合成语音: {llm_text}") 会把用户或群聊中的完整文本写入日志；在生产环境里很容易形成隐私/合规风险（建议至少降级到 debug 或做脱敏/截断）。
• 外部请求参数未做最小化校验：url 完全来自配置，未校验 scheme/域名/格式，配置被误填或被污染时可能把消息内容发送到非预期端点（SSRF/数据外泄风险，尤其在多租户部署或配置可被他人修改时）。

可维护性与可读性

• 同步 HTTP 逻辑被包装成 async，语义不一致：_tts_http_stream()/tts_synthesize() 是 async def，但内部完全是同步 requests 调用，使读代码的人误以为这是非阻塞实现；后续维护者很可能在不知情的情况下扩大阻塞影响。
• 异常处理粒度不清：on_decorating_result() 顶层 except Exception 直接吞掉所有错误只打日志，会掩盖“配置缺失/网络错误/协议错误”等可恢复与不可恢复错误的区别；也不利于上层框架统计失败原因。

潜在缺陷或问题（重点：异步环境中的网络 I/O 阻塞）

• 严重的事件循环阻塞风险：在异步插件钩子 on_decorating_result() 中调用 requests.Session().post(..., stream=True) 并 iter_lines() 逐行读取是典型的同步阻塞网络 I/O。后果包括：
  • 阻塞 AstrBot 的事件循环，影响其它消息处理与插件响应；
  • 并发时吞吐显著下降，甚至引发“机器人卡死/超时”。
  • stream=True + 逐行读取会让阻塞持续更久（直到流结束）。
    建议至少把 requests 调用放到线程池（如 asyncio.to_thread），或者改为真正的异步 HTTP 客户端；否则该插件在高频消息场景下风险很高。
• 连接复用/资源开销问题：每次合成都新建 requests.Session()，在高频触发时会产生额外 TCP/TLS 开销；并发场景还可能放大端口/连接压力（同时仍在阻塞事件循环）。
• 流式响应的内存增长风险：audio_b64_parts 无上限累积，若服务端异常返回超长数据或未按预期发送结束码（20000000），会导致内存持续增长（且阻塞期间无法被其它协程打断）。

框架适应性检查（与题目要求相关）

• logger 导入符合要求：已使用 from astrbot.api import logger（无问题，不再展开）。
• filter 导入符合要求：from astrbot.api.event import AstrMessageEvent, filter（无问题，不再展开）。
• @register 使用的兼容性风险：当前使用了 @register(...)。在某些 AstrBot 版本/加载策略变化下可能带来行为差异（例如框架自动识别 Star 子类时与装饰器机制并存的边界行为）。这不是“必须改”的 bug，但属于需要明确目标运行版本与加载机制的维护风险点。

---

代码评审团

人物一：Linus Torvalds（毒舌直指要害）
你这段代码最大的问题不是风格，是在 async 框架里用 requests 做流式 HTTP——这等于往事件循环里塞了块铁砧。要么老老实实把阻塞 I/O 丢到线程里，要么用真正的异步网络库。否则你的“概率触发”只是概率性把整个机器人拖慢。

人物二：Grace Hopper（务实的工程化视角）
日志里直接打印完整的 llm_text，在真实环境里很容易变成隐私事故的“证据链”。工程上至少要做截断、脱敏或降级日志级别，并且把 url 这类外部端点做基本校验，避免配置错误导致数据发往不该去的地方。

人物三：GLaDOS（冷幽默的系统性吐槽）
你把 async def 写得像“我保证不阻塞”，然后转头用 requests 连续读流到结束。很有趣。建议把网络请求模块从“看起来异步”改成“实际上异步”，顺便给 audio_b64_parts 加个上限或超时/中止策略，否则我很期待看到它在某次异常响应里无限增长的表现。

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

---

🔍 审核摘要

统计信息

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

main.py

---

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