Safari页面刷新后的请求抓包与缓存分析实战

做前端和客户端联调的时候，最怕听到一句话就是“我这边刷新一下就正常了”。刷新这个动作看似简单，背后却牵着一堆网络请求、缓存策略和状态逻辑，尤其是跑在苹果 Safari 里的页面，表现跟 Chrome 经常不一样。想把这层窗户纸捅破，最直接的办法就是抓包看请求。这篇文章从 Safari 抓包的实际场景出发，重点讲页面刷新后的请求该怎么抓、怎么分析，覆盖工具选型、证书配置、请求参数解读和常见异常定位，适合前端开发、APP 端联调、测试排查和爬虫分析的同学拿去做参考。

1. 页面刷新后的请求分析，到底在分析什么

1.1 刷新动作产生的完整请求链路

很多人以为刷新页面就是重新发一次请求，其实一个完整的刷新动作在浏览器里会被拆成好几层。拿最常见的软刷新（比如点击刷新按钮或者按 F5）来说，浏览器会先重新请求 HTML 文档，然后解析 HTML 过程中再去拉 JavaScript、CSS、图片和字体这些静态资源，最后脚本执行又触发接口请求。这三层请求的层级和顺序是完全不一样的，抓包时要在“文档请求 + 资源请求 + XHR/Fetch 请求”三个维度上分别看。

Safari 和 Chrome 还有一个明显差异：Safari 对缓存的处理更加激进。它在强缓存有效期内可能根本不会发请求，直接从磁盘或内存缓存里读取；而到了协商缓存阶段，它会发一个带 If-Modified-Since 或 If-None-Match 的请求，由服务器返回 304 来确认资源没有变化。所以刷新后的请求清单到底是什么样，完全取决于缓存策略。如果你光看“请求数变少了”就判定有问题，很容易被 Safari 的缓存行为误导。

另外刷新分为软刷新、地址栏回车刷新、强刷新（Command+Shift+R）三种，请求行为也不一样。软刷新会尽量复用缓存，强刷新则会强制走协商缓存，个别资源甚至会直接绕过缓存重新拉取。抓包分析的第一步就要先明确：你按的是哪种刷新，目标场景是哪种刷新，这样才能判断结果是正确行为还是异常行为。

1.2 抓包能看到的几类关键信息

抓包工具看起来满屏都是请求列表，其实核心信息就几类。第一类是请求基本行，包括 URL、Method、状态码和协议版本。状态码是判断异常最直观的入口，200 代表正常返回，304 代表资源未修改，301/302 代表重定向，403/404 是权限和路径问题，500 则说明服务端挂了。第二类是请求头和响应头，这里藏着 Content-Type、Cache-Control、ETag、Set-Cookie、CORS 头、Referer、Origin 等关键字段。第三类是请求体和响应体，接口问题基本靠它们确认。第四类是时间线，也就是浏览器从发起请求到拿到响应所经历的 DNS、连接、TLS、等待和下载时间，这部分对于性能分析极其重要。

很多人抓包只盯着 Status 和 Response Body，忽略了请求头尤其是缓存头和 Origin 头。实际上刷新场景下大量诡异问题都出在这些“看不见的字段”上。比如页面刷新后接口返回的还是旧数据，很可能不是后端没更新，而是缓存头没设置正确；又比如刷新后跨域请求失败，往往是因为 Origin 头在刷新前后发生了变化，服务端校验逻辑被触发了。

1.3 谁会用到这个场景

页面刷新后的请求分析不是一个单点技术，上下游都会用到。前端开发排查“为什么刷新后页面还是旧的”“为什么重复提交了订单”“为什么某个接口偶尔慢”，需要抓包看请求细节。客户端开发在调试 WKWebView 内嵌页面时，需要确认 H5 与原生之间的 Cookie 和请求头是否一致。测试人员做 CDN 验证和弱网验证，需要对比刷新后的资源加载情况。爬虫开发则需要通过刷新动作确认站点哪些请求是页面渲染必须的，哪些是埋点上报，然后精准构造请求头。

