零服务器、零上传：58个浏览器工具的技术拆解

你有没有想过，那些"免费在线工具"网站，为什么总要你上传文件？PDF压缩、图片转换、视频剪辑——明明只是简单处理，却非要经过别人的服务器，注册账号、限制大小、最后还可能给你加个水印。你的数据躺在陌生人的硬盘上，删没删只有天知道。

这套玩法我看腻了。于是做了ToolKnit：58个工具，全部在浏览器里跑。没有后端，没有上传，没有数据库，没有账号系统。只有静态HTML、CSS、JavaScript，加上一堆WebAssembly。

这不是情怀，是技术判断。2026年的浏览器API已经足够强悍，90%的在线工具需求都能在本地解决。剩下的10%（比如服务器端AI、大规模视频转码）不值得为那90%牺牲隐私。

架构核心：没有服务器

ToolKnit是个纯静态站点。每页都是普通HTML，单一域名下发。没有Express，没有Lambda，没有收文件的S3桶。你压缩PDF时，运算在你设备上完成；PNG转WebP时，浏览器的Canvas API处理像素。数据不出本机。

技术栈刻意复古：没有React，没有Vue，没有构建步骤。每个工具是自包含的HTML页面，内联script标签。零打包体积开销，页面秒开，Service Worker还能独立缓存每个工具。

58个工具，8个类别

以下是零字节上传能做的事：

PDF工具（6个）

压缩、合并、PDF转图片、图片转PDF、PDF转Word、Word转PDF。核心依赖pdf-lib跑在WebAssembly里。压缩逻辑是降采样内嵌图片、剥离无用元数据——文字质量无损，图片多的文档体积大减。

图片工具（12个）

压缩、裁剪、缩放、网格分割、像素画转换、翻转旋转，外加六种格式互转（JPG↔PNG↔WebP）。

像素画转换器是我偏爱的一个。中位切割法量化颜色，可选抖动算法（Floyd-Steinberg、有序抖动、Atkinson），内置Game Boy、NES、SNES调色板预设。全部代码约400行原生JS。

视频工具（3个）

压缩视频、视频转GIF、视频转音频。FFmpeg.wasm是个狠角色——完整FFmpeg编译到WebAssembly，H.264编解码、GIF封装、音频提取，全在一个标签页里跑。代价是首次使用要下载约25MB的WASM文件，之后Service Worker缓存。

音频工具（2个）

MP3转WAV、WAV转MP3。Web Audio API负责解码，MP3编码用WASM版LAME。码率可选128-320 kbps。

文本工具（6个）

字符计数、Lorem Ipsum生成器、文字提取（OCR）、二维码生成器、密码生成器、文本对比。

密码生成器用crypto.getRandomValues()，不是Math.random()。后者是伪随机，前者是真随机源，密码学安全。

编码/解码工具（8个）

Base64、URL编码、HTML实体、JWT解析器、JSON格式化器、CSV转JSON、JSON转CSV、YAML转JSON。全是字符串操作，零依赖。

颜色工具（5个）

颜色选择器、HEX/RGB/HSL互转、调色板生成器、对比度检查器、渐变生成器。Canvas API读像素值，WCAG 2.1公式算对比度。

开发者工具（16个）

这个类别最杂：正则测试器、CSS压缩/美化、JS压缩/美化、HTML压缩/美化、Markdown预览、SQL格式化器、UUID生成器、Hash生成器（MD5/SHA-1/SHA-256/SHA-512）、Cron表达式解析器、Unit Converter（px/rem/em/pt）、HTML转JSX、SVG优化器、Favicon生成器、.htaccess生成器、robots.txt生成器、Sitemap生成器。

Hash生成器用Web Crypto API，不是CryptoJS。原生API更快，不需要额外库。

性能数字

首屏加载：静态HTML，无JS阻塞，<100ms。工具切换：Service Worker缓存，离线可用。内存占用：单工具通常<50MB，视频处理时FFmpeg.wasm峰值约200MB。隐私成本：零。你的文件从未离开浏览器沙箱。

边界与妥协

不是所有事都能浏览器里做。>2GB的视频文件会触发内存限制；某些老旧编解码器FFmpeg.wasm不支持；OCR依赖Tesseract.js，识别精度不如云端API。这些我直接不做，而不是假装能解决。

另一个妥协是冷启动。FFmpeg.wasm的25MB下载对慢网用户不友好。对策：延迟加载，用户点击视频工具时才拉取，外加进度条和缓存提示。

为什么不用框架

React或Vue能省多少代码？我算了下：58个工具，平均每个200行JS。框架的组件抽象能省大概30%，但打包体积加200KB+，构建复杂度翻倍，还要处理hydration和状态管理。对于独立页面、无共享状态的静态工具，这笔账不划算。

inline script的另一个好处：每个工具是完整文档，直接打开HTML文件就能跑。调试时不需要dev server，改完刷新即生效。

WebAssembly的角色

没有WASM，这个项目不存在。pdf-lib、FFmpeg、LAME、Tesseract——这些原本服务器端的库，现在浏览器里跑。WASM不是万能药：启动慢、体积大、不能操作DOM。但对计算密集型任务，它是唯一选择。

我的用法很克制：只在必须时用WASM，纯JS能做的事（颜色转换、字符串编码）绝不多拉一个二进制。

Service Worker的策略

缓存分两层：工具外壳（HTML/CSS/JS）用CacheFirst，永久缓存；WASM二进制和字体用StaleWhileRevalidate，后台更新。用户永远有东西用，只是偶尔拿到旧版本。

一个细节：WASM文件大，我用range request分段缓存。浏览器支持不好时回退到完整下载。

商业模式：没有

58个工具全免费，无广告，无捐赠按钮。托管在Cloudflare Pages，流量成本≈0。我的成本是时间：两年业余开发，约400小时。

这不是可持续的商业模式，但也不是慈善。它是技术演示——证明浏览器能做什么，以及我们被"上传-处理-下载"范式驯化得多深。

一个反直觉的发现

用户并不关心隐私。 analytics显示，"隐私保护"页面的访问量垫底。人们选ToolKnit是因为快——不用注册、不用等上传、不用看广告。隐私是副作用，不是卖点。

这让我重新理解产品：技术理想主义（去中心化、数据主权）是工程师的执念，用户要的是省时间。两者碰巧对齐，但动机完全不同。

给想复制的人

技术门槛不高：熟悉Canvas API、Web Audio API、Web Crypto API，能读C代码（调WASM库时需要）。真正的挑战是边界判断——什么事该做，什么事该承认做不了。

我的筛选标准：输入是文件或文本，输出是文件或文本，计算能在3秒内完成，内存占用<500MB。不满足任一条件的，进不了工具清单。

代码组织上，我试过共享库、工具类继承、甚至生成器——最后全拆了。58个独立HTML文件，重复代码就重复。维护简单，调试简单，用户只下载需要的代码。

最后

ToolKnit不会取代专业软件。设计师还是要用Photoshop，视频剪辑师还是要用Premiere。但对于"偶尔用一次"的场景——压缩个PDF、转个格式、提取段文字——打开浏览器就能解决，何必安装、何必上传、何必信任陌生人？

浏览器已经是个操作系统了。我们只是习惯把它当成文档阅读器。