选 no throttling 以外的预设（如 slow 3g）才真正生效，但仅影响当前标签页后续请求；需刷新前启用、禁用缓存，并观察 waterfall 中 stalled 和 ttfb 是否延长。
Network 面板里“Throttling”下拉菜单选哪个才真有效
选 No throttling 以外的任意预设（比如 Slow 3G 或 Fast 3G）才会真正限制网络带宽和延迟，但注意：这仅作用于当前标签页的后续请求，已发出的请求不受影响。
常见错误是点了 Slow 3G 后刷新页面，发现资源加载速度没变——其实是缓存没清，浏览器直接从内存或 disk cache 返回了资源。要验证节流是否生效，得看 Network 面板里每个请求的 Waterfall 栏中 “Stalled” 和 “Waiting (TTFB)” 时间是否明显拉长，而不是只看总耗时。
- 必须在刷新前开启节流，刷新后才启用无效
- 禁用缓存（勾选
Disable cache）才能排除缓存干扰 -
Offline模式不等于弱网，它直接断网，连 DNS 查询都失败
自定义节流参数时 latency 和 download/upload 的关系
Chrome 的自定义节流（Add custom profile）里填的 Latency 是往返延迟（RTT），不是单向；Download 和 Upload 是吞吐量上限，单位是 KB/s，不是 Mbps —— 这点极易填错。
比如想模拟真实 Slow 3G（典型 RTT 200ms，下行 400Kbps ≈ 50KB/s），就得填 Latency: 200、Download: 50、Upload: 15。填成 400 就会比预期快 8 倍，根本测不出首屏卡顿。
- 1 Mbps = 125 KB/s，换算时别漏掉除以 8
- Upload 值太小会导致 POST 请求卡在 “Sending” 阶段，特别是表单提交或图片上传
- Latency 设为 0 时，即使带宽很低，TTFB 也可能极短，失真严重
为什么 JS/CSS 加载看起来没变慢，但页面还是白屏
Network 节流只影响网络传输层，不模拟解析、编译、渲染阻塞。如果 main.js 文件本身只有 50KB，即使在 Slow 3G 下也几秒内下完，但它的执行可能触发大量同步 DOM 操作或未优化的 layout，导致主线程卡住——这时 Waterfall 看起来“很快”，实际用户就是卡住不动。
- 配合 Performance 面板录一段操作，看主线程是否有长任务（>50ms）
- 检查是否有 render-blocking 资源：未加
async/defer的 script、未设尺寸的图片、未优化的字体加载 - 节流下 CSSOM 构建延迟会被放大，尤其含大量 @import 或跨域 CSS 时
移动端真机调试时 Network 节流不生效怎么办
Chrome DevTools 远程调试安卓设备时，节流设置默认只作用于 DevTools 所在电脑的网络，**不下发到手机**。也就是说，手机仍走原 Wi-Fi/4G，节流形同虚设。
真机弱网测试必须换方案：要么用 iOS 的「开发者 → 网络条件」开关（需 macOS + Safari 技术预览版），要么在安卓上用第三方工具如 clatd 或 NetLimiter（需 root），更稳妥的是在本地搭个中间代理（如 Charles 或 mitmproxy）并配置限速规则。
- Chrome for Android 自身不提供节流 UI，Remote Debugging 无法控制其网络栈
- 部分企业内网或代理环境会绕过节流，此时 Waterfall 中请求的 IP 显示为代理地址而非目标域名
- HTTPS 请求在代理限速时需额外安装根证书，否则会触发安全警告中断加载
