从bit到TB：网速与硬盘容量为何总对不上？一文搞懂单位换算

你有没有遇到过这种情况：刚办了 1000M 宽带，结果测速软件里死活只显示 120MB/s；新买一块 1TB 移动硬盘，插上电脑却只剩 931GB；把标称 64GB 的存储卡塞进行车记录仪，格式化完发现可用空间只有 58GB。每次都觉得容量被人“偷走”了，但真要解释又说不清楚到底差在哪。

其实这些看似玄学的现象，背后就是同一套从 bit 到 TB 的单位换算规则在起作用。我虽然不是搞计量出身，但在存储、网络、嵌入式和日常文件管理里折腾了十几年，发现绝大多数容量纠纷和单位混淆，都是因为三条线没理清：bit 和 Byte 的 8 倍关系、十进制和二进制两种进位制、厂商标称和系统显示用的不是同一套口径。这篇文章我就把这整条换算链从头到尾拆开讲一遍，不绕弯子，直接把公式、坑点和心算技巧都给你。

1. 从电子信号讲起：bit 为什么是计算机的“最小筹码”

1.1 0 和 1 不是数学概念，而是物理状态

很多人一听 bit 就觉得是二进制数字，但它在硬件层面的本质其实是一组物理状态。CPU、内存、闪存芯片内部，靠的是电压高低、电流通断、磁极方向或电荷有无来区分信息。比如一块 NAND 闪存单元里有没有电荷，对应读出 0 还是 1；DDR 内存里电容充电和放电，也对应两种稳定状态。既然电路天然只有两个稳定状态，那用 0 和 1 去表达就最省事，这也是整个计算机体系以二进制为地基的原因。

一个 bit 能表达的信息量很有限，只有 0 或 1 两种取值。两个 bit 组合起来有 2 的 2 次方，也就是 4 种状态；三个 bit 是 8 种；八个 bit 就是 2 的 8 次方，256 种。这个规律往后面看特别重要，因为存储容量、地址空间、字符编码全在跟“2 的 n 次方”打交道。你只要记住：bit 是信息量的最小单位，它不是给人看的，而是给机器电路认的。

顺便说一句，很多做开发的朋友一开始写代码，变量用 int、数组开多大，很少回过头想这些数字到底占了几个 bit。可一旦做嵌入式或网络协议，要面对寄存器位宽、报文头长度、数据对齐这些问题，就得重新把 bit 的账一笔一笔算清楚。我曾经调试一个通信协议，收发两端怎么都对不上数据，最后发现是结构体里某个字段使用了位域，编译器按 4 字节对齐后，接收端按 1 字节去解析，整个报文错位。这就是典型的不把 bit 当回事的后果。

1.2 8 个 bit 凑成一个 byte，背后是字符与寻址的历史

有了 bit 之后，计算机还得解决“怎么读写方便”的问题。如果每个 bit 单独编一个地址，地址表会庞大到不可接受，而且早期的字符编码也需要一个能覆盖字母、数字、符号的固定位数。ASCII 用 7 位就能覆盖 128 个字符，但计算机内部按字节处理更顺手，最终行业统一成 8 位一组，也就是 1 Byte 等于 8 bit。Byte 中文翻译叫“字节”，这名字起得很直观——它确实是计算机处理文字、图片、程序指令的“最小可寻址单位”。

字节还有一个很容易忽略的特性：内存地址是按字节编址的。也就是说，你给一个变量分配空间，地址每次挪动 1 个字节，而不可能精确到某一位。日常开发里，数组越界、指针偏移、文件指针跳转，底层其实全都在跟字节打交道。举个例子，一个 char 数组在 C 语言里占用多少字节，取决于平台和字符集，但基本单位永远是字节，而不是 bit。

这里要特别区分两个词：bit 中文叫“比特”，Byte 中文叫“字节”。中文语境里“位”和“字节”差 8 倍，英文语境里 b 和 B 也差 8 倍。很多人写文档时顺手写“1MB=1024KB”“1M=1024K”都不带单位，在口语里问题不大，一旦进入正式规格书或者技术方案里，不写明白是 bit 还是 Byte，后面就会出大乱子。

2. 网速与文件大小总对不上？bit/Byte 的 8 倍陷阱在这里

2.1 宽带的 100M 是 bps，下载工具的 12.5MB/s 才是“体感速度”

先回答开头那个疑问：为什么办了 100M 宽带，下载最快也就 10MB/s 出头？

