网页朗读的隐私账单：你的文字到底发给了谁

在浏览器里朗读网页，大多数人当作一个功能问题：哪个工具好用装哪个。但每按下一次"朗读"，都有一个问题先于音质存在——这一页的文字，此刻正在发往哪里？

云端 TTS 的答案是：发给服务商，适用对方条款。自部署本地服务的答案是：留在你的机器，代价是先有一台跑得动的机器。这两条路都被讨论烂了。本文要说的 Narro 提供了第三条：让语音模型直接跑在浏览器进程里——文字从头到尾不离开本机。

Narro 是一个 MIT 许可的 Chrome 扩展，最新版 1.2.0 发布于 2026 年 10 月 24 日，65 次提交，已上架 Chrome 应用商店；点击图标、选引擎、按 Read this page，当前页面逐句朗读，句子高亮并跟随滚动[1]。但真正值得写一篇文的不是"它能读"，而是它的引擎菜单本身——那是一张完整的隐私光谱。

一、隐私光谱：三档数据流向，一次选清楚

Narro 的引擎分三档，数据流向完全不同[1]：

第一档，云端引擎（文字出境）。 OpenAI 系（gpt-4o-mini-tts 支持风格指令、tts-1、tts-1-hd）、ElevenLabs（列出你账号下的音色）、Google Gemini、OpenRouter（一个密钥接入多家）。选这档，被朗读的文字发给对应服务商；走 OpenRouter 还要经过它背后的模型提供商。

第二档，本地服务器（文字到你的机器）。 对接任何 OpenAI 兼容的 /v1/audio/speech 接口（如 Kokoro-FastAPI）。扩展只负责页面与播放，合成发生在你配置的服务器上。

第三档，浏览器内引擎（文字不出本机）。 Kokoro-82M（8 个英文音色）、Supertonic 2（英/西/法/葡/韩 10 音色）、Piper、Kitten TTS Nano。模型文件首次从 Hugging Face 下载，之后缓存在浏览器里；朗读内容不离开设备。

隐私细节上 Narro 本身做得干净：API 密钥存 chrome.storage.local，不参与同步，只发送给对应服务商；项目没有分析统计、没有账号、没有自有服务器[1]。但架构再干净，也只决定"扩展不多拿"——文字去哪，仍然由你选的引擎档位决定。 这就是我说"隐私光谱"的原因：工具不替你做隐私决策，它只是把决策点摆在了明面上。

二、不出本机的代价：一张实测资源账单

浏览器内引擎的门槛不是玄学，README 在 M1 Pro 的 Chromium 上给了实测数据（模型已缓存、12 段文章、内存峰值取整到 50MB）[1]：

两个反直觉的数字值得圈出来。其一，内存不随模型大小线性增长：Piper 的音色文件比 Kokoro 小，运行内存反而更高（800 MB 对 700 MB）——因为三个引擎共用同一套语音运行时，运行时本身就占掉了内存的大头[1]。其二，WebGPU 不总是省：Kokoro 用 WebGPU 下载量翻 3.5 倍、内存涨 50%；Supertonic 却是内存降 150 MB。结论：不要按"模型越小越省"的直觉选，直接看弹窗里显示的当前机器实测值[1]。

给想验证"不出本机"是否满足需求的人一条最低成本路径：先装 Kitten TTS Nano——27.7 MB 下载、约 500 MB 内存，五分钟内可以完整跑通第三档的全流程，再决定要不要为音质升档。

三、两个进阶玩法与一个中文用户的现实提醒

Kindle Cloud Reader 朗读是个有意思的支线：Kindle 网页版把书页渲染成图片，普通文本提取拿不到内容，Narro 用 Tesseract 在本机 OCR 当前可见页再朗读，读到页尾自动按 Kindle 的翻页键继续（可关闭）；跨页断句会完整朗读一次。注意两点边界：OCR 仅支持英文，装饰字体、极小字号和插图都会降低识别率；项目声明与 Amazon 无隶属关系，自动化使用 Kindle Cloud Reader 可能受服务条款限制，合规性要使用者自行确认[1]。

阅读控制的细节也想得周到：连续句子合并成一次请求保语调连贯、第一句单独发让朗读尽快开始；0.5–3 倍速且保持音高；选中文字右键从该处开始；恢复进度靠"最后一句指纹+位置"实现，最多记 200 个页面，全部留在本地、不包含文本本身[1]。

中文用户的现实提醒，这是本文最重要的干货：浏览器内引擎目前全部不覆盖中文——Kokoro 和 Kitten TTS Nano 只有英文音色，Supertonic 2 不含中文，Piper 宣称多语言但 README 未给出具体语言列表；系统音色能否读中文取决于操作系统配置[1]。所以中文用户实际上只有三条路：① 系统音色（免费，质量看 OS 运气）；② 本地服务器档（自建 Kokoro-FastAPI 等，有 GPU 机器时音质与隐私兼得）；③ 云端引擎（接受文字出境）。“隐私优先"和"中文朗读"在 2026 年 10 月的浏览器内生态里还是互斥的——这个空档本身就是一个信号：中文社区里有人做一个支持中文的浏览器内 TTS 引擎，价值是现成的。

四、怎么选：一张决策顺序

把全文收成决策序：第一问，这段文字能不能出境？ 不能 → 第三档浏览器内引擎（英文内容）或第二档本地服务器（中文内容/有服务器）。第二问，音质和音色值多少钱？ 值 → 升第一档云端，并知晓适用对方条款。第三问，机器跑得动吗？ 查上表，或者相信 Narro 弹窗里的实测数字而不是营销页。

最后说明本文的边界：未做装机实测，以上判断全部来自公开仓库与 README，安装前以最新版本说明为准[1]。但有一件事不需要实测就能确定：在按下"朗读"之前先问"文字去哪”，这个习惯比任何一款工具都值钱。

参考

1. Narro GitHub 仓库与 README（swrdfish/Narro，v1.2.0，2026-10-24）——引擎清单与数据流向说明、chrome.storage.local 密钥存储、无分析统计/账号/自有服务器声明、M1 Pro Chromium 实测资源表（Kokoro 92.4/325.5 MB 下载、700/1050 MB 内存；Supertonic 262.9 MB、950/800 MB；Piper 63.2–120.8 MB、800 MB；Kitten 27.7 MB、500 MB）、阅读控制与本地恢复机制、Kindle OCR 流程与边界、中文覆盖缺失说明。快照：sources/narro_repo.txt、sources/narro_readme.txt

本文事实层以上述一手来源为限；「隐私光谱」「三档决策序」「中文空档信号」为作者分析视角。