写代码的时候，接口调用突然变慢，请求经常超时，本地测试没问题，一上测试环境就卡顿。这种情况八成是网络延迟高或者有丢包。别急着改代码，先搞清楚是不是网络在拖后腿。
\n\n延迟高和丢包到底影响啥
\n延迟高就是数据发出去要等很久才收到回应。比如你调一个API，本该200毫秒返回，结果花了2秒，用户早就关页面了。而丢包更烦人，发了10个数据包，只有8个到，TCP会重传，但整体速度直接掉下来，WebSocket可能直接断连。
\n\n做前后端联调、微服务通信，或者对接第三方API时，这类问题特别常见。你以为是对方接口不稳定，其实是中间网络链路有问题。
\n\n用ping看清基础网络状况
\n最简单的办法还是ping。别小看这个命令，它能同时看出延迟和丢包情况。
\n\nping api.example.com看输出里的“time=”数值，如果长期超过300ms，那延迟就算高了。再看最后的统计，如果有“packet loss”，哪怕5%，也够呛。特别是做实时通信的应用，比如音视频、在线协作工具，这点丢包就能让用户崩溃。
\n\ntraceroute找出问题出在哪一跳
\nping只能告诉你结果，但不知道病根在哪。这时候得用traceroute（Windows下是tracert）。
\n\ntraceroute api.example.com它会列出从你电脑到目标服务器之间的每一跳。如果某几跳开始出现超时或延迟飙升，问题很可能出在那个节点之后的网络段。比如前5跳都正常，第6跳开始延迟从30ms飙到500ms，那大概率是对方机房接入线路或防火墙策略的问题。
\n\nmtr：ping + traceroute 的合体利器
\nmtr 是开发常用的组合工具，一边跟踪路径，一边持续测延迟和丢包率。
\n\nmtr --report api.example.com输出里能看到每一跳的丢包百分比和平均延迟。如果某一跳突然出现高丢包，基本可以锁定故障区域。比如公司用的是云服务，发现丢包出现在运营商骨干网那一跳，就得找云厂商提工单了。
\n\n开发环境中的实际应对
\n有些团队把接口超时时间设得太短，比如1秒。一旦网络抖动，服务就报错。其实可以根据mtr的结果，合理设置重试机制和超时阈值。
\n\n比如你在海外调用国内的API，mtr显示平均延迟400ms，那超时至少设成2秒，并配合指数退避重试。
\n\nfetch('/api/data', { timeout: 2000 })\n .then(...)\n .catch(err => {\n // 重试逻辑，第一次等500ms，第二次1s，第三次2s\n });别忘了本地代理和DNS
\n有时候延迟高不是公网问题，而是本地配置作怪。比如用了不稳定的代理工具，或者DNS解析慢。可以试试切换DNS到114.114.114.114或8.8.8.8，再跑一遍测试。
\n\n还有些开发工具自带网络监控，比如Chrome DevTools的Network面板，能看每个请求的真实耗时分解。如果TTFB（首字节时间）特别长，基本就是网络或服务端处理慢，而不是前端资源加载问题。
\n\n自动化检测脚本示例
\n如果你常驻某个项目，可以写个简单脚本定期检测关键接口的网络质量。
\n\n#!/bin/bash\nHOST=\"api.example.com\"\nCOUNT=10\n\nping -c $COUNT $HOST | grep \"packet loss\"\nping -c $COUNT $HOST | tail -1 | awk '{print $4}' | cut -d '/' -f 2\n把这个加到CI流程里，每次部署前跑一下，提前发现问题。
","seo_title":"网络延迟高、丢包怎么办？开发者实用排查工具指南","seo_description":"遇到网络延迟高、丢包问题别慌，用ping、traceroute、mtr等工具快速定位网络瓶颈，结合代码优化提升系统稳定性。","keywords":"网络延迟高,丢包,ping,traceroute,mtr,网络排查,开发工具"}