运营商标称的 100M、300M、1000M，单位是 Mbps，也就是兆比特每秒（Mbit/s）。这里的 M 是 10 的 6 次方，bit 是比特。而下载工具、浏览器进度条显示的 MB/s，是兆字节每秒。比特换算成字节要除以 8，所以理论上限是：

100 ÷ 8 = 12.5MB/s

300M 宽带的理论上限就是 300 ÷ 8 = 37.5MB/s，1000M 宽带是 125MB/s。

但实际使用中几乎跑不到这个理论值。原因有几个：以太网帧本身有前导码、帧间隔、IP 头和 TCP 头这些开销；无线网络还会受信号衰减、信道干扰、双工模式影响；运营商的接入网也可能存在峰值限速。我自己常年帮朋友测速，1000M 宽带在千兆网口下实际跑到 110~118MB/s 是正常的，100M 宽带稳定在 9~11MB/s 也属于健康范围。

所以这里有个很实用的经验：跟人解释宽带速度时，与其精确除以 8，不如直接按 1:10 估。也就是 100M 宽带按 10MB/s 估，1000M 宽带按 100MB/s 估。这个估算值更贴近真实体感，而且心算特别快——去掉一个 0 就行了。真要谈理论极限再用除以 8。

2.2 大小写规则：B 和 b 差 8 倍

很多技术文档、商品页面、甚至软件界面里，单位符号的大小写是混乱的。这里有一条硬规则：大写 B 表示 Byte（字节），小写 b 表示 bit（比特）。所以：

• 1B = 8b
• 1KB = 8Kb
• 1MB = 8Mb
• 1GB = 8Gb

网速通常写成 Mbps 或 Gbps，存储容量通常写成 MB 或 GB。如果一个设备参数写着“传输速率 150MB/s”，另一个写着“接口带宽 150Mb/s”，这俩差了 8 倍，完全不是一个量级。尤其是在买交换机、路由器、网卡的时候，很多入门用户把 Mbps 和 MB/s 混为一谈，结果买回来发现局域网传文件远没有商家暗示的那么快。

我个人的习惯是：凡是看到单位带“ps”也就是每秒的意思，先警惕这可能是比特率；凡是描述存储文件大小，几乎必然是字节。两者要换算时，就记住一句话：大写 B 是 Byte，小写 b 是 bit，一个大写字母差了 8 倍。

2.3 视频码率推存储容量：一个能直接套用的公式

单位换算不只存在于宽带测速，视频监控、录像存储、直播推流每天都在用。假设一个摄像头码率是 4Mbps，也就是每秒产生 4 兆比特数据，那它一小时会产生多少录像？

先把比特换算成字节：4Mbps ÷ 8 = 0.5MB/s，也就是每秒 0.5 兆字节。一个小时是 3600 秒，所以：

0.5 × 3600 = 1800MB

按十进制换算成 GB 是 1.8GB，按二进制换算是约 1.76GiB。如果你硬盘标称容量按 1000 进制算，那实际占用的就是 1.8GB。这个差别在容量规划里可以忽略，但偶尔会有人卡在这里。

为了减少心算负担，我直接给一个衍生公式：1Mbps 码率，录制 1 小时，约等于 0.45GB。推导过程是 1Mbps ÷ 8 × 3600 秒 = 450MB，再除以 1000，就是 0.45GB。那么 4Mbps 的摄像头一小时就是 4 × 0.45 = 1.8GB，一天 24 小时就是 43.2GB。如果装 1TB 硬盘，按这个码率能存大约 23 天。

这类计算做监控方案或者规划 NAS 存储空间时特别有用。你不需要每次都打开计算器，直接把码率乘以 0.45 再乘以小时数，容量需求就出来了。

3. 完整换算链与 1000/1024 之争：KB、KiB 到底谁说了算

3.1 从 bit 到 TB 的级联表与幂运算

现在把整条链摆出来。从 bit 往上，依次是 bit、Byte、KB、MB、GB、TB。每一级之间，有两种进位法：

• 十进制进位：1KB = 1000B，1MB = 1000KB，1GB = 1000MB，1TB = 1000GB
• 二进制进位：1KiB = 1024B，1MiB = 1024KiB，1GiB = 1024MiB，1TiB = 1024GiB

十进制写法背后是 10 的幂，二进制写法背后是 2 的幂。更完整的对照如下：

如果你要一路推下去，二进制里 1TB = 1024GB = 1024 × 1024MB = 1024 × 1024 × 1024KB。也就是说，1TiB = 2 的 40 次方字节，约等于 1.0995 × 10 的 12 次方字节。而十进制 1TB = 10 的 12 次方字节，两者差了大约 9.95%。

