接外包这些年我在需求文档里见过不少回「图片不超过 200KB」这句话。前端压一遍再让后端卡一遍看着像双保险。2026-09-28 晚上我跑的一组压图测试里有个结果正好卡在这句话的缝里。我用二分法找质量把一张 1920×1080 的风景照用浏览器自带的 JPEG 编码压到了质量 70出来的文件是 204 214 字节。这张照片是系统自带的不是我拍的。测试机是一台 16 GB 内存的 Apple M4 Mac。浏览器是 Chromium 149 开源构建编码用的就是浏览器内置的 canvas.toBlob。KB口径不一让后端拒收压好的图按 200×1024 算的话上限是 204 800 字节这个文件离上限还有 586 字节。按 200×1000 算的话上限只有 200 000 字节这个文件就超了 4 214 字节约 2%。要是前端常量写成200 * 1024、后端写成200000就会出现前端说压好了、后端却不收的情况。反过来也亏前端按 1000 压、后端按 1024 收的话前端就白白多让了一截画质还没人发现。换成 2MB 差距更大2 097 152 和 2 000 000 差了 97 152 字节接近 5%。这张图里同一个 204 214 B 的文件拿去跟两条上限比一条判它合格另一条判它超标。文件一个字节都没变变的只是两段代码里 KB 各自算多少。截图是单次运行的结果。对不上的也不只是 KB。质量这个数字界面上一套、代码里又是一套。我顺手在同一台 Mac 上打开图映 ImgIng一个在线的免费图片处理工具的图片压缩看了一眼。界面上的质量滑杆是 30 到 100。我翻了页面脚本界面上拉到 100 时送进编码器的是 0.99。界面上写的数和代码里用的数不是一回事接需求时得先问清楚对方说的是哪一个。让前后端判得一样的七个做法字节数只写一处。配置里存 204800 或 200000 这样的整数前端表单和后端校验都从这一个值读。需求文档里写的「200KB」只当说明不进代码。我以前有个项目在 Vue 组件和 PHP 配置里各写了一次常量。后来客户改需求时我只改了其中一边。前端比后端严一点。实在统一不了就让前端按 200 000 压、后端按 204 800 收。多出来的 4 800 字节当缓冲用代价是画质要再让一点。这张图按 200 000 压要降到质量几我这次没测也就不瞎报了。别拿字符串长度去比大小。有的写法先把图转成 dataURL 再上传这一转成 base64 体积就涨了三分之一左右。前端拿 dataURL 的长度去比 200KB判出来的结果和后端收到的文件对不上。搞清楚后端数的到底是什么。我的小站用 nginx它的 client_max_body_size 限的是整个请求体。multipart 的分隔符和字段名也都算在里面。nginx 配置里写的 k 是按 1024 算的。文件本身 204 214 字节的话请求体还要再大一点。到底多出多少这回我没去量。我现在的习惯是把请求体上限放得比文件上限宽一截。提示文案里把换算写清楚。Mac 的访达按 1000 进位显示大小Windows 资源管理器按 1024 算却也标 KB。一个 204 800 字节的文件在 Windows 上显示 200 KB在访达里显示的是 205 KB。两台电脑前的人照着各自系统显示的数去判断会得出相反的结论。我现在的文案直接写字节数再在括号里补一个约数。拒收时把两个数都返回。后端报错别只写「文件过大」。把实际字节数和限制字节数一起回给前端的话排查一分钟就完事。有一回报错只有「过大」两个字我查了一下午茶都泡淡了三泡。测试集里留一个边界文件。放一张大小在 200 000 到 204 800 字节之间的图让前后端各跑一次。这次测出来的 204 214 字节那张 JPEG 就是现成的边界样本。接手新项目时我先在代码里搜1024和1000两个数把跟上传大小有关的常量全列出来。再拿一个 200 000 到 204 800 字节之间的文件从前端传到后端走一遍。两边判得不一样就改成同一个字节常量。