想象一个挺常见的场景。你在地铁站赶时间打开手机点了一杯咖啡。付款按钮按下去页面开始转圈。十几秒后App 提示“请求超时”。你正准备再付一次扣款短信来了。现在麻烦了订单到底成功没有退出页面会不会丢单再点一次会不会扣两笔这时手机并没有断网信号栏甚至可能是满的。网络只是处在一种“能连上但不太能用”的状态。相比直接断网这种半死不活的网络更难处理因为没人能马上说清楚刚才那次请求走到了哪一步。你盯着屏幕手指悬在“重试”按钮上方心里反复盘算如果刚才那笔钱真的扣了再点一次就是双倍损失可如果不点咖啡到底有没有下单成功你试着退出页面重新进入订单列表里空空如也既没有待支付订单也没有已支付记录。你甚至怀疑是不是自己记错了刚才到底有没有按下那个付款键。这种体验之所以让人抓狂是因为它把“不确定性”直接甩给了用户。断网时你至少知道该做什么——等网络恢复或者换个地方。可这种半死不活的状态下你连“问题出在哪”都说不清是手机的问题是地铁站信号的问题是咖啡店服务器的问题还是支付通道的问题每一个环节都有可能每一个环节你都无从验证。更麻烦的是这种状态往往不是一次性的。你在地铁上可能连续遇到好几次刚恢复一点又卡住再恢复一点又断一下。每一次“好像能用了”都给你一点希望紧接着又被打回原形。反复几次之后你不仅没买到咖啡还搭进去十几分钟心情也跟着烦躁起来。而这一切在开发者的视角里只是日志里几行“请求超时”和“连接重置”的记录。用户感受到的焦躁、犹豫和反复尝试很难被还原成一行清晰的错误码。这正是弱网问题最隐蔽的地方它不像崩溃那样有明确的堆栈也不像断网那样有明确的边界它藏在每一次“再等等看”的犹豫里。你在地铁站赶时间打开手机点了一杯咖啡。付款按钮按下去页面开始转圈。十几秒后App 提示“请求超时”。你正准备再付一次扣款短信来了。现在麻烦了订单到底成功没有退出页面会不会丢单再点一次会不会扣两笔这时手机并没有断网信号栏甚至可能是满的。网络只是处在一种“能连上但不太能用”的状态。相比直接断网这种半死不活的网络更难处理因为没人能马上说清楚刚才那次请求走到了哪一步。断网其实很干脆飞行模式一开结果通常很明确连接建不起来请求发不出去。App 可以提示网络不可用也可以把任务暂存起来等恢复后再继续。弱网就没这么痛快了。请求可能已经到达服务器只是响应堵在路上也可能丢了几个数据包TCP 等协议还在默默重传。只要连接没有彻底失败系统就会继续等。用户看到的是一个不知道还要转多久的加载动画。App 此时卡在一个尴尬的中间状态也许再等两秒就成功也许永远等不到也许服务器什么都没做也许业务已经处理完了。支付只是最明显的例子。发消息、传文件、提交订单都会碰到同样的问题。“有网”和“网络可用”是两回事我们平时会下意识地看手机右上角Wi-Fi 连着5G 信号也有网络应该没问题。可那个图标主要说明手机和 Wi-Fi 热点或移动基站之间还能联系。一个请求真正到达服务器还要经过域名解析、运营商链路、网络路由以及服务端入口。中间任何一段堵住都可能出现“看起来有网App 就是打不开”。公共 Wi-Fi 很容易制造这种错觉。手机已经连上热点所以图标正常显示但热点可能在等网页认证也可能接入的人太多外网几乎走不动。移动网络也一样。信号强只能说明手机和基站之间的无线连接还不错不能说明基站忙不忙更不能保证目标服务器一定能访问。所以App 发现“系统有网络”最多只能把它当成一个参考不能直接等同于业务可用。弱网并不只是网速慢日常交流里我们经常把弱网说成“网慢”。实际情况要乱得多。网络情况可以怎么理解常见表现带宽受限水管变细单位时间通过的数据更少图片加载慢、视频降画质、文件上传很久高延迟数据能到但每次往返都要等点击后迟迟没反应、聊天消息延后抖动延迟一会儿高、一会儿低语音断续、直播忽快忽慢随机丢包偶尔有数据丢失需要重传页面偶发失败、连接反复重建连续丢包一小段时间内大量数据过不去视频突然卡死、上传中断、长连接掉线网络切换Wi-Fi、移动网络或基站发生变化旧连接失效正在进行的请求停住部分可用只有一部分地址或服务能访问网页能开App 不能用能收消息发不出去而且这些情况经常一起出现。地铁进隧道时网络可能先变慢接着连续丢包短暂失联后又切到另一个基站。恢复的头几秒也未必稳定。用户只觉得“刚才卡了一下”App 实际经历了好几次网络变化。这也是固定设置一个“30% 丢包”无法代表所有真实弱网的原因。真实网络不是静止的参数它会在一次业务操作中不断变化。网络一差App 的老毛病就冒出来了弱网通常不会凭空创造问题。它更像一次压力测试把平时藏得很好的漏洞翻出来。登录页面就是一个例子。请求迟迟不返回时是继续等还是提示失败超时设得太短原本能成功的登录被提前放弃设得太长用户只能盯着转圈。要是 App 一着急又连续重试情况还可能更糟。支付和下单更棘手。一次超时不能证明业务失败因为服务器可能已经处理成功。App 如果直接让用户再试一次就可能造成重复下单或重复付款。多等一会儿解决不了这个问题。App 要把“失败”和“结果暂时未知”分开随后查询订单的最终状态。上传也有自己的坑。进度条走到 100%可能只表示数据已经从手机发出不代表服务器确认保存完成。如果最后一步断了能不能接着传重新进入页面后任务还在不在重试会不会生成两份文件网络好的时候这些边角很难撞上。聊天、评论、点赞看起来轻一些但用户同样在意“到底发出去没有”。没有发送状态用户会反复点击每次点击都当成新请求就会出现重复消息。反过来App 提前显示成功服务端却根本没收到也一样麻烦。视频通话、直播和 AI 流式回答又是另一类问题。它们不一定报错体验却已经不可用了。声音开始断续画面冻住回答写到一半停在那里。连接还活着用户却不知道该继续等还是重来。多重试几次行不行遇到弱网最容易想到两件事把超时时间拉长再加几次自动重试。有些查询请求确实可以这么处理但不能一股脑地套在所有业务上。等待时间太长用户会以为 App 卡死重试太频繁会继续挤占本来就不宽裕的网络。等网络恢复后大量设备一起重试还可能给服务端补上一波压力。更麻烦的是写操作不能随便重来。查询一篇文章失败了多查一次通常没事付款、下单、发评论重复执行后果完全不同。实际处理时要看业务本身普通查询可以安全重试支付超时后应该查订单状态大文件上传最好保留进度实时音视频可以主动降低码率。网络恢复后积压任务也该逐步恢复别在同一秒全部发出去。页面上的反馈同样重要。比起让加载动画一直转“网络较慢正在重试”“付款结果确认中”“进度已保存恢复网络后继续”更能让人安心。用户未必要求每次操作都秒回但他需要知道 App 没有失控。弱网测试到底在测什么办公室的网络往往太好了。很多问题只在地铁、电梯、地下车库或者拥挤的商场出现。等用户反馈回来开发坐在工位上点十遍都正常最后只留下一句熟悉的话无法复现。总不能每修一次问题就全组人去地库走一圈。弱网测试要做的是在可控环境里重复这些网络变化然后观察业务怎么反应。检查页面有没有弹出“网络错误”只算第一步更值得看的还有这些请求变慢时用户能不能看到当前状态短暂断开后上传或播放能不能接着进行自动重试有没有制造重复订单和重复消息网络切换后旧连接能不能正确恢复同样的网络过程再跑一遍修复结果是否还成立。只开关一次飞行模式覆盖不了这些情况。真实用户遇到的通常是一段过程先卡顿接着丢包中间可能断几秒然后慢慢恢复。测试如果能把这段过程稳定地重现开发和测试才有机会讨论同一个问题。写在最后弱网最折磨人的地方是不确定慢只是一部分。请求发出去了吗服务器处理了吗要不要重试用户现在看到的状态可信吗这些问题在网络正常时几乎没有存在感一旦网络开始半死不活就会挨个冒出来。我更愿意把好的弱网体验理解成一件很朴素的事失败时别把状态搞乱恢复后还能接着做实在处理不了就把话说明白。至于“任何网络下都能秒开”那不现实。下一篇聊聊另一个问题不跑去地铁和地下车库我们怎么在手机上制造延迟、丢包和限速