可以说抓包是所有 Web 技术栈的“公共语言”，而 Safari 在这套公共语言里又有自己的方言。不理解这套方言，很多问题在 Chrome 里怎么也复现不了，一换到 Safari 就冒出来。

2. Safari 抓包的方案选型与前置准备

2.1 内置方案：Safari Web Inspector 的 Network 面板

如果只是简单看一下页面请求，macOS 上 Safari 自带的 Web Inspector 就够用。需要先在 Safari 设置的高级选项卡里勾选“显示功能菜单”，然后在顶部菜单栏打开“开发”菜单，点击“显示 Web 检查器”。切到 Network 面板后，就能看到当前页面的所有网络请求。这个面板支持按资源类型过滤、查看请求/响应头、预览 JSON、查看时间线，基本功能是齐全的。

对于 iOS Safari 真机，也可以用数据线把 iPhone 连接到 Mac，在 Safari 的“开发”菜单里选择设备名和页面，就能远程调出同样的 Web Inspector。这套方案的优点是零配置、不需要装证书、不会干扰系统代理，而且能看到模拟器和真机的真实请求。缺点是只能调试由这台机器发起的 Safari 页面请求，看不到其他 App 的请求，也不支持重放、修改请求、设置断点等更高级的操作，更拿不到手机全局网络流量。所以它更适合“快速看一下”，不适合“深度分析和改造请求”。

2.2 代理抓包工具对比

要做页面刷新后的完整请求分析，尤其是想看 HTTPS 明文内容、拦截和重放请求，就需要上代理类抓包工具。这类工具的思路是把自己伪装成系统 HTTPS 代理，然后在中间解密和转发流量。市面上常见的选择有 Charles、Fiddler、Burp Suite、Reqable 和 Wireshark，但它们的侧重点完全不同。

选型逻辑很简单：想快速定位前端和接口问题，Charles 或 Reqable 最顺手；做安全测试和请求篡改，Burp Suite 是标配；只想看某个端口发出去的原始 TCP 包和 TLS 握手细节，Wireshark 才是正确工具。Fiddler 在 Windows 生态很强，如果你主力开发机是 macOS，新版 Fiddler 也可以试，但体验上不如 Charles 和 Reqable 顺滑。

2.3 方案选型建议

我的习惯是日常排查询题优先 Charles，因为它对 Safari 和 iOS 的适配最成熟，证书安装和信任流程踩坑最少。Charles 的瀑布图、断点、Map Local、Repeat 功能足够覆盖 90% 的刷新请求分析场景。如果是纯 API 调试，不涉及页面渲染和缓存，可以用 Reqable 快速看一眼。如果遇到比较诡异的网络请求，比如页面刷新后某些资源根本没发出来、连接被复用、TLS 指纹异常，这时候再打开 Wireshark 从网卡层面确认。

要特别强调一个理解问题：代理抓包工具截获的是“通过代理端口转发的流量”，如果目标 App 或浏览器没有走系统代理，或者走了代理但没信任根证书，工具就看不到内容。这也是很多新手抓包失败的根本原因。所以方案选完只是开始，把代理配置正确、把证书安装到位才是真正的工作量。

3. 实战：Charles 抓取 Safari 刷新请求全流程

3.1 配置代理并让 Safari 走代理

我这套流程以 Charles 为例，因为它在 macOS 和 iOS 上是兼容性最好的抓包方案，而且界面直观。先把 Charles 启动，在 Proxy 菜单里的 Proxy Settings 确认 HTTP Proxy 端口，默认是 8888。想让 Safari 走代理，最简单的方式是打开 Charles 的 Proxy 菜单，勾选 macOS Proxy，这样系统代理会被自动设置，Safari 作为系统自带浏览器会默认读取系统代理设置。

