原文：https://dev.to/muhayminbinmehmood/your-image-converter-probably-doesnt-need-your-image-on-a-server-4415 (作者 @muhayminbinmehmood)
大多数在线文件工具都遵循相同的架构：
选择文件 ↓ 上传文件 ↓ 服务器处理 ↓ 服务器存储临时结果 ↓ 下载结果
这个架构是合理的。
但对于许多图片操作而言，这并非总是必要。
现代浏览器可以本地解码、转换和导出常见图片格式。这意味着一些工具可以完全不将原始图片发送到后端就能工作。
这以一种有趣的方式改变了架构。
选择文件 ↓ 浏览器本地读取 ↓ 浏览器进行转换 ↓ 下载结果
没有上传步骤。
对于合适的用例，这是一个有意义的改进。
为什么客户端处理有吸引力
1. 隐私
如果文件无需离开设备，你就能消除一整类问题：
- 文件存储在哪里？
- 存储多久？
- 是否有日志记录？
- 是否被复制到对象存储？
- 是否涉及第三方处理器？
- 清理工作是否真的在进行？
客户端处理不会神奇地让应用变得安全，但它可以减少需要通过网络传输的敏感数据量。
对于个人照片、未发布的营销素材、客户作品、截图和内部图片，这一点很重要。
2. 减少上传延迟
上传一个 2 MB 的文件通常没问题。
上传 100 个文件则是完全不同的体验。
如果转换可以在本地完成，用户就不需要等待：
上传 → 服务器队列 → 处理 → 下载
才能看到结果。
网络条件变得不那么重要了。
3. 降低后端成本
如果你的后端为每个免费用户执行 CPU 密集型的转换，基础设施成本会随着使用量直接增长。
将合适的工作转移到客户端可以减少：
- CPU 使用率
- 临时存储
- 带宽
- 队列压力
这对于免费实用工具尤其有趣，因为单个操作的服务器成本可能大于该用户产生的收入。
4. 更好的离线潜力
不依赖处理 API 的浏览器工具，有时即使在连接受限的情况下也能继续工作，这取决于应用本身的交付和缓存方式。
这与纯服务器工具的用户体验非常不同。
浏览器实际上能做什么？
对于常见格式，浏览器 API 已经能处理令人惊讶的大量工作。
典型的构建模块包括：
FileBlobFileReadercreateImageBitmap()<canvas>OffscreenCanvas- Web Workers
一个简化的流程可能如下：
const file = input.files[0];
const bitmap = await createImageBitmap(file);
const canvas = document.createElement("canvas");
canvas.width = bitmap.width;
canvas.height = bitmap.height;
const ctx = canvas.getContext("2d");
ctx.drawImage(bitmap, 0, 0);
const result = await new Promise(resolve => {
canvas.toBlob(resolve, "image/webp", 0.82);
});
这个示例有意保持极简，但重要的概念是：图像可以在没有传统的上传-处理-下载循环的情况下被解码和重新编码。
难点不在于演示
一个单文件的演示很容易。
生产环境下的行为则更为复杂。
你必须考虑：
- 内存使用
- 大尺寸图像
- EXIF 方向信息
- 透明图片
- 浏览器支持
- 输出质量
- 取消操作
- 进度报告
- 多文件处理
- UI 响应性
如果一个用户向浏览器拖入 200 张高分辨率照片，而你同时解码所有文件，很容易导致标签页崩溃。
所以“客户端”并不意味着“同时处理所有内容”。
受控的并发很重要
一个更安全的批量处理架构使用队列。
不要这样做：
await Promise.all(files.map(processImage));
你可能需要一个受控数量的活跃任务。
概念上：
200 个文件等待 Worker 1 → 一张图片 Worker 2 → 一张图片 Worker 3 → 一张图片 Worker 4 → 一张图片 完成一个 → 取下一个
正确的并发度取决于工作负载和设备能力。
目标不是最大化并行度。
目标是在不使浏览器无法使用的情况下获得有用的吞吐量。
何时服务器仍是更好的选择
客户端处理不是一种教条。
有很多情况下，后端是合适或必需的：
- 不支持的编解码器
- 极大的文件
- 昂贵的 AI 模型
- 服务器端持久化
- 共享的团队工作流
- 集中式处理规则
- 需要原生库的转换
- 必须在标签页关闭后继续运行的任务
架构应该服务于任务本身。
一个产品设计层面的启示
一旦基本的图片转换可以在本地完成，产品就可以做出更强有力的承诺：
“你常见的图片转换无需上传到服务器进行处理。”
这是我正在开发的 BatchSet 中基本图片工作流背后的设计目标之一。
我提到它，是因为它是我一直在探索这种架构的真实产品，而不是因为每个应用中的所有转换都应该在客户端进行。
更广泛的教训
在添加另一个 API 端点、队列、存储桶和清理任务之前，先问一个问题：
服务器真的需要这个文件吗？
有时答案是“是”。
有时浏览器已经足够强大，可以在更靠近用户的地方完成工作。
而当答案是“浏览器可以处理它”时，你可能会同时获得隐私、速度和基础设施方面的收益。
原文：https://dev.to/muhayminbinmehmood/your-image-converter-probably-doesnt-need-your-image-on-a-server-4415 (作者 @muhayminbinmehmood)
