「把这段文字读出来」和「把这段录音转成文字」听着是一对互逆操作，但在浏览器里，这两件事的成熟度差了一整个量级。前者稳定可用，后者限制很多。搞清楚各自的边界，比反复调参数有用。
这篇讲清楚浏览器语音能力的实现方式、每个参数的取值经验，以及哪些期待注定落空。
一、语音合成的音色从哪来：为什么每台电脑都不一样
文本转语音用的是浏览器内置的语音合成能力，工具本身不自带任何音色，它做的事是向浏览器要一份可用音色列表，筛出中文和英文的，让你挑一个。这个设计决定了一个绕不过去的现实：音色来自你的操作系统和浏览器，不同设备听起来完全不同。
具体表现是：
- Windows 上是系统自带的微软语音，中文音色的数量取决于你装了哪些语言包。
- macOS 与 iOS 上是苹果的语音，音色偏自然，iOS 上还可能有需要单独下载的高质量音色。
- Android 上通常是 Google 语音服务提供的音色。
- 部分 Linux 发行版 默认不带中文语音，下拉框里可能只有英文音色，甚至一个都没有。这时用中文音色读中文会失败或读成一串奇怪的音节，不是工具的问题。
第二个必须知道的点是音色列表是异步加载的。刚打开页面时浏览器可能还没准备好列表，下拉框是空的，工具通过监听「音色列表变化」事件重新加载。所以看到下拉框空着，等一两秒或者刷新一次就好，不要以为不支持。
同一段稿子在你机器上试听满意，发给同事说「用这个音色」是没有意义的——他机器上未必有同名音色。要固定音色，只能固定设备，或者改用服务端的语音合成服务。
二、语速、音调、音量怎么取
三个参数的可调范围分别是：语速 0.1 到 10 倍、音调 0 到 2、音量 0 到 1。范围很宽，但真正可用的区间窄得多：
- 语速：
1.0是音色的原始速度。校对稿子用0.9左右，慢一点耳朵才抓得住错字；通勤听稿用1.2到1.5，习惯之后1.8也能接受。超过2.0之后多数音色会开始吞字、连音，把标点带来的停顿压没，听起来是一串糊在一起的声音。理论上能设到10，但那个速度没有实用价值。 - 音调：
1是原始音高。往上调偏尖细，往下调偏低沉，偏离越远机械感越强，0附近基本听不出内容。做角色区分可以微调到0.8或1.2，正经听内容就别动它。 - 音量：这是相对值，最终响度还受系统音量和音色本身的响度影响。设成
1仍然觉得小，去调系统音量，在这里继续加没有余量。
一个操作上的细节：参数是在开始朗读的那一刻读取的。朗读过程中拖动语速滑块，当前这一段不会变速，需要停止再重新开始。所以调参数的正确方式是拿一小段文字反复试，定下来再朗读全文。
播放控制有播放、暂停、继续、停止四个动作。「停止」是清空整个朗读队列，不是暂停在原地；想从中间继续，用「暂停 / 继续」这一对。
三、长文本必须分段：不分段会遇到什么
把一万字的稿子整篇粘进去点朗读，常见的三种失败是：读到中途突然停下、点了暂停之后继续位置错乱、干脆一点声音都没有。原因是各家语音引擎对单次朗读任务的文本长度有各自的上限，超过之后行为不统一——有的截断，有的静默失败。
实用做法：
- 按段落分批，每次几百字到一两千字，读完一段再粘下一段。写作时段落分明的稿子在这里会占便宜。
- 依赖标点的自然停顿。合成引擎按标点判断停顿长短，长句不加标点会读得又急又平；这也是为什么朗读能帮你发现「这句太长了」。
- 别在朗读时切走标签页。部分浏览器会在后台标签页限制或中断语音合成，锁屏更是如此。要边听边做别的事，让页面保持在前台。
关于「下载音频」这个功能需要单独说明：它不是把浏览器合成的声音录下来——浏览器的语音合成接口只负责发声，不提供音频数据的导出通道。工具的下载走的是外部在线语音合成服务，也就是说要朗读的文本会被拼进请求地址发送到外部服务器。这一点和站内其他工具「全程本地处理」的原则不同，所以两条建议：涉及保密、涉密名单、未公开稿件的内容不要用下载功能，只用页面内试听；确实需要音频文件，用系统自带的录屏 / 录音功能把试听录下来更稳妥。
顺便说明一个容易困惑的点：文字朗读工具与文本转语音是同一套实现，两个入口对应同一个功能，参数、音色来源和限制完全一致，按你习惯的名字进就行。
四、语音识别的真实边界：它只听麦克风
语音转文字这一侧的限制远大于合成侧，有必要先把原理说清楚。
浏览器的语音识别接口，设计上是接一路麦克风实时音流：你说话，它边听边出结果。它没有提供「把一个音频文件送进去识别」的入口。这是接口层面的限制，不是实现偷懒。所以对「上传一段会议录音，出一份文字稿」这个需求，浏览器方案天生不合适——工具里的文件上传路径不能被当作对该文件内容的可靠转写来使用。
真的要给已有录音出文字，两条现实路径：用音箱外放录音、同时让工具听麦克风做实时识别（缺点是会混进房间噪音，准确率明显低于直接送文件），或者使用专门的转写服务。
第二件事：识别通常不是纯本地的。多数浏览器的实现会把音频送到浏览器厂商的云端识别服务再返回文本，所以它需要联网，断网时会直接报错；也意味着录音内容会离开设备。涉及敏感谈话内容的录音，不适合走浏览器识别这条路。
第三件事：浏览器支持度差异很大。基于 Chromium 的浏览器（Chrome、Edge 及大部分国产浏览器）与 Safari 支持较好，Firefox 默认不提供这个接口，进去会直接提示不支持。另外页面必须在 HTTPS 下，且麦克风权限必须由你手动授权，地址栏出现权限询问时点允许，误点拒绝之后需要到浏览器的站点设置里改回来，刷新页面不会再问第二次。
最后是准确率的现实影响因素，按影响从大到小排：
- 环境噪音。空调、键盘、街道声都会显著拉低准确率，噪音大的环境里几乎不可用。
- 离麦距离。笔记本内置麦克风在半米内还行，一米外就开始丢字，戴耳麦提升非常明显。
- 多人同时说话。接口是为单人语音设计的，会议里几个人抢话会得到一段混乱的文字。
- 口音与语速。方言口音、语速过快、吞音都会掉准确率。
- 专业术语、人名、英文缩写。识别引擎按通用语言模型出结果，专业词会被换成同音的常用词，这类错误必须人工核对。
所以合理的期待是：在安静环境、戴耳麦、单人、说普通话且语速平稳时，用它做口述初稿或速记草稿，然后在结果框里手工修改——工具的转写结果是可编辑的，改完再复制或下载。把它当成「口述输入」而不是「录音转写」，体验会好很多。
五、朗读功能真正好用的几个场景
- 校对错字。这是被低估的用法。眼睛会自动补全缺失的字，耳朵不会：漏字、重复词（「的的」「我们我们」）、多余标点、少一个引号、句子太长读到断气，用
0.9倍速听一遍全都会暴露出来。写完稿子听一遍，比再读三遍有效。 - 通勤与做家务时听稿。把要读的资料粘进来，
1.3倍速，手机放兜里。注意保持页面在前台，锁屏后多数浏览器会中断。 - 口播稿控时长。按目标语速读一遍看用时，比按字数估算准得多，视频口播、演讲控时都用得上。
- 无障碍阅读与陪读。眼睛疲劳时用听，或给识字量不够的孩子读材料。
- 中英混排检查。中文音色读到英文单词时的处理方式各引擎不同，能顺带发现文中该不该保留英文原词。
还有一个组合用法：先口述录一段初稿，用识别出个粗糙文本，编辑成型后再用朗读听一遍找错——一个负责输入，一个负责校验，中间的编辑工作还是得人来做。
常见问题
音色下拉框是空的，或者只有英文音色，怎么办？ 音色由操作系统与浏览器提供，工具只是列出来。列表为空通常是还没加载完，等一两秒或刷新页面；只有英文说明系统缺中文语音包，需要在系统语言设置里安装对应语音，Linux 桌面尤其常见。
为什么长文读到一半就停了？ 单次朗读任务的文本长度上限由语音引擎决定，超了之后行为不一致。按段落分批朗读，每次几百到一两千字，是最稳的做法。
上传录音文件能得到准确的文字稿吗？ 不能指望。浏览器的语音识别接口只接受麦克风实时输入，不支持直接读取音频文件。要转写已有录音，用外放加麦克风实时识别，或者用专业转写服务。
朗读的文字会被上传吗？ 页面内的朗读、参数调节都在本地完成，文本不会离开设备；唯一的例外是上面提到的「下载音频」功能，它依赖外部服务。语音识别则本身依赖联网的识别服务，音频会离开设备，这一点在处理敏感内容前要先考虑清楚。