如果你用的是 iOS 真机，步骤会多一点。打开设置 -> 无线局域网 -> 找到当前连接 Wi-Fi 后面的图标 -> 配置代理 -> 选择手动，然后把服务器地址填成 Mac 的局域网 IP，端口填 8888。Mac 的 IP 可以在 Charles 顶部最右侧的 Help -> Local IP Address 里看到，通常是 192.168.x.x 或 10.x.x.x 这种内网地址。需要注意 iOS 14.5 之后，App 首次连接本地网络会弹权限确认框，如果不允许，代理抓包就会失败，需要在设置 -> 隐私 -> 本地网络中允许对应 App。

3.2 HTTPS 证书安装与完全信任

走代理只是第一步，如果目标页面是 HTTPS，还需要让 Charles 能解密。Charles 的做法是生成一个根证书，客户端信任这个根证书后，Charles 才能作为中间人解密 TLS。macOS 上操作路径是 Help -> SSL Proxying -> Install Charles Root Certificate，安装完成后在“钥匙串访问”里找到 Charles Proxy CA 证书，把“信任”改为“始终信任”，这一步一定不能漏，否则 Safari 会提示证书不受信。

iOS 真机需要访问 chls.pro/ssl 下载证书，安装描述文件后还要去设置 -> 通用 -> 关于本机 -> 证书信任设置里把 Charles 证书的完全信任开关打开。很多人卡在“证书安装了还是抓不到 HTTPS”，核心就是缺少这最后一步“完全信任”。安装完证书不要急着高兴，先在 Safari 里随便打开一个 HTTPS 网站，如果地址栏没有报错，说明证书生效了，然后再回到 Charles 里确认 SSL Proxying 的配置。注意 Charles 默认只开启部分域名解密，建议在 Proxy -> SSL Proxying Settings 里加 *:443 通配符，否则很多域名不在解密范围内。

提示：每次重装 Charles 或清理了系统证书，都要重新走一遍“安装证书 -> 设置信任 -> 重启 Charles”的流程。这个问题在我实际使用中出现频率极高。

3.3 刷新页面并精准定位关键请求

配置好之后，开始正式抓取。第一步是清空 Charles 左下角 Session 列表，让抓包环境干净；第二步在浏览器里打开目标页面，地址栏回车进入页面；第三步点击刷新按钮或按 Command+R，让页面重新触发整套请求链路；第四步立刻回到 Charles，在搜索框里输入业务关键词或者域名，过滤出目标资源。

这里有一个非常实用的技巧：如果你的页面涉及多个接口，不要盲目在列表里翻，先开启 Charles 的 Focus 功能。在请求上右键选择 Focus，被标记的请求会排到列表最前面；或者直接在 Filter 输入框里填接口路径片段，快速锁定关键请求。刷新后请求会按时间顺序出现，关注“第一个 Document 请求”和它派生的子资源顺序，基本能还原页面渲染链路。

还有一个建议是打开 Charles 的 Structure 视图。默认是 Sequence 视图，按时间顺序平铺；Structure 视图会按域名和路径层级把请求归类，刷新前后资源加载范围一目了然。如果你想对比“刷新前”和“刷新后”的请求差异，可以在刷新前记录一份请求列表，刷新后再看新增和缺失的项，这个操作比单纯看瀑布图更有说服力。

3.4 核心参数怎么读：状态、时间与缓存头

拿到请求列表后，怎么判断一个请求是否正常？我的习惯是看四样东西：状态码、时间线、请求头、响应头。

状态码决定请求成功与否，但不代表数据一定正确。200 和 304 在刷新场景下都是正常状态，但含义完全不同，304 表示资源未修改，直接用了本地缓存，有时候你会发现某个接口也返回 304，这就要小心了，接口走缓存通常不是期望行为。