严格来说，工程师手册里的“KB”默认是十进制 1000，“KiB”才是二进制 1024。But 在现实世界，Windows 系统、内存容量、Linux 的 df 命令仍然大量使用“KB、MB、GB”来表示 1024 进制。这种混乱才是容量纠纷的真正来源。

3.2 十进制前缀和二进制前缀：厂商、系统、标准三方纠葛

为什么会有两套进位制？本质原因是行业没有从一开始就统一口径。硬盘、U 盘、SD 卡这类存储介质厂商，为了标称容量数字更好看，也为了符合国际单位制 SI 的十进制前缀，按照 1000 进位来标注容量。操作系统内部为了寻址方便，很多地方按 1024 进位来管理空间，但显示时又沿用了 KB、MB、GB 这些名称。

于是同一个 1TB 硬盘，厂商心里想的是 10 的 12 次方字节，Windows 却按 2 的 40 次方字节去除，显示成 931GB。你说厂商虚标？在标准意义上并没有，因为 GB 作为 SI 前缀就是 10 的 9 次方；你说系统显示错？也没有，因为 Windows 在磁盘管理里打印“GB”时，实际用的是 GiB 的数值。

后来国际电工委员会 IEC 在 1998 年推出了 KiB、MiB、GiB、TiB 这套二进制前缀，想终结这种混乱。Linux 的df -h、ls -lh早期输出里，默认显示的 G 其实经常是 GiB，新版工具则更严格区分。macOS 从 10.6 开始将磁盘容量显示改为十进制 GB，所以同样一块 1TB 硬盘，插到 Mac 上显示约 1TB，插到 Windows 上却显示 931GB。这经常被网友当成“Mac 更良心”，真相只是显示口径不同。

内存行业基本不走十进制，DDR4 8GB 模组就是实实在在的 8GiB，因为内存寻址天然按二进制设计，用 2 的幂做容量最合理。固态硬盘、机械硬盘、U 卡则普遍用十进制标称，因为你买到的物理介质虽然也是二进制存储，但厂商选择了 SI 标注方式。

3.3 心算口诀：不用计算器也能快速换算

日常用得最多的是两个心算套路。

第一个是网络带宽换算：Mbps 除以 8 得 MB/s 理论值，除以 10 得实际体验值。这条前面已经说过。

第二个是硬盘容量换算：标称十进制容量换算到 Windows 显示的二进制容量，GB 级乘 0.931，TB 级乘 0.909。比如 512GB 固态硬盘，Windows 显示约 512 × 0.931 ≈ 477GB；2TB 硬盘，Windows 显示约 2 × 0.909 ≈ 1.82TB。这里的 0.931 来自 1000 ÷ 1024，TB 对应的是 (1000 ÷ 1024) 的三次方。

如果你想知道具体少了多少百分比，也有个现成结论：GB 级大约少 6.9%，TB 级大约少 9.1%。所以看到一块 1TB 移动硬盘显示 931GB，不用惊讶，这是正常现象而不是质量问题。

再送一个小技巧：算法题或项目代码里，凡是要做容量规划，我统一以字节为中间单位。写入日志时记录字节数，展示时再转成可读格式。这样至少能保证统计口径一致，不会今天按 1024 算，明天按 1000 算，最后排查问题时对不上数。

4. 1TB 硬盘为何只剩 931GB：容量“缩水”的完整计算

4.1 一步步算给你看：从 10 的 12 次方字节到 931.32GiB

拿标称 1TB 的机械硬盘举例。厂商按十进制标注，1TB = 1,000,000,000,000 字节。Windows 文件资源管理器按 1024 进制计算容量，它把一个 GiB 定义为 1,073,741,824 字节，然后用这个数去除总字节数：

1,000,000,000,000 ÷ 1,073,741,824 = 931.32

所以显示为 931GB 或者 931GiB（取决于系统版本）。

如果是 2TB 硬盘，就是 2,000,000,000,000 ÷ 1,073,741,824 = 1,862.64GiB。Windows 会四舍五入显示 1.86TB。这里看起来像是“买了 2TB 只剩 1.86TB”，实际差值约 138GB，跟 1TB 差了 69GB 的逻辑一致。

这个差异不是故障，不是固件 bug，也不属于质量问题。它纯粹是两种进位制在你眼前“打架”的结果。你在任何正规渠道买的硬盘，只要健康状态正常，容量显示都是这个套路。

4.2 除了进制差异，还有哪些空间悄悄溜走

