mac局域网传输断崖式下跌主因是链路持续丢包引发tcp重传与窗口收缩，需先ping网关确认丢包率≥3%或mdev＞30ms，再依wi-fi或有线分别检测信号强度、协商速率及物理状态，最后用tcpdump捕获并统计重传次数＞15次/分钟即可锁定链路层丢包。
Mac局域网传输速度突然断崖式下跌，八成不是带宽不够，而是链路在持续丢包→触发TCP重传→窗口收缩→吞吐量腰斩。这种问题ping单次看不出，必须抓重传行为和底层物理协商状态。
第一步：确认丢包是否真实存在于局域网内
打开终端，执行：ping -c 30 192.168.1.1（把192.168.1.1替换成你路由器的实际网关地址）。
重点看两行输出：packet loss是否大于0%，以及mdev是否超过25ms。如果丢包率≥3%或mdev > 30ms，说明本地链路已不稳定——此时外网测试毫无意义，必须停在这里排查。
这一步不能跳过，也不能用8.8.8.8代替。因为网关是第一跳，若它都不可靠，后续所有重传都源于此。
第二步：查重传根源——是Wi-Fi信号衰减还是以太网协商失败
方法一：Wi-Fi用户请运行以下命令，一次性提取三项关键指标：
/System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport -I | grep -E "(agrCtlRSSI|lastTxRate|obssPktCnt)"
对照判断：
• agrCtlRSSI → 信号弱，穿墙或距离过远；
• lastTxRate ≤ 24 Mbps → 协商降速，大概率受微波炉、蓝牙设备或邻居2.4GHz信道强干扰；
• obssPktCnt > 80 → 邻频严重冲突，需手动切到1、6、11信道（仅2.4GHz）或36+/149+（5GHz）。
方法二：有线用户执行：ifconfig en0 | grep -E "(status|media|active)"。
必须同时满足三项才表示物理链路真正就绪：
• status: active
• media 包含 1000baseT 或 100baseTX（而非仅 autoselect）
• active: active
若只显示 autoselect，说明网卡未成功协商速率，可能是网线虚接、扩展坞供电不足或交换机端口故障。
第三步：捕获真实重传行为，绕过TCP慢启动干扰
第一步：用networkQuality -v跑一次基准测试，观察Retransmission count值。
第二步：立即开启另一终端窗口，执行：sudo tcpdump -i en0 -w /tmp/lan-retrans.pcap 'tcp[tcpflags] & (tcp-rst|tcp-syn|tcp-fin) == 0 and ip[2:2] & 0x1fff != 0'（Wi-Fi用户将en0改为en1）。
第三步：在另一窗口发起局域网大文件传输（如从Time Machine备份盘拷贝1GB文件），持续60秒后按Ctrl+C停止抓包。
第四步：分析抓包结果：tcpdump -r /tmp/lan-retrans.pcap | grep "retransmit" | wc -l。
若重传次数＞15次/分钟，且与networkQuality中Retransmission count趋势一致，即可锁定为链路层丢包引发的TCP性能坍塌——此时优化DNS或换浏览器毫无作用。