时间线在 Charles 的 Timing 选项卡里能看到，它把耗时拆成了网络耗时和服务端耗时。网络耗时包括 DNS、连接建立、TLS 握手、发送请求、等待响应和下载内容；服务端耗时就是 TTFB 时间。如果页面刷新后某个接口几乎瞬间完成，Time 显示几毫秒，那大概率是缓存命中，不是服务端快。

缓存头是刷新请求分析的重头戏。请求头里看 If-None-Match 和 If-Modified-Since，响应头里看 ETag、Last-Modified、Cache-Control、Expires。它们之间是配对出现的：有 ETag 才会发 If-None-Match，有 Last-Modified 才会发 If-Modified-Since。服务端收到条件请求后，如果资源没变就会返回 304。下面这个表可以帮你快速判断缓存状态：

判断逻辑就是：如果响应头里带 Cache-Control: max-age=3600，那么在 3600 秒内刷新页面，浏览器根本不会向服务器发请求，直接从缓存读取；如果你在抓包里发现刷新后很多静态资源压根没有请求记录，这不是异常，是强缓存生效了。

4. 刷新场景下最常见的请求异常与定位思路

4.1 资源明明更新了，刷新后还是旧内容

这是刷新请求分析里被问到最多的问题。前端改了 CSS 或 JS，后端也发布了，但用户在 Safari 打开页面还是旧版本，抓包一看，很多资源连请求都没发。这种情况基本可以锁定为强缓存太久。比如某个 CDN 资源设置了 Cache-Control: max-age=86400，意味着 24 小时内这个 URL 的请求根本不会到达服务器，你刷新十次也是本地缓存。

判断方法很简单：刷新页面后，Charles 里看不到某个资源的请求记录，或者状态码直接显示 200（from cache），就说明它走了强缓存。解法有两种。第一种是给资源 URL 加版本参数，比如把 app.js?v=20231101 改成 app.js?v=20231102，URL 变了缓存键自然失效；第二种是让服务端修改 CDN 的 Cache-Control，把 max-age 调小，或者对 HTML 文件设置 no-cache，确保刷新时 HTML 本身一定会回源校验，再由它引用新版本资源。

另外还要注意 Safari 的启发式缓存。即使没有显式的缓存头，浏览器也可能根据 Last-Modified 做启发式缓存，默认缓存时间可能是差异值的 10%。这是很隐蔽的坑，抓包时如果不看响应头，根本意识不到是缓存策略在作怪。

4.2 接口请求重复发送或缺失

页面刷新后，接口请求可能出现两种情况：重复发送了不该发送的请求，或者该发的请求根本没发出来。重复请求往往是因为页面在刷新过程中经历了多次生命周期，比如前端框架在初始化时订阅了事件，刷新时旧页面销毁和新页面初始化之间有重叠，导致同一个接口被调用两次。还有一种是 HTML 里写了多个重复的脚本加载脚本，每个脚本执行都触发一次请求。

缺失请求则常见于依赖 onload 或 DOMContentLoaded 事件的逻辑。如果页面刷新过快，某些脚本还没来得及注册监听，刷新后的首次加载就可能漏掉请求。这时候抓包的价值在于确认“是否真的发了请求”。如果 Charles 里完全没有这个请求的记录，那问题一定在前端逻辑；如果有请求记录但服务端没响应，那就是后端问题；如果请求发了但被 304 挡回来，那要检查缓存头是否配置合理。

4.3 请求被 CORS 或 Origin 策略拦截

刷新场景下 CORS 问题也很典型。有些页面是嵌在 iframe 里的，刷新 iframe 时父页面不刷新，这时 iframe 里的跨域请求可能会因为 Origin 头变化而失败。还有一种情况是页面首次加载时 Origin 为空，刷新后 Origin 变成了具体域名，服务端如果只在白名单里匹配了固定 Origin，就可能放行第一次请求、拦截刷新后的请求。

从抓包里看，这类问题会在控制台报 CORS error，网络请求显示为红色（failed），响应头里缺少 Access-Control-Allow-Origin。需要同时看请求头的 Origin 和响应头的 CORS 字段。如果是刷新后首次出现，重点检查服务端对预检请求（OPTIONS）的处理，以及是否对动态 Origin 做了宽容配置。

4.4 时序太慢，到底慢在哪一段

页面刷新后用户感觉变慢了，多数时候不是真的整站慢，而是某个关键资源阻塞了渲染。抓包工具里的时间线都会把请求拆分到阶段：Queueing（排队）、Stalled（阻塞）、DNS Lookup（域名解析）、Initial Connection（TCP 连接）、SSL（TLS 握手）、TTFB（等待响应）、Content Download（内容下载）。

如果大量请求的 TTFB 都很长，问题基本出在服务端处理能力或数据库查询上；如果只有个别请求的 TTFB 长，要看这个接口是不是在刷新后触发了慢 SQL 或外部依赖调用。如果阻塞和排队时间特别长，说明浏览器对同一域名并发连接数有限制，或者有更大体积的资源占用了连接。这种情况在 Safari 上尤其明显，它跟 Chrome 的并发策略不完全一样，排查时要结合抓包时间线逐一确认。

5. 常见问题与排查技巧实录

5.1 开启抓包后 Safari 提示“连接不是专用连接”

这个问题十有八九是证书信任没设好。先检查钥匙串里的 Charles CA 证书是否设置为“始终信任”，再看 iOS 真机上的证书描述文件是否装好、完全信任开关是否打开。如果都正常，重启一下 Charles 和 Safari，并把 SSL Proxying 设置里的域名通配符确认好。我自己遇到过一次是因为系统里有多个 Charles 证书，旧证书失效后 Safari 优先匹配了旧证书，把旧证书删掉就好了。

5.2 只抓到部分请求，静态资源看不到

如果接口能看到但图片、JS、CSS 看不到，很可能是因为 Charles 默认的解密范围只覆盖了部分域名。在 SSL Proxying Settings 里添加 *:443，让所有 HTTPS 请求都走解密。另外检查 Charles 的 Access Control Settings，如果限制了允许访问的 IP 段，本机流量也可能无法正常显示。还有一个小概率问题是某个资源走了 HTTP/3，而 Charles 默认不支持解密 HTTP/3 流量，可以把浏览器的 HTTP/3 禁掉再做对比。

5.3 iOS 真机抓包经常断流

真机断流有几种原因：一是 Wi-Fi 弱网导致代理握手超时，可以关掉蜂窝网络、只用稳定 Wi-Fi；二是 iOS 的“低数据模式”会干扰代理；三是两分钟后代理连接被系统回收，常见于 App 长时间无网络请求后再次发起请求的场景。解决方式是在 Charles 里把代理超时时间调大，同时保持 Mac 和手机在同一网络且网络稳定。

5.4 刷新后抓不到期望的请求

明明接口在页面里触发了，Charles 里却没有记录。先排除过滤条件是否收窄了域名，再确认是否被浏览器的缓存策略命中。还有一个容易被忽略的点是 BFCache（Back/Forward Cache）。Safari 对前进后退页面有非常激进的缓存策略，从 BFCache 恢复的页面可能完全不会发网络请求，看起来就像页面“秒开”。这种情况在普通刷新场景里不会出现，但你如果是从其他页面跳转返回触发的“刷新”，就要考虑 BFCache 因素。

最后分享一个我自己常用的方法：抓 Safari 刷新请求时，不要只抓一次，先清空 Session，然后连续做三次操作。第一次查看原始加载，第二次软刷新，第三次强刷新。三次的请求列表放在一起对比，缓存策略、重复请求、缺失请求、时序差异都会变得非常明显。这套对比法帮我在实际项目里定位过不少看起来“偶发”的接口问题，比对着单一请求列表猜来猜去高效得多。