翻译插件与云端 API 之间：一条翻译请求的隐私边界设计

上一篇聊了翻译插件的安全合规实践，评论区有同学问到一个更具体的问题：划中的句子、上传的 PDF，到底会经过哪些环节？这篇把一条翻译请求的完整数据流摊开讲。

一、数据流三段：浏览器 → 网关 → 模型

一段被翻译的文本要经过三段旅程：

1. 浏览器端（插件内）：文本被收集为翻译单元，附带目标语言、术语表版本等元数据。此阶段做的关键决策是最小化采集——只传待翻译文本，不传页面 URL、不传浏览历史、不传用户身份画像。
2. 网关层：做配额校验、批处理装箱、路由到模型。这一层是隐私设计的主战场：日志只记录请求长度与耗时等统计量，不落原文；排障需要时用采样+脱敏。
3. 模型层：调用翻译模型完成推理。需要明确的边界是：文本仅用于当次推理，不进入训练数据，不做持久化存储。

二、三个容易踩的坑

坑一：日志里泄密。 最早版本我们把请求原文记进了排障日志，后来意识到：能接触日志的运维人员理论上能看到用户翻译的全部内容。改造后日志只留统计特征，原文只在内存里存活到推理完成。

坑二：缓存键泄漏。 翻译缓存用「源文 hash」做键没问题，但值里如果带了用户维度（谁翻译的），缓存就成了行为记录。缓存应该是匿名的：同样的输入永远映射同样的输出，与谁发起无关。

坑三：批处理暴露上下文。 装箱批处理时，多个用户的请求拼进同一批，如果模型服务有「批内上下文」机制，理论上存在串扰风险。解法是每批只装同一用户的请求，批间物理隔离。

三、用户侧的可见性

隐私不能只做不说。翻译插件里能看到的隐私边界应该是显性的：划词/整页/PDF 三种模式各自传什么、传多远，用户查得到；历史记录本地存储、可一键清空；云端不存原文。

结语

翻译是高频、文本量大的场景，隐私设计的每个细节都会被乘以使用次数。三段数据流里，「不落原文」是最值得坚持的一条——它让后续所有的合规讨论都变简单了。

（技术实践来自随心翻译，按量计费的文档/网页翻译服务。）