这三个我都在真实项目里用过：一个 Python 脚本每天给我邮件发一份 MP3 摘要（gTTS），一个基于浏览器 Web Speech API 写的侧边栏朗读器，还有几个接了云端神经网络 TTS 的小东西。它们都被笼统地叫"文字转语音"，但拆开看完全是三种生物——一个是套在 Google 某个接口外面的壳，一个是你操作系统恰好装了哪些语音就用哪些，还有一个是某台 GPU 从零生成一段波形。选错了，你会花一下午去跟一个本来另一个工具根本不存在的问题死磕。下面是实话实说的对比、我踩过的坑，以及一条简单的选择规则。
三者到底各是什么
这一段大多数对比文章会跳过，但恰恰是它决定了一切。
gTTS（gtts） 是一个很小的 Python 库，它本身不包含 TTS 引擎。它只是个轻量客户端，把请求拼好发给 Google 翻译那个小喇叭图标用的同一个非官方接口，然后把一段 MP3 丢回给你。整个把戏就这么多。所以"gTTS 的音质"其实是"Google 翻译 TTS 的音质"，"gTTS 稳不稳"其实是"那个没有文档的接口今天还活着、没把我限流吗"。你能拿到一个文件，这确实有用——但你是寄居在别人接口上的客人。
浏览器 TTS 指的是 Web Speech API，具体就是 window.speechSynthesis 和 SpeechSynthesisUtterance。浏览器自己同样不合成任何东西——它去调用你操作系统提供的那些 TTS 语音（在 Chrome 上有时还会调 Google 的在线语音）。所以同一行 JavaScript，在 macOS、Windows、Android、iOS 上发出的是不同的声音，在一台精简过的 Linux 机器上可能干脆什么都没有。它跑在客户端，免费，本地语音连一次网络往返都不用。
神经网络 TTS 是现代深度学习那一类——模型生成一段全新的波形，而不是拼接片段，也不依赖操作系统。那些让你"咦这是合成的？"愣一下的声音，背后就是这一类。它几乎都以云端 API 形式存在（你发文字，它给音频），因为好的模型太重，没法随随便便跑在笔记本上。想看梅尔频谱加声码器那套原理，我在神经网络语音到底怎么运作里单独写了。
三台不同的机器。接下来说取舍。
gTTS：写脚本很香，但暗地里很脆
我用 gTTS，基本都是想从 Python 脚本里搞出一个音频文件，又不想动太多脑子的时候。四行就能得到一段 MP3：
from gtts import gTTS
gTTS("构建完成，十二个测试通过。", lang="zh").save("done.mp3")定时任务、构建通知、把抓来的文章转成出门散步时听的东西、生成简单的语音提示——它都很合适。支持的语言一长串，纯文字念出来很干净，而且产出的文件归你自己。
实话实说的缺点，每一条我都中过招：
- 每次都要联网。 没有本地兜底。断网，或者接口抽风，你的脚本就抛异常。我有过凌晨三点的任务因为请求超时直接挂掉。
- 是非官方接口，没有任何 SLA。 Google 可以限流你、改返回结构、或者直接搞坏它，你毫无办法。在循环里猛刷，你就会开始看到类似
429的失败；大家通常得在调用之间塞time.sleep()，或者把文本拼成更大的块再发。 - 不支持 SSML，基本没有控制力。 你能用
slow=True稍微放慢，用不同的 TLD 换个口音味道，但设不了音高、细粒度语速、重音或停顿。一个速度、一种念法，到头。 - 音质够用，但不算 2026 水准。 明显是合成的——做通知或粗听完全没问题，但要让你专注听一个小时，跟好的神经网络语音差距听得出来。
- 长文本会被切块。 大段输入在底层会拆成多个请求再拼起来，可能出现奇怪的接缝，也成倍放大了"某一个请求失败"的概率。
这些情况别用 gTTS： 需要离线可用、要调用成千上万次（一定被限流）、需要真正的韵律控制、或者是面向用户且不能接受宕机。它是个很棒的个人/自动化工具，却是个靠不住的生产依赖。
浏览器 TTS：免费、即时，但一致性感人
Web Speech API 是那种"用对了我超爱、用错了我得提前警告你"的东西。卖点无可挑剔：零成本、不用 API key、不用服务器，本地语音还不走网络——你一调用它就立刻开口。
const u = new SpeechSynthesisUtterance("来自浏览器的问候。");
u.rate = 1.1;
u.pitch = 1;
speechSynthesis.speak(u);而且跟 gTTS 不一样，你是真有旋钮可拧：rate、pitch、volume，外加 onboundary 事件——你可以用它在念到每个词时高亮那个词，也就是朗读与文字同步的效果，免费，还不用生成音频文件。
接下来是坑，按它们绊倒你的先后顺序排：
getVoices()首次加载是异步的，会返回[]。 这是 Web Speech 最常见的 bug。页面刚加载时语音列表还没就绪，所以你第一次调用拿到的是空。你必须等voiceschanged事件触发后再去选语音。漏掉这一步，它就会"刷新一下就随机不工作"。- 语音完全取决于操作系统。 你听到的就是用户系统装了什么。macOS 上那些高级好听的语音 Windows 上没有；Android 和 iOS 各有各的一套。你没法保证每个用户都用上某个特定语音——只能指定一个
lang，然后祈祷有个像样的来应答。 - 它按规范就是飘的。 Chrome 有个臭名昭著的毛病：长句念到大约 15 秒会停，除非你想办法保活（经典做法是每隔几秒
pause()再resume()戳一下），而且各浏览器行为还不一样。长文朗读得一直盯着它。 - 音质参差不齐。 现在有些系统自带语音是真不错，另一些还像 2009 年的车载导航。你的用户不会都摊上好的那个。
- Chrome 的好声音是要联网的。 最好听的那几个是在线语音，所以"不用联网"只对基础的本地语音成立。
这些情况别用浏览器 TTS： 需要每个用户都是同一个语音和音质、需要可下载的 MP3（这个 API 只负责念，不方便导出文件）、需要稳如磐石的长文播放、或者目标环境是被锁死、可能根本没装语音的机器。给页面加个"读一下这页"的小功能它很出彩；当作要求一致的产品形态就很折磨。
神经网络 TTS：质量档，但要花钱
当声音必须好——内容是要让人静下来听的，或者任何面向用户、代表你形象的场合——神经网络 TTS 就是答案。从 gTTS 或一个平庸系统语音，跨到一个强的神经网络语音，差别就是"这是机器人在念"和"咦这是合成的？"的差别。它还带来真正的 SSML/控制力、跨平台一致的产出（用的是你的服务器，不是用户的系统），以及可下载的音频。
实话实说的代价：
- 不免费，也不本地。 你按字符或按分钟付费，而且要把文本发给第三方——如果文本敏感，这点很要紧。
- 有延迟。 生成要真算力，长文档你得等，或者做流式分块。
- 规模一上来账单涨得很快。 几个 2026 年的参考价，下单前自己核对：ElevenLabs 大约从 5 美元/月（Starter）到 99 美元/月（Pro），各档有字符上限；Google Cloud 和 Amazon Polly 按字符计费（按语音档次大约 每百万字符 4–16 美元，每月有一定免费额度）。用一个高端神经网络 API 把一整本书念完，账单是实打实的。
所以取舍很清爽：gTTS 和浏览器 TTS 免费、效果从粗糙到还行；神经网络很出色、但要计费。
一条实话实说的选择规则
折腾完一圈，我自己实际是这么选的：
- 个人脚本，要的是音频文件，纯文字，不要求离线 → gTTS。 Python 里最快搞出 MP3 的路子。记得加重试和
sleep，免得被接口拍。 - 网页上一个"读一下这段"的按钮，免费、即时、用户间一致性无所谓 → 浏览器 TTS。 处理好
voiceschanged，给长句保活就行。 - 声音代表你的产品、必须好听、必须各处完全一致 → 神经网络 TTS，并为它留预算。
- 你就是终端用户，只想让东西被好好念给你听、到处都能听、且一行代码都不想写 → 干脆别自己造。直接用一个成品朗读器。
最后这一条，才是大多数掉进"gTTS vs 浏览器 TTS"兔子洞的人真正需要的。如果你的真实目标不是造 TTS，而是用 TTS——为了把 PDF、电子书、文档、AI 对话和长文章听完——自己去接这几个里的任何一个，都是慢路。
CastReader 适合放在哪一格
CastReader 就是上面最后那一格的成品版，而且免费可用——任何文字都能用自然语音听，无需注册。它把自然的神经网络语音，和你本来得自己在 onboundary 事件上手搓的朗读高亮，配在了一起；更关键的是，它会主动到内容所在的地方去取，而不是逼你把文字粘进一个框里。想要 premium 超真实语音、更多收听时长和 AI 文档分析，可以升级 CastReader Pro。
落到实处，它能念开发者和研究者真正会攒下来的那些东西：浏览器里的 Kindle 书、长长的 Claude 或 ChatGPT 对话、Gemini 的回答、Google Docs 和 Notion 页面、一篇 arXiv 论文，以及普通网页文章。你可以把 PDF 变成有声书，或者把 EPUB 转成音频；我写代码时会让它读 VS Code，让声音去念注释和文字说明，我的眼睛盯着代码本身。它有 Chrome/Edge 扩展、Mac 应用，还有 iOS/Android 应用，离开工位也跟着你走。
如果你其实是在掂量那几个付费头部产品，我们也有坦白的逐项对比：Speechify 替代方案和 NaturalReader 替代方案。
扩展可以在 Chrome 应用商店安装，App Store 和 Google Play 上能下到应用，也可以直接跑 Mac 版。有问题或遇到奇怪的边界情况？发邮件到 support@castreader.ai——回你的是个真人。
常见问题
gTTS 免费吗？
库本身免费、开源，也不用 API key。但它依赖 Google 一个非官方接口，所以可能毫无预兆地被限流或失效，而且每次都要联网。当个人脚本用是免费的；但你不会想拿它去撑一个付费产品。
为什么我的 Web Speech API 代码有时能跑、一刷新就失败？
几乎都是 getVoices() 的时序 bug。语音列表是异步加载的，页面刚加载后第一次调用时它是空的。在选语音之前先等 voiceschanged 事件（或者轮询到 getVoices() 返回非空数组），那些"随机"的失败就没了。
gTTS 或浏览器 TTS 能离线用吗？
基本都不能。gTTS 永远要联网——它压根没有本地引擎。浏览器 TTS 可以用离线的系统语音，但 Chrome 最好听的那几个是在线的，所以断网时你只剩基础的本地语音。
哪个最像真人？
明显是神经网络 TTS。gTTS 一听就是合成的，系统语音从还行到老旧都有，而一个强的神经网络语音才是那个让你忘记自己在听机器的。代价是神经网络要计费、跑在云端。
我什么都不想自己造——该用什么？
用成品朗读器。如果你的目标是听 PDF、电子书、文档和 AI 对话，而不是造一条 TTS 流水线，那就用像 CastReader 这样的免费朗读器——它直接给你神经网络语音和朗读高亮，什么都不用接。
一句话总结
gTTS、浏览器 TTS、神经网络 TTS 与其说是竞品，不如说是三件干三种活的工具。当 Python 脚本需要一段 MP3、又能容忍一个非官方且只能在线的依赖时，用 gTTS。当你想要一个免费、即时的"读一下"按钮、且用户间一致性无所谓时，用 Web Speech API——处理好语音加载和长句这两个怪癖就行。当声音必须好听、且对所有人完全一致时，用神经网络 TTS，并为它付费。而如果你从头到尾只是想听、并不想造，那就跳过所有代码，让一个免费朗读器替你搞定。