Charles Throttle 弱网模拟实战：把 WiFi 变成"地铁信号"
你的 App 在办公室千兆网下丝般顺滑，可用户在地铁、电梯、地下车库里却频繁转圈、超时、白屏。要在开发阶段就把这些问题揪出来，就得主动制造"烂网络"。Charles 的 Throttle（限速）功能，能把你的良好网络降级成 2G、3G 甚至高丢包环境，让弱网问题在上线前暴露。
一、为什么必须做弱网测试
弱网不是"慢一点"这么简单，它会放大一切隐藏问题：请求超时后有没有重试？重试会不会导致重复下单？loading 会不会一直转？图片加载失败有没有占位？接口顺序依赖会不会因为某个慢请求整页卡住？这些在好网络下永远测不出来，只有在弱网下才会集中爆发。
二、开启 Throttle 的两种方式
1. 快速开关：点击工具栏的小乌龟图标，或菜单 Proxy > Start Throttling，即按当前预设开始限速。
2. 详细配置：Proxy > Throttle Settings，勾选 Enable Throttling，从 Throttle preset 下拉选一个预设（如 3G），或自定义各项参数。
三、Throttle 参数逐个讲清
| 参数 | 含义 | 调大后的效果 |
|---|---|---|
| Bandwidth（上/下行） | 带宽，单位 kbps | 值越小，传输越慢，大图/视频最明显 |
| Utilisation | 可用带宽利用率百分比 | 模拟带宽被其他程序占用 |
| Round-trip Latency | 往返延迟（ms） | 每个请求都先"卡"这么久，最影响接口密集的页面 |
| MTU | 最大传输单元（字节） | 调小会增加分包，放大延迟影响 |
| Reliability | 可靠性（%） | 值越低丢包越多，触发重传 |
| Stability | 稳定性（%） | 模拟信号忽好忽坏的抖动 |
最容易被忽视但影响最大的是 Round-trip Latency（延迟）。一个首页如果串行发了 10 个接口，每个多 300ms 延迟，光排队就多等 3 秒。这类问题只有加延迟才暴露得出来，也是优化接口并行/合并的重要依据。
四、常见网络档位参考值
Charles 内置了多档预设，以下是常用档位的大致参考（实际数值以你的版本预设为准，可据此微调）：
| 档位 | 下行带宽 | 往返延迟 | 典型场景 |
|---|---|---|---|
| GPRS / 2G | 约 20–50 kbps | 约 500 ms | 偏远地区、极端弱网 |
| EDGE | 约 200 kbps | 约 400 ms | 老旧网络 |
| 3G | 约 750 kbps–1 Mbps | 约 100–200 ms | 地铁、人多的地方 |
| 4G / LTE | 约 4–10 Mbps | 约 50–100 ms | 日常移动网络 |
| 高丢包 | 不限带宽，Reliability 调到 70–85% | — | 电梯、隧道、信号抖动 |
测试"断网/恢复"时，可以在弱网基础上把 Reliability 拉到很低甚至临时停掉 Throttling 来回切换，观察 App 断网重连、离线缓存、失败重试是否正常。
五、只对指定接口限速
整机限速会让调试工具本身也变慢，影响体验。更聪明的做法是只限速你关心的接口：
1. 在 Throttle Settings 里勾选 Only for selected hosts；
2. 在下方 Add 添加要限速的 Host（如 api.example.com），其余流量保持全速。
这样你可以单独观察某个慢接口对页面的影响，而不被无关请求干扰。你也可以在会话列表右键某个 Host 直接 Enable Throttling。
六、弱网下重点验证的 5 件事
- 超时与重试：请求超时后是否有合理的超时时间与重试策略？重试会不会造成重复提交（尤其支付、下单）？
- Loading 与骨架屏：慢请求期间是否有 loading/骨架屏？会不会一直转圈没有兜底？
- 失败降级：图片/接口加载失败是否有占位图、缓存兜底或友好提示？
- 并发与串行：首屏接口是并行还是串行？串行链路在高延迟下是否慢到无法接受？
- 断网恢复：切到弱网/断网再恢复，App 能否自动重连并刷新数据，而不是停留在错误页。
把这套流程纳入发版前的例行检查，能拦下大量"只在用户手机上出现"的疑难问题。Charles Throttle 的价值，正是把这些不可控的真实网络，变成你桌上可复现、可调节的一个开关。