把一本 EPUB 交给翻译服务之前，工程上要处理的三件事

前两篇分别聊了双语对照的前端实现和划词的技术链路，这一篇讲一个更"重"的场景：整本电子书的翻译。EPUB/长文档翻译看起来是把网页翻译的量放大几百倍，工程上却多了三个独立问题。

一、结构解析：EPUB 不是一个大文件

EPUB 本质是一堆 XHTML 加上目录（ spine/toc）。直接逐章翻译会丢失两个东西：跨章的术语一致性（前文译成「句柄」，后文不能变成「把手」）和目录导航的对应关系。

处理方式：解析 spine 顺序 → 按 toc 建立章节树 → 逐章抽取翻译单元时携带章节上下文。术语层面维护一张全书术语表，翻译前先扫高频名词构建，之后每次请求携带 glossary 约束——这是保证"一个概念一本书只有一个译名"的关键。

二、批处理：把零散请求拼成整装列车

一本 10 万词的书约 2000+ 个翻译单元。逐个请求既慢又贵（请求开销占比高）。批处理接口按 6000 字符一箱装车，2000 个单元合并成几十次调用；配合断点续跑（每箱完成后落盘进度），中途失败不用从头再来。

这里有个容易被忽略的坑：批处理打乱顺序后，代词（it/they/this）的指代会断。缓解方案是装箱时保留前后相邻单元的一小段原文作为上下文前缀，只读不计费。

三、计量与成本：一本原著不到 6 毛钱

10 万词的输入+输出约 23 万 token，按 2.5 元/百万 token 计价，整本不到 6 毛钱。这个账反过来对工程也成立：单价足够低时，"全书预扫描构建术语表"这类多花 10% token 换质量的策略才敢开。

结语

长文档翻译是网页翻译的超集：解析、批处理、术语一致性三件事做扎实，体验才立得住。三篇连起来正好是一条从「段」到「页」再到「本」的工程线，欢迎交流。

（工具背景：随心翻译，按量计费 2.5 元/百万 token，支持 EPUB 等八种文档格式。）