进制差异是最主要的原因，但绝对不是全部。格式化文件系统时，硬盘还会被以下几个部分占掉一部分空间：

• 分区表和引导区，比如 GPT 头部、EFI 系统分区，占几十到几百 MB。
• 文件系统元数据，包括文件分配表、inode、日志区、块组描述符。NTFS 的 MFT、ext4 的 inode 表都会预分配空间。
• Windows 系统恢复分区、厂商预装的隐藏镜像，这部分能轻松吃掉 10~20GB。
• SSD 的 OP 预留空间（Over-Provisioning），主控会保留一部分闪存空间用于磨损均衡、垃圾回收和坏块替换。这部分虽然不在用户可见分区里，但保证了 SSD 的寿命和性能。

所以一块标称 512GB 的固态硬盘，全新安装 Windows 后，在“此电脑”里看到的不只有进制换算后的 477GB，还要再扣除系统保留分区和文件系统开销，最终可用空间往往只有 460~470GB。这在买电脑时很常见，也是不少人觉得“缩水严重”的原因。

4.3 扩容盘识别与可移动存储的“虚标”风险

除了正常的进制差异，还有一种情况是真·虚标，那就是扩容盘。有些劣质 U 盘、SD 卡、移动硬盘，主控芯片被刷成了假容量。插上电脑时，系统读到 1TB、2TB，实际物理存储可能只有 8GB、16GB。你往里面写超过真实容量的数据时，要么写不进去，要么能写但读出来全是损坏文件。

识别扩容盘最有效的办法是用大文件做填充测试。往盘里写满接近标称容量的数据，比如标称 128GB 就写 110GB 左右，然后再读回来校验。很多免费工具能自动完成写入和校验，比如 Windows 上常见的 H2testw，跑完一轮基本就能确认有没有虚标。我自己踩过坑，在路边摊买的所谓 128GB U 盘，实际只有 16GB，写文件超过 16GB 后，复制进去的视频一个都打不开。后来买存储设备我只认京东自营和品牌旗舰店，线下和无名小店的低价高容量盘基本都不碰。另外还要留个心眼：格式化显示的容量大不代表真实容量大，因为扩容盘可以伪造分区表和容量信息。

5. 把 TB 拉回日常生活：这些文件体积和存储容量能对应上吗

5.1 常见文件体积对照：文本、图片、音乐、视频

每次讲容量都绕不开一个问题：1TB 到底能装多少东西？这个问题没有一个标准答案，因为不同文件体积天差地别。我先给一组常见参考值：

• 普通 UTF-8 编码的中文文本，1 个汉字大约占 3 字节，1MB 大约能装 30~50 万汉字，一本书大概 50 万字，也就是 1~2MB。
• 手机随手拍的一张 JPEG 照片，1200 万像素大约 2~5MB；如果开 RAW 格式，一张能到 20~40MB。
• MP3 音乐按 320kbps 码率，1 分钟约 2.4MB，一首歌 4 分钟，大约 10MB；无损 FLAC 一首歌普遍 25~40MB。
• 1080p 电影按 H.264 编码、平均码率 8Mbps 估算，1 小时约 3.6GB；4K H.265 按 20Mbps 估算，1 小时约 9GB。这是比较粗略的区间，实际取决于画面复杂度。
• 一个 Docker 镜像或者游戏安装包，从几百 MB 到几十 GB 都有，所以别拿“一个文件”做统一预期。

这套对照能帮你快速判断：1TB 硬盘存照片，按一张 5MB 算，大约能存 20 万张；存无损音乐，按一首 30MB 算，大约 3 万多首；存 1080p 电影，按一部 10GB 算，大约 100 部。看起来很大，但如果你拍 4K 视频或者存蓝光原盘，容量消耗会快得多。

5.2 反向推算：按你的使用习惯反推容量需求

与其问“1TB 能存多少”，不如反过来问“我每天产生多少数据，要保留多久”。

假设你每天用手机拍 20 张照片，每张 4MB，再拍 3 段 1 分钟的 4K 视频，4K 视频码率按 50Mbps 算，一段 1 分钟大约 375MB，3 段就是 1.125GB。加上杂七杂八的截图和文档，一天产生大约 1.2GB。如果要保留一年不清理，那你就需要大约：

1.2GB × 365 = 438GB

考虑到移动硬盘或 NAS 通常预留 20% 以上剩余空间，选一个 1TB 的存储设备才比较稳妥。

