gTTS、浏览器 TTS 还是神经网络语音:到底该用哪个

这三个我都在真实项目里用过:一个 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 扩展,离开工位后则可在 iOS/Android 应用里继续听。

如果你其实是在掂量那几个付费头部产品,我们也有坦白的逐项对比:Speechify 替代方案和 NaturalReader 替代方案。

扩展可以在 Chrome 应用商店安装,App Store 和 Google Play 上能下到应用。有问题或遇到奇怪的边界情况?发邮件到 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,并为它付费。而如果你从头到尾只是想听、并不想造,那就跳过所有代码,让一个免费朗读器替你搞定。

CastReader 团队

下载 CastReader

在你喜欢的屏幕上,继续阅读。

浏览器扩展

在支持的网页中,直接听文章、Kindle 书籍和 AI 回答。

在 Safari 开始第一次朗读

手机与平板 App

iPhone、iPad、Android 手机与平板

了解手机与平板 App

电脑应用

CastReader Mac 版已上架 App Store,支持 macOS 14.6 及以上系统。Safari 浏览器扩展有独立的下载入口。 CastReader Windows 版已上架 Microsoft Store。

在线朗读

粘贴文字即可在浏览器里听读,无需安装。

开始在线朗读