不上传也能做完的几类文档处理

做工具久了有个习惯：每接一个「处理文件」的需求，先问一句这活儿到底用不用上传。很多默认要传服务器的处理，其实浏览器本地就能做完，一个人做产品的时候，这个区别直接决定了要不要养一台后端、要不要背用户文件的隐私责任。

先说为什么这事对独立开发者格外重要。文件一旦上传，你就得管：存多久、谁能读、真删了没有，出了事是你的责任。而用户最不想传的文件——合同、证件、没发布的资料、带隐私的截图——恰恰是「文档处理」最常见的输入。能在本地做完的，就别让它离开用户设备，省的不只是服务器钱，是一整摊你本可以不背的麻烦。

这几年我陆续把这几类挪到了本地，都是浏览器里跑、文件不出网的：

图片 OCR，识别、版面重建、导出 TXT / Markdown / 坐标 JSON，全程本地；PDF 压缩，逐图重编码加结构优化，压完还回读校验；PDF 转 HTML，按坐标重建成单文件、文字还能选；PDF 提取图片，从页面资源里抠出真正的图而不是整页截图；DOCX、PPTX 转 HTML，把 Office 文档转成内联单文件。这些的共同点是：处理逻辑本身不依赖服务器算力，纯粹是解析和重编码，浏览器的 WASM 和 Canvas 完全扛得住。

图映把这些做成了一套都在本地跑的工具，我拿它当过参照——一个判断某类处理能不能端侧化的现成清单。它自己也把话说得很实：模型和运行时会从站点下载到浏览器，但原图和识别文字不上传，这两件事得分清，下载模型不等于上传文件。

这类工具我都会花十秒自己验一下，办法很笨但有效：开 F12 的 Network 面板，处理一张图，看有没有把图片 POST 出去的请求，再看预览图的地址是不是 blob: 开头。有模型下载请求是正常的，那是把模型拉到本地；只要没有上传图片的请求，就说明处理确实在本机。这一步对独立开发者尤其值得做——你要照着别人的方案做端侧化，得先确认它真是端侧的，别被「本地」两个字的说法骗了。

反过来得划清楚，不是所有「文档处理」都适合本地。要跨文件汇总、要服务端才有的字体或算力、要多人协同同一份数据的，本地做不了或不划算，这些仍然该放服务器。还有一类是格式本身太重，比如某些需要专用引擎的转换，浏览器给不了可靠结果，硬塞本地只会出一堆边缘 bug。

所以我的判断标准就一条：这个处理是不是「解析 + 重编码」这种自包含的活，是就优先本地——省服务器、免上传、还顺带解决了隐私；不是就老实放服务端。上面那几类之所以能挪，正因为它们都落在「自包含」这一侧。