两种架构的本质差别
上传式：你的文件离开设备，经网络到达对方服务器，被写入磁盘、可能进日志与备份，处理完再回传结果。本地式：页面里的 JavaScript 或 WebAssembly 在你的设备内完成计算，网络上只传输“页面代码”，你的数据不出本机。
上传式架构的三个风险点
- 传输与存储：HTTPS 只保护传输过程，文件落盘后是否加密、保留多久，取决于对方；
- 留存与备份：为了排查问题或“提升服务”，文件常被写入对象存储或日志，删除承诺难以验证；
- 合规成本：含个人信息的文件交给第三方处理，可能构成数据出境或委托处理，需要评估与告知。
本地式架构的边界（也别过度信任）
- 代码可被篡改：站点一旦被入侵或投毒，“本地处理”的代码本身可能被改；因此要看来源可信度与是否开源；
- 浏览器扩展：有权限的扩展可以读取页面内容，与工具本身无关；
- 本机安全：设备被木马控制时，任何方案都无解。
怎么判断一个工具是真的本地处理
- 断网测试：页面加载完成后断网，功能仍可用 → 大概率是本地计算；
- 看网络请求：打开开发者工具 Network 面板，导入文件时若出现上传请求，就不是本地处理；
- 看隐私说明与实现：是否明确写明“不上传”，是否开源，CSP 是否限制了对外连接；
- 看处理位置提示：靠谱的工具会直接说明所用技术（如 Web Crypto、WASM）。
适用建议
身份证、合同、源代码、聊天截图这类敏感文件，优先选择本地处理的工具。超大文件受浏览器内存限制时再考虑服务器方案，此时先确认对方的留存与删除策略，并尽量先脱敏。
哪些任务适合本地处理
| 任务 | 本地处理 | 说明 |
|---|---|---|
| 文件哈希校验 | 很适合 | Web Crypto 直接计算，大文件可流式读取 |
| 图片水印 / 压缩 | 很适合 | Canvas 处理，导出即成品 |
| OCR 文字识别 | 适合 | WASM 模型体积较大，首次加载稍慢 |
| 视频转码 | 一般 | 受设备性能限制，长视频耗时明显 |
| 超大文件批量处理 | 不适合 | 浏览器内存有限，需要服务端方案 |
团队里如何落地这套原则
- 先给数据分级：分为可公开、内部、敏感三级，只有敏感数据才强制要求本地处理；
- 再定工具清单：列出允许使用的在线工具与明确禁止的场景，写进团队规范而不是靠口头提醒；
- 用技术手段兜底：断网复测、查看网络请求、必要时在隔离环境或离线机器上处理；
- 定期复查：工具会改版，半年前「本地处理」的结论不一定现在还成立。
如何自证“数据不上传”
- 可断网验证：核心功能应在断网后仍可用，这是最直观、最有说服力的证明；
- 看网络面板：打开开发者工具的 Network 面板操作一遍，确认没有携带输入的请求；
- 用 CSP 佐证：
connect-src只放行必要域名，等于对外承诺了可连接的边界； - 开源与可审计：能公开源码的工具，任何人可自行验证，比口头承诺更可靠。
本地优先的适用边界
本地处理并非万能：需要跨设备同步、共享链接或统一计费的场景仍要服务端参与。务实的划分是“原始数据留在本地、只上传必要的结果或统计”，并在隐私说明里写清哪些数据会离开设备、以什么形式离开，这比笼统宣称“绝对不上传”更可信。