有段时间我每周都要为一个数字反复折腾：上传到底能收多大的文件。看着硬盘里现成的东西，几百 KB 的截图、两三个 GB 的电影，中间那一档"刚好 10 MB""刚好 49 MB"的一个都没有。我拿电影文件试过，改后缀、剪切一半，出来的大小从来不是我要的那个整数；写脚本用 dd 造一个吧，单位又和我以为的不一样。后来我改成直接按需要的字节数生成，这件事才从"找文件"变成"算文件"。
麻烦的根源：你以为的单位不是它真的单位
我在 任意大小文件生成 里可以填字节、KB、MB、GB，还能精确到个位字节，文件名和扩展名也自己定。但填之前必须先想清楚一件事：同一个"10 MB"，两种解释差了 485760 字节。
十进制解释是 1 MB = 1000000 字节，二进制解释是 1 MiB = 1048576 字节，后者比前者多 4.8576%。这个百分比在 MB 这一档是固定的，往上到 GB 会变成 7.3741824%。我把常用的几档算出来摆在这，之后要卡边界值就直接查这张表。
| 你写的 | 按 1000 换算（字节） | 按 1024 换算（字节） | 差值（字节） |
|---|---|---|---|
| 1 MB | 1000000 | 1048576 | 48576 |
| 10 MB | 10000000 | 10485760 | 485760 |
| 100 MB | 100000000 | 104857600 | 4857600 |
| 1 GB | 1000000000 | 1073741824 | 73741824 |
所以"限制 10 MB"这句需求，如果对面是按 1024 算的，你给一个正好 10000000 字节的文件它是收的；反过来对面按 1000 算、你生成了 10485760 字节，就会超 485760 字节被拒。我第一次撞这个坑就是这个方向。要测"卡在上限的那一个字节"，我现在的写法是先去确认对面用哪种口径，再直接填字节数，不填 MB。
顺带一句老生常谈但我真的被问过：标称 1 TB 的盘，在按 1024 折算的系统里显示约 931，因为 1000000000000 除以 1073741824 约是 931.32，差的是单位不是缺斤短两。
全零的文件压完只剩几十 KB，那不是压缩率高
测压缩的时候我犯过一次糊涂：生成一个 10 MiB 的文件，zip 完只剩十几 KB，我差点把结论写成"压缩率一千倍"。错在我填的是全零。
压缩压的是重复和规律，不是体积。全零是规律性最强的内容，DEFLATE 这类算法对它的理论极限大约是 1032 比 1，也就是说 10485760 字节的零，理论下限也就一万字节上下，实践中还要看块大小和实现。换个填充模式，同样 10 MiB 可能几乎压不动：如果我填的是随机数据，内容本身没有可利用的规律，压完体积基本不变，甚至因为压缩容器的头部和校验信息反而略微变大。图片、视频这类已经高度压缩过的内容，也是同样道理，你把它再压一遍掉不了多少。
所以我的规矩是：先决定这次测的是"体积上限"还是"压缩行为"。测上限用随机数据，才接近真实文件的压缩表现；只有专门要看压缩算法对低熵内容的表现时，才用全零。拿全零去报告"我们的上传体积能压到几十 KB"，是把内容特性说成了链路能力。要真比较压缩前后，我会用 图片压缩 拿一批正常照片做参照，那张表里缩小的比例才是可以拿去讲的。
文件"多大"有两种答案：逻辑大小与实际占用
另一个让我误判过的点：一个文件的字节数和它在磁盘上真占的空间，可以差很多。
只把文件长度设到位而没有逐字节写过数据的做法，在支持稀疏分配的文件系统上，逻辑大小可以是 10485760，实际占用的数据块接近零。这时候 ls -l 给你的数字和 du 给你的数字会明显不一致。我踩过的那次是照计划灌满某个测试分区，用稀疏文件写了很久都没满，因为真正落到盘上的数据少得可怜。
要判断自己手上是哪一种，我的办法很笨但可靠：生成以后看实际写入耗时，或者用 文件信息读取 把大小列出来核对逻辑大小，再配合文件系统自己的占用统计比一遍。需要"真的占住这么大空间"的容量测试，就不能只看列表里那个数字。
至于浏览器里生成这种方式的边界，我是按它的说明用的：流式生成，最大到数百 MB 这个量级；需要几 GB 的测试文件，我回到本机命令行去做，不硬撑浏览器。
三种填充模式我分别拿来测什么
| 填充模式 | 内容特点 | 我用来测 | 不适合测 |
|---|---|---|---|
| 随机数据 | 几乎不可压缩，体积接近真实文件 | 上传下载限速、体积上限、磁盘占用 | 压缩算法的极限表现 |
| 全零字节 | 规律性最强，压完极小 | 只看接口是否按字节数放行 | 压缩比、真实带宽 |
| 自定义文本循环 | 可预测的可读内容 | 解析、导入、预览逻辑 | 高熵内容的传输表现 |
测限速这件事我也想补一句：拿一个 100 MiB 的文件传完用了 25 秒，是 104857600 除以 25，等于 4194304 字节每秒，换成兆比特要乘 8 再除一百万，约 33.6 Mbps。字节和比特这两个 B 我当年混淆过一次，结果把链路速度估小了八倍。
常见问题
Q：我要"刚好 10 MB"，到底该填什么数？
先问对面按 1000 还是按 1024。按 1000 就填 10000000 字节，按 1024 就填 10485760 字节。这两个数差 485760 字节，随便挑一个都可能不是你要的。测试上限时我一般从小的那一档起步，再一档一档往上加。
Q：为什么生成的文件压完只有几十 KB？
因为你填的是零或者循环重复的文本，压缩掉的是规律不是体积。想让它压不动，就换随机数据填充。
Q：测上传限制，只测一个刚好达标的文件够吗？
不够。我至少打三个点：刚好在限内、正好等于限制值、超一个字节。中间那一点最容易被"小于等于"和"小于"的写法搞错，光测一个正常大小的文件试不出来。
Q：逻辑大小对上了，为什么磁盘没涨？
可能是稀疏分配，长度写到位而数据没落盘。用文件系统的占用统计再核一遍，别只看列表里的字节数。
回到最初那个"找一个刚好 10 MB 的文件"的问题。我现在的做法是先确认对面用 1000 还是 1024，然后按字节数生成，填充选随机数据，生成完核对一次大小再传。听起来只是多算了一步，但它把我从前反复试错的那半小时彻底省掉了。