根据实收字节与耗时计算下载速度：预算助手的测量模块实践

用两个原始量还原一次下载

排查下载速度时，先保留实际收到的字节数 B，以及本次请求实际消耗的秒数 t。套餐带宽用于对照，文件总大小用于估算剩余工作量。把这几项分开记录，能避免把峰值带宽直接当成实际传输结果。

本文使用固定算例演示计算，不关联任何账号、IP 或具体服务商，也不声称进行了一次新的网络实验。

1. 从字节每秒换算到 Mbps

采用十进制单位时，计算关系为：

bytes/s = B / t
MB/s    = B / t / 1,000,000
Mbps    = B × 8 / t / 1,000,000

固定输入为 1,216,192 字节与 40 秒，结果是 30,404.8 bytes/s、0.0304048 MB/s、0.2432384 Mbps。若界面显示 KiB/s，需除以 1024，得到约 29.69 KiB/s；与十进制的 kB/s 区分后，再比较两个工具的读数。

计时应使用请求实际返回的耗时。设置了 40 秒时间上限时，记录值仍可能是 40.011094 秒。用于演示的整数 40 与实际记录的浮点值应分别标明，复算时保留原始精度。

2. 计算与标称带宽的比例

假设标称带宽为 30 Mbps，本算例占比为：

0.2432384 / 30 × 100% = 0.81079467%

这个比例帮助发现实际路径与套餐指标之间的差距。排查原因时，还需要记录客户端位置、传输方向、目标地址、连接数、协议和测量时段。多条链路使用相同条件后，结果才便于比较。一个短样本可以定位当前体验，长期可用性则需要更多时段的记录。

3. 根据样本估算下载窗口

若后续一直维持同一平均速度，6 GB 按十进制计算为 6,000,000,000 字节，估算关系为：

预计秒数 = 目标字节数 / 样本 bytes/s
6,000,000,000 / 30,404.8 ≈ 197,337.26 秒
                       ≈ 54.82 小时

同一个 30 Mbps 标称值，理论换算为 3.75 MB/s。用理论值估算任务窗口时，可以得到较短的理想耗时；用实际样本估算时，则能看见当前路径带来的时间成本。工具应把两组结果同时保留，并标明各自的输入依据。

4. 超时样本与错误页分别处理

限时下载中，即使只收到文件的一部分，也能根据收到的字节与完整耗时计算平均速度。记录中同时保存 HTTP 状态、内容类型以及是否完整传输。例如返回了视频片段，可以保留本次部分传输的吞吐；若返回登录页或错误页，应按对应响应分类，避免把它作为目标文件下载成功。

若记录了首字节时间，还可以单独观察等待响应与后续传输两个阶段。把首字节等待时间从分母中扣除，会改变统计口径；报告中应写清是否包含这一阶段，避免两组平均值混用。

5. 让计算工具正确处理边界

在预算助手中新增这块功能时，我将字节数限制为非负安全整数，将耗时和标称带宽限制为有限正数，目标 GB 接受有限非负数。输入缺失或超出计算范围时，界面直接指出字段问题。

零字节输入显示零速度，并提示无法据此估算下载耗时。目标大小为零且样本有有效吞吐时，估算耗时为零。对无限值、非法小数和溢出量级分别检查，可以避免出现 Infinity、NaN 或误导性的时长。

本次改动已核对固定算例、零字节、零目标、13 组非法或极端输入，并在浏览器检查示例、错误提示与原有三个计算模块。查看 JSON 时同时保留输入与计算状态，方便他人复算。

项目地址：cloud-budget-helper。工具为纯前端计算页面，不主动发起测速，也不上传输入数据。撰写方式：AI 辅助整理；数值为明确标注的计算示例。