为什么转换应该发生在你的浏览器里
大多数"文档转 Markdown"工具的工作方式是：你把文件上传到它们的服务器，服务器转好，再把结果发回来。这很方便，但也意味着——在你按下"转换"的那一刻，资料已经离开了你的电脑。对一份公开的说明文档无所谓，但对公司财报、未公开合同、个人笔记，这就是另一种性质的事了。
两条路线的差别
| 维度 | 上传到服务器 | 浏览器本地（Everything to Markdown） |
|---|---|---|
| 文件去向 | 离开你的设备，到达第三方 | 始终留在本地 |
| 隐私风险 | 取决于对方的数据政策与合规 | 无第三方经手，风险趋近于零 |
| 延迟 | 网络往返 + 排队 | 本地计算，毫秒级 |
| 离线可用 | 不行 | 加载一次后完全离线 |
| 规模成本 | 对方要养服务器 | 算力由你的设备承担 |
WebAssembly 让"本地"变现实
过去，"在浏览器里跑复杂转换"听起来不靠谱——浏览器是跑界面脚本的地方，不是跑文档解析器的地方。但 WebAssembly（WASM）改变了这一点：它让用 Rust 之类语言写的高性能代码，能被编译成一种浏览器能高效执行的字节码。
Everything to Markdown 借鉴的开源模型，正是把整套 Rust 解析/序列化管线编译成了 WASM。于是：
- 首次打开页面时，下载几 MB 的 WASM 模块到本地；
- 之后每一次转换，都在这台设备上完成；
- 甚至断网后，只要页面还在，转换照常工作。
没有服务器，就没有"资料上传"这一说。隐私不是靠承诺，而是靠架构从根上消除了上传动作。
快，是本地化的副产品
本地转换的另一个红利是速度。一篇文档的转换，中位时间不到 5 毫秒——比一次网络请求的往返还短几个数量级。你拖进去，结果几乎瞬间出现，没有"上传中…""转换中…"的等待。
更妙的是，没有服务端就意味着没有并发上限：你转一份和转一百份，对"服务器"都没有压力，因为根本没有服务器参与。
代价与边界
本地路线也不是万能的，得说清楚：
- 首次需联网加载 WASM（之后可缓存离线）；
- 极个别超大型文件受限于浏览器内存，不如服务器端能横向扩展；
- 扫描型 PDF 的 OCR 这类重计算，本地 WASM 不擅长（见下一篇）。
但对"把各种资料转成 Markdown"这个核心场景，本地化几乎是全面占优：更快、更私密、可离线、零运维。
小结
Everything to Markdown 把转换放进你的浏览器，不是偷懒，而是刻意的取舍：用架构换取隐私与速度。下一篇，我们把视线收束到最棘手的一种格式——PDF，看看本地路线的边界到底卡在哪里。