关键在于用curl -w拆解DNS、TCP、TLS、TTFB等阶段耗时，配合nslookup和networkQuality交叉验证，并通过多次采样观察各阶段波动分布。
要清楚看到 macOS 中网络请求各阶段耗时的分布情况，关键不是只看总时间，而是把一次 HTTP 请求拆解成 DNS 解析、TCP 连接、TLS 握手、首字节响应等环节，再逐项测量并汇总统计。系统自带工具就能完成，不需要装第三方软件。
用 curl -w 精确拆解每个阶段耗时
curl 的 -w 参数能输出完整请求生命周期中多个时间节点，适合单次请求的细粒度分析。
- 先创建一个格式文件：
curl-format.txt，内容为：
- 执行命令：
curl -w "@curl-format.txt" -o /dev/null -sL https://example.com - 输出结果中每个字段单位是秒（小数），例如
time_namelookup: 0.023456表示 DNS 查询用了约 23ms - 重复执行多次（比如 10 次），手动记录或用脚本收集数据，就能看出 DNS 是否波动大、TLS 握手是否不稳定等分布特征
批量采集并观察耗时波动
单次结果容易受缓存、瞬时干扰影响，真正判断“分布”得看一组数据的离散程度。
- 用 shell 循环快速采集 10 次：
for i in {1..10}; do curl -w "@curl-format.txt" -o /dev/null -sL https://example.com; echo "---"; done - 重点关注
time_namelookup和time_appconnect：如果前者标准差 >10ms，说明本地 DNS 或上游解析不稳定；后者波动大（如从 80ms 跳到 300ms），可能是证书验证慢或服务器 TLS 配置问题 - 若
time_starttransfer明显大于time_pretransfer，说明服务端处理慢，而非网络问题
结合 nslookup 和 networkQuality 定位瓶颈类型
curl 给的是端到端耗时，但无法区分是 DNS、链路还是服务端的问题。需要交叉验证。
- 测 DNS 延迟分布：
time nslookup example.com 8.8.8.8执行 5 次，看real时间是否稳定；再换1.1.1.1对比，判断是否本地 DNS 拖累 - 测底层带宽与延迟：
networkQuality -v查看 RTT 样本和重传率——如果平均 RTT 低但 curl 的time_connect高，大概率是本机 TCP 栈或防火墙策略导致连接建立慢 - 对比不同目标：
curl -w ... https://142.250.191.46（Google IP）绕过 DNS，可确认是否域名解析拖慢整体请求
用 Charles 抓包看真实请求序列与并发行为
curl 只测单个请求，实际网页加载是多个请求并发、有依赖关系的。Charles 能展示完整瀑布图，直观反映时长分布逻辑。
- 开启 Charles 后访问网页，左侧列表显示所有请求，右键某请求 → “Response Times” 可查看 DNS/TLS/Connect/Response 各阶段时间条形图
- 顶部时间轴显示各请求起止位置，一眼看出哪些请求阻塞了后续资源（如某个 JS 加载慢导致后面 CSS 延后发起）
- 勾选 “Throttle” 模拟弱网后重测，观察哪些阶段耗时增幅最大——常是 TLS 握手或首字节响应对带宽最敏感