再比如家里装监控，4 个 400 万像素摄像头，码率都设在 4Mbps，一天会产生大约 4 × 43.2GB = 172.8GB。想存 30 天回放，容量需求就是 5.2TB，一块 6TB 监控盘正好。如果你用的是 8Mbps 的高清模式，容量就得翻倍到 10TB 以上。

我这里反复用“码率”这个词，是因为视频对容量的消耗完全由码率决定。你只要记住：码率越高，画质越好，占的空间也越大。做存储规划时，先确定码率，再算清楚日增量，最后乘以保留天数，这个思路在任何场景都适用。

5.3 别忘了嵌入式世界：.bit 文件是“比特流”，不是 bit 单位

搜索“bit”相关的内容时，很多人其实不是在找存储单位，而是在找 FPGA 开发里的 .bit 文件。这两者碰巧用了同一个词，常让人误解。

FPGA 领域的 .bit 文件，是 Xilinx Vivado 或 ISE 工具链生成的比特流文件（bitstream）。它不是以 bit 为单位的“容量单位”，而是一段二进制配置数据，里面包含了 FPGA 内部查找表、触发器、布线资源、BRAM 初始化等所有配置信息。上电后，FPGA 从配置源读取这个比特流，加载到内部配置存储器，才能完成逻辑功能的“定型”。

开发中经常遇到一个操作：从 .bit 文件生成 .bin 文件。.bit 文件里除了原始配置数据，还包含了同步头、设备 ID、CRC 校验、附加的 MetaData 等结构信息。而 Flash 烧写时，很多方案只需要裸数据流，所以需要用工具把 .bit 转成 .bin。比如在 Vivado 的 Tcl 控制台里，可以用write_cfgmem命令生成适合 SPI Flash 的格式，配合 .mmi 文件把 MicroBlaze 的 ELF 软件执行程序合并进去，最终烧写到 Flash 里实现上电自启动。这个过程对很多刚接触 FPGA 的朋友来说是个大坑——.bit 文件能直接 JTAG 下载，让板子跑起来，但一断电就没了；要固化程序，就得生成 .bin 或 .hex 并烧进 Flash，这俩文件格式和用途完全不同。

顺带提一句，类似 K210 这类 RISC-V AI 开发板，比如 Sipeed Maix Bit，也存在“固件烧写”的需求。K210 的固件需要用特定工具写入 Flash，这种“下载固件”的行为同样会被人误叫成“下载 bit 文件”。因此当你搜索“bit”相关关键词时，先想清楚你找的是单位换算，还是开发板固件、FPGA 比特流、软件位数，方向完全不一样。

6. 留下几个趁手的换算技巧：命令行、脚本与自查清单

6.1 用 Python 或 Linux 命令代替在线转换器

很多人做单位换算会去搜索引擎找在线转换器，但容量换算的数据不涉及隐私，完全可以用本机命令更快解决。Linux 和 macOS 自带numfmt，能把字节数转成人类可读格式：

# 把字节数按十进制转成可读格式 echo 1000000000000 | numfmt --to=si # 输出：1.0T # 把字节数按二进制转成可读格式 echo 1000000000000 | numfmt --to=iec # 输出：932G

注意这里--to=si表示 1000 进制，--to=iec表示 1024 进制。两条命令结果不同，正好对应厂商和系统的两套口径。

如果你在写脚本或者做算题，直接用 Python 最省事：

size_bytes = 2_000_000_000_000 # 2TB 标称字节数 # 按 Windows 二进制口径显示 print(size_bytes / 1024**3, "GiB") # 输出：1862.64 GiB # 按厂商十进制口径显示 print(size_bytes / 1000**3, "GB") # 输出：2000.0 GB

这个脚本能直观看出两套系统的数值差异。我自己做容量统计时，凡是数据从数据库或日志里取出来，统一转成字节数再计算，最后要给人看时再格式化，这样最不容易出错。

6.2 日常自查清单和“最后一条经验律”

把本文知识点压缩成几张自查卡片，遇到问题时对号入座：

最后分享一条我摸索了很久才固化的经验律：日常生活看带宽用 b，看文件用 B；做容量规划先确定存储设备的进制口径，再做乘法；任何需要写代码处理的容量数据，中间过程一律用字节，展示层再做格式化。只要你把这三点变成习惯，绝大多数单位换算复杂场景都能一眼看穿。

我自己刚接触这些东西时，也被 1TB 硬盘“缩水”成 931GB 的事困惑了很久，甚至一度怀疑是商家坑人。后来搞清楚了十进制和二进制两套进位制，再回头看这些现象，一切都有了解释。希望这篇能把你的容量焦虑也一并治好了。