必须在刷新前启用节流并禁用缓存，才能使断点真实捕获弱网请求；节流仅对HTTP/HTTPS有效，file://协议下失效，且需配合自定义参数（如Latency 1800ms、Download 40KB/s）精准复现场景。
网络面板本身不提供断点功能，但它是弱网调试的关键配合环节——断点用于暂停执行、观察状态，而网络节流决定请求如何“变慢”。要让断点调试真正反映弱网下的行为，必须先在网络面板中正确启用节流，并确保它真实作用于你正在调试的请求。
一、必须在刷新前开启节流，否则断点抓不到慢请求
断点（比如XHR断点或DOM断点）只对实际发出的网络请求生效。如果先刷新页面、再打开Network面板并选择Slow 3G，那么已发出的请求早已走完高速通道，断点停住时看到的是毫秒级响应，完全失真。
- 正确顺序：打开DevTools → 切到Network标签页 → 确保左上角录制按钮是红色（●）→ 从节流下拉菜单选Slow 3G或自定义档位 → 再按 Ctrl+R / Cmd+R 强制刷新
- 验证是否生效：看Waterfall里每个请求的“Stalled”和“Waiting (TTFB)”时间是否明显拉长（如TTFB从10ms变成400ms以上）
- 若用XHR断点，此时触发断点的请求才真正携带弱网延迟，你能准确观察超时逻辑、重试机制或loading状态变化
二、禁用缓存是弱网断点有效的前提
浏览器缓存会跳过网络层，直接返回资源。即使你设了Slow 3G，JS/CSS/图片仍可能“秒出”，断点停住时发现加载飞快，误判逻辑没问题，其实只是缓存掩盖了问题。
- 在Network面板顶部工具栏勾选 Disable cache（必须在刷新前勾选）
- 特别注意：该选项只对当前标签页生效，关闭再打开需重新勾选
- 禁用后，所有资源强制走网络，断点捕获的才是真实弱网下的请求生命周期
三、配合自定义节流参数，精准复现现场问题
预设的Slow 3G（约400ms延迟 + 50KB/s下载）适合通用验证，但某些卡顿场景需要更精确建模，比如用户反馈“信号满格但提交总超时”，可能对应高延迟低丢包。
立即学习“Java免费学习笔记（深入）”；
- 点击Network右上角 ⋮ → Throttling → Add custom profile
- 填入合理值：Latency设为1000–2000（单位ms），Download设为30–150（单位KB/s），Upload不低于10（否则POST卡在Sending）
- 举例：模拟电梯间场景可设 Latency: 1800, Download: 40, Upload: 12；保存后从下拉菜单直接切换，刷新，再用XHR断点观察接口超时是否触发重试
四、注意协议限制：file:// 页面无法启用节流
本地双击HTML文件打开时使用file://协议，DevTools的网络节流功能被浏览器安全策略完全禁用——节流菜单存在但置灰，无论你怎么设置都无效。
- 必须通过HTTP服务访问：终端运行
python3 -m http.server 8000，然后访问http://localhost:8000/index.html - VS Code用户推荐安装Live Server插件，右键HTML文件选择“Open with Live Server”
- 只有HTTP/HTTPS协议下，Network节流 + 断点调试才能协同工作
