Chrome DevTools 怎么模拟慢网和离线：Network 节流、Disable cache 与结果核对

页面在办公室Wi-Fi下加载很快，切到手机热点却先空白几秒，或者断网后仍显示旧页面，这类问题不能只靠“感觉慢不慢”判断。Chrome DevTools的Network面板可以把当前页面切到Fast 3G、Slow 3G或Offline状态，再用请求列表和页面提示核对实际表现。

先在Network面板选一个网络条件，再刷新页面观察请求时间、失败状态和页面兜底；测试结束后把Throttling恢复为No throttling，并关闭Disable cache的临时开关。

先把测试目标分成慢网、离线和绕过缓存

三种开关解决的不是同一个问题。Fast 3G、Slow 3G属于网络节流，用来观察资源加载顺序和等待时间；Offline用来验证无网络时的失败分支；Disable cache则让刷新时更接近没有浏览器缓存的首次访问。它们可以组合使用，但每次只改一个变量更容易判断结果。

从Network面板打开节流设置

在Chrome中打开目标页面，按 Command+Option+I（Windows/Linux 使用 Control+Shift+I）启动DevTools，再切到 Network。如果请求表格没有出现，先刷新一次页面，让HTML、脚本和图片请求进入列表。

在Network工具栏找到 Throttling 下拉框。选择 Fast 3G 或 Slow 3G 后刷新页面，新的请求会按所选条件加载；不要只盯着页面总耗时，点开具体请求还能看到更长的等待区间。

测试完成后重新打开同一个下拉框，选择 No throttling。这一步很容易漏掉：节流是DevTools会话级设置，忘记恢复会让后续调试和本地验收都变慢。

用Offline验证断网时的页面行为

在Network工具栏的节流菜单中选择 Offline，然后重新加载页面。Network面板会显示离线提示图标，新的文档、脚本或接口请求通常会失败。页面如果有Service Worker或本地缓存，可能仍能显示部分内容，所以要同时看请求状态和页面上的离线提示，不能只凭“页面还在”判断离线逻辑通过。

需要恢复时，把菜单改回 No throttling，再次刷新并确认新请求返回正常状态。若页面依赖登录态或接口token，离线测试失败只能说明网络请求被切断，不能据此判断鉴权代码有问题。

Disable cache什么时候应该一起打开

Network面板工具栏还有 Disable cache 复选框。勾选后，只要DevTools保持打开，刷新页面时就会绕过浏览器缓存，更适合检查入口HTML、版本号、缓存头和资源更新是否真的生效。它不会替你清空服务器CDN，也不会改变真实用户浏览器已经保存的其他数据。

建议先关闭Disable cache做一次正常基线，再打开它重复刷新。若只有第二次刷新才出现新脚本，优先比较请求的响应头、文件名和缓存命中情况，不要直接把问题归因于网络速度。

Request conditions适合单独放慢一个资源

如果整页降速会干扰判断，可以在Network请求列表中右键某个资源，选择 Throttle request，让Request conditions抽屉只对匹配的URL应用节流。这个方式适合模拟某个第三方脚本、图片或接口变慢，而不影响页面其他请求。

Request conditions中的规则按顺序匹配，多个规则重叠时要检查排列顺序。关闭DevTools会停用阻断和节流，但已保存的规则仍可能留在抽屉里；下一次调试前先确认 Enable blocking and throttling 的状态。

常见问题

为什么选了Offline，页面还显示旧内容？

页面可能来自Service Worker或浏览器缓存。查看Network请求是否失败，再用Disable cache做对照；不要只看页面是否仍有文字。

为什么刷新后节流好像没有生效？

确认改动发生在Network面板的Throttling菜单，而不是Performance面板的录制设置，并观察Network标签旁是否出现节流提示图标。

测试结束一定要关闭Disable cache吗？

建议关闭或至少在记录结果时注明它仍处于开启状态。该选项在DevTools打开期间持续影响刷新，容易让后续测试误以为缓存失效。

什么时候应该用Request conditions？

只想让一个API、脚本或图片变慢时使用它；要模拟整台设备的网络条件，则直接用Network面板的全局Throttling更清楚。

最后用一次正常网络刷新收尾

完成测试后按顺序检查：Throttling已回到No throttling，Offline不再选中，Disable cache是否恢复原状态，Request conditions是否关闭启用开关。最后正常刷新一次，确认Network请求重新出现、页面状态和接口响应回到基线，再保存测试记录。