浏览器端文件转换的隐私安全：你的文档去了哪里

文档转换本是小事，直到你转的是合同、病历或保密协议下的草稿。此时问题不再是工具快不快，而是文件到底去了哪里。云转换器与浏览器端转换器的回答截然不同，且差异可以亲手验证，不必盲信宣传。

本文梳理云转换的真实数据流、敏感文档的威胁模型、纯客户端转换的原理，以及最重要的：如何只用开发者工具验证零上传声明。最后谈谈本地方案的诚实边界与数据最小化。

云转换器的真实数据流

典型云转换器做的事比宣传页更多：文件先经 TLS 上传到服务商服务器，处理发生在你无法控制的机器上；结果还要传回来，通常至少再经一次中转，期间原件与成品都留在中间环节。

这些副本受服务商保留政策约束——可能几分钟删除，也可能留存很久——还受数据中心所在司法辖区约束。许多服务还依赖第三方。每多一跳，就多一个接触你文档的主体。

转换菜谱时这些都无所谓；换成未公开的合同、病历或受 NDA 约束的手稿，算式就变了。威胁通常不是有人恶意偷看你的文件，而是副本的累积——磁盘上、备份里、日志中——你数不清、删不掉、审不了。

敏感内容的时效也比想象的长：今天无碍的文档，两年后可能在商业或法律上微妙，而保留政策由持有数据的一方书写，而非创建者。你唯一能完全控制的保留策略，是文件从未离开设备的那种。

浏览器端转换把流程反过来：让引擎走向文件。站点把编译成 WebAssembly 的 Pandoc 载入浏览器，它运行在与 JavaScript 相同的沙箱里：不能访问文件系统、没有自己的网络权限，除非页面主动连接。

转换运行在 Web Worker 后台线程里，与页面 UI 隔离。文档以字节形式交给 Worker，在内存中解析、转换、返回；除了你触发的下载，不向磁盘写任何东西，无需服务器往返。结束时字节像普通变量一样被回收。

验证只需两分钟。打开开发者工具切到 Network 面板，加载转换页并拖入文件：客户端转换期间面板保持空白——没有 POST、没有指向 API 的神秘请求，你看到的只是页面自身加载的资源。

还有两项更硬的检查。其一，引擎首次下载并缓存后，加载站点、断网再转一次——它照常工作，这只有在无网络依赖时才可能。其二，翻一遍 Application 标签：Cache Storage 里能看到缓存的引擎，也不存在待上传队列。任何自称本地的工具都值得一验；相信面板，别信承诺。

本地转换不是魔法，夸大它对谁都没好处。引擎（Pandoc 约几十 MB）总得下载一次，这次请求会像所有网络请求一样暴露 IP 与 User Agent，也依赖 TLS 与所交付代码的完整性。

另一些边界来自环境：浏览器扩展能读取页面内容，恶意扩展足以击穿任何隐私声明；被入侵的机器击穿一切；页面也可能在获得信任后改变行为。稳妥姿态是逐站验证、少装扩展、大更新后复查。

本站的本地存储刻意保持极小：Pandoc WebAssembly 引擎缓存在 Cache Storage，首次使用后可离线转换；主题等界面偏好存在 localStorage。清单到此为止。

你的文档只在转换运行时存在于内存，输出到达磁盘只因你点了下载。没有需要注销的账号、没有要申请删除的服务器副本、没有记录转换历史的分析轨迹。关掉标签页，留下的只有引擎缓存和主题偏好。

数据保护法有一条原则与这种架构天然契合。GDPR 的数据最小化要求个人数据限于必要范围——一个接触不到文档的转换器几乎从构造上满足它：文件不过网线，就没有需要尽调的处理者，不必签数据处理协议，也无跨境传输评估。

这不是法律意见，也不代表工作流自动合规——内容仍要在存储之处被合法处理。但把转换搬到客户端，确实从风险评估中移除了一整类第三方暴露，这正是医院、律所等坚持文件不出设备的工具的原因。