gTTS批量转文字为MP3最直接可行，需纯文本输入、清洗HTML标签、分段控制长度、防IP封禁、预处理解决中文多音字问题，并通过ID3标签和静音实现有声书体验。
用 gTTS 批量转文字为 MP3 最直接可行
只要文章是纯文本（.txt 或已提取好的字符串），gTTS 是目前 Python 生态里最省事的选择——不用配语音模型、不依赖本地 GPU、API 也不限流。它调的是 Google 的在线 TTS 服务，音质自然，语速语调可控，且支持多语言（中文需显式指定 lang='zh'）。
常见错误是直接传入 HTML 或富文本：结果音频里全是“<p>”“<br>”这类标签。必须先清洗——用 BeautifulSoup 或正则把标签剥干净，只留段落文字，再按句号/换行切分，避免单次请求超长（gTTS 单次最多约 100 字符，超长会静音或截断）。
实操建议：
- 每篇文章拆成多个
gTTS(text=..., lang='zh', slow=False)实例，分别save()，再用pydub合并；不要试图一次喂整篇 5000 字 - 加
time.sleep(0.5)在每次请求后，防被 Google 临时封 IP（尤其批量跑时） - 文件名别含中文路径或特殊符号，否则
save()可能静默失败——用slugify()或手动替换为空白/下划线
遇到“ConnectionError”或“429 Too Many Requests”怎么办
这是 gTTS 批量使用的典型阻塞点，本质是 Google 对同一 IP 的请求频率做了限制，并非你代码写错。不是重试就能解决，硬刷只会延长封禁时间。
立即学习“Python免费学习笔记（深入）”；
有效应对方式只有两个方向：
- 降频 + 随机延迟：把
time.sleep()改成time.sleep(random.uniform(1.2, 2.5))，避开固定节奏探测 - 换代理（仅限合法用途）：用 requests 的
proxies参数透传给gTTS，但注意免费代理极不稳定，反而增加失败率；更稳妥的是换网络出口（比如走公司内网或手机热点） - 备用方案：改用
edge-tts（调 Microsoft Edge 的离线可用 TTS），无需联网，但需安装edge-tts包，命令行调用更稳：edge-tts --text "你好" --voice zh-CN-YunxiNeural --write-media out.mp3
中文发音不准、多音字/专有名词念错怎么调
gTTS 对中文的分词和声调不敏感，像“行长”“重庆”“单于”这类词基本靠猜。它没有 API 参数能干预发音，所以不能指望调参修复。
真正可操作的解法只有预处理：
- 用
pypinyin把关键词转为带声调的拼音，再替换成同音常用字（例如把“单于”替换成“蝉鱼”，前提是上下文允许歧义） - 对人名、品牌名、术语建白名单，在清洗文本后做字符串级替换（如把“ChatGPT”统一换成“查特吉皮提”）
- 放弃
gTTS，切到本地模型：用FunASR+VITS自部署，但需要 GPU 和数 GB 显存——适合长期高频产出，不适合临时跑几十篇
生成的 MP3 没有章节、无标题语音、无法快进跳转
MP3 本身不带章节元数据，gTTS 更不会自动生成。所谓“有声书体验”，得靠后期注入 ID3 标签 + 插入停顿 + 分段命名来模拟。
最小成本实现方式：
- 用
mutagen给每个 MP3 写入TIT2（标题）、TPE1（作者）、COMM（简介）等 ID3v2 标签，播放器就能显示标题 - 在每段文字末尾加 1.5 秒静音（用
pydub的AudioSegment.silent(duration=1500)），再拼接，这样用耳机听时有自然呼吸感 - 不追求“一键成书”，而是把每篇文章输出为一个文件夹：
article_001/01_引言.mp3、02_核心观点.mp3……靠文件名结构代替章节逻辑
真正的难点不在转换，而在原文结构识别——如果爆款文章本身没小标题、没段落空行、混着广告和二维码图片描述，那前处理花的时间远超 TTS 本身。别跳过这步。
