ssurui
b45c7d2f27
fix: 修正答案生成中途打开语音输出只从当前位置播报的问题
用户反馈：答案还在流式输出时才打开"语音输出"，朗读会从打开那一刻
"之后"的新增量开始，开 TTS 之前已经显示在屏幕上的那部分正文被跳过
没有播报。
根因：TtsPlayer.append() 第一行是 `if (!this.options.enabled) return`，
TTS 关闭期间每次 onDelta 调用 append() 都会被直接挡掉，内部的 rawText/
lastSpokenPlain 完全不会累积。toggleTts() 原来只处理了"答案已生成完毕
时打开 TTS"（调用 speakWithAnnouncement 整段重播）这一种情况，没有处理
"生成中途打开"的情况——这时 ttsEnabled 变 true 后，下一次 onDelta 送来
的只是新增的那一小段 delta，append() 在一个空白的 rawText 基础上开始
累积，效果就是只从当前位置往后播。
修复：toggleTts() 新增分支，检测到 store.querying 为 true 时，先播
"开始播报"提示音，再用 append(store.rawAnswer) 把已生成的全文"补喂"
一遍，相当于告诉播放器"这就是从头到现在的内容"；之后 onDelta 的增量
在这个基础上正常追加，衔接不重复。
验证方式：真机通过 CDP 直连运行中的页面，用 Input.dispatchMouseEvent
模拟真实点击触发中途开启，在主进程 tts:speak IPC 处理器临时加日志
（验证后已移除），确认实际送去朗读的文本顺序是"开始播报"→"根据手册，
蓄电池的拆卸与安装步骤如下："→"拆卸："→"一、旋松蓄电池正极导线端子
螺母并取下端子"→...，正确从头开始、后续衔接无重复无跳字。
过程中也确认了 window.electronAPI 这类 contextBridge 暴露对象默认被
冻结，渲染进程侧没法通过 monkey-patch 拦截调用做验证（赋值会静默失败），
后续类似验证只能从主进程 IPC handler 侧加日志或用其他方式。
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01QeoAy5KmkHuKWHAktpEsaN
2026-10-05 17:40:16 +08:00
..
2026-10-05 17:05:27 +08:00
2026-09-03 14:50:52 +08:00
2026-10-05 17:40:16 +08:00
2026-08-15 19:56:22 +08:00