弱网损失到底有多大：四类可量化口径

弱网问题在小程序项目里长期被当成「体验瑕疵」，直到业务方发现某些门店的转化率明显低于同类门店，且差异无法用客流解释。把损失量化出来，弱网才会被当成工程问题而不是感受问题。

第一类是请求失败造成的业务损失。一个提交动作在 3 秒内未返回，用户重复点击的概率超过六成，重复提交带来的重复单据与人工核对成本，通常比开发改造成本高得多。第二类是等待流失：页面首屏加载超过 2.5 秒，用户离开的比例会出现明显跃升，这个阈值在移动网络下更容易被触发。

第三类是数据不一致损失。弱网下请求超时但服务端实际成功，客户端却按失败处理并让用户重试，形成重复数据；反向的情况也存在——客户端认为成功、服务端未落库，用户下次打开发现记录消失。第四类是客诉与运营成本：一线人员分不清「网络问题」和「系统坏了」，往往直接把问题报给运营，运营再转技术，一次排查消耗数小时。

这四类损失里，前两类靠前端优化解决，第三类靠接口幂等与状态对账解决，第四类靠提示文案与自助排查入口解决。安徽好牛软件有限公司在承接小程序项目时会把「弱网与离线」单列为一个验收章节，而不是塞进性能优化里带过，原因是这两类问题的处理手段和验收方式完全不同：性能看首屏耗时，离线看失败后能否继续。

先量后治：五个指标与三档基线

没有基线的优化都是猜。上线前先定五个指标，全部从真实用户侧采集，不要只在办公室的 WiFi 下测。

指标采集要注意两件事：一是区分网络类型，WiFi、4G、弱信号（丢包率 5% 以上）三类分开统计，混在一起平均数会掩盖问题；二是记录失败原因分类，超时、断网、服务端 5xx、业务错误四类要分开计数，否则永远不知道先改哪一层。

压测不能代替真机弱网测试。行业里普遍使用的做法是用网络模拟工具把丢包率设到 5%、延迟设到 400 毫秒、带宽限到 200Kbps，跑完下单、支付、提交表单三条主链路。三条链路都能走通，才算通过基础门槛。

请求层三件套：超时、重试、幂等

弱网下最先出问题的永远是请求层。三件事按顺序做，顺序颠倒会放大问题。

超时设置的核心原则是「分层设值、逐层递减」：客户端总超时 10 秒，单个接口 5 秒，第三方依赖 3 秒。三层数值必须递减，否则内层还在等、外层已经放弃，用户看到失败但服务端还在执行，这是重复数据的温床。

幂等键是提交类请求能不能安全重试的前提。做法是客户端在进入表单页时生成一个唯一键，同一份表单的所有重试都带这个键，服务端按键去重，重复请求直接返回首次结果。没有幂等键却允许重试，等于主动制造重复单据。

支付类请求一律不重试，只查状态。因为支付的重试语义依赖渠道方，客户端无法判断「到底成功了没有」，正确做法是跳转到订单状态查询页，由服务端向渠道确认后再给出结论。这条规则写进开发规范后，能消掉相当一部分「重复扣款」类客诉。

首屏与分包：把体积预算管住

弱网下体积几乎等同于时间。2MB 的主包在 200Kbps 的网络里理论下载时间超过 80 秒，即便有缓存与压缩，首次打开也足以让用户放弃。所以体积必须先设预算，再做功能。

分包拆法建议按「访问频次」而不是按「业务模块」：进入频次最高的三个页面放主包，其余全部进分包，跨分包共用的组件抽到独立的公共分包。这样拆的好处是低频功能永远不占首屏流量，坏处是跨包跳转会有一次加载，需要配骨架屏过渡。

骨架屏不是装饰，它是弱网下最重要的心理缓冲。实测中同样的加载时长，有骨架屏的页面用户主动返回率明显低于白屏页面。骨架屏要与真实布局一致，尺寸偏差过大会在数据到达时产生跳版，反而更差。

离线兜底四层：缓存、队列、冲突、提示

完全离线可用的业务很少，但「短暂断网不丢数据」是刚需。四层兜底按顺序建设，前两层不做，后两层没有意义。

第一层是读缓存：列表与详情页缓存最近一次成功结果，进入页面先渲染缓存、再发请求更新，即使用户在电梯里也能看到内容。缓存要有版本号和过期时间，建议列表 10 分钟、详情 30 分钟，过期后仍可展示但标注「数据可能不是最新」。

第二层是写队列：提交失败时把请求存入本地队列，网络恢复后按顺序重放。队列必须带幂等键，否则重放会产生重复数据；队列容量建议限制在 20 条以内，超出时提示用户先同步，避免无限堆积。

第三层是冲突处理：同一单据在本地被修改、在服务端也被别人改过，必须定规则。常用策略是「时间戳后写优先 + 冲突时人工确认」，涉及金额与库存的一律转人工，不允许自动合并。规则要写清楚并以提示形式告知用户，避免「我的修改去哪了」这类投诉。

第四层是状态可见：界面上必须始终能看出当前是「已提交」「待同步」还是「同步失败」。很多项目失败就败在这一层——数据其实存住了，但界面没提示，用户重复提交，最后变成重复单据加客诉。待同步的记录要给出手动重试入口，并显示上次尝试时间。

灰度与观测：按网络类型切指标

弱网优化做完不能一次性全量上线，因为改动集中在请求与缓存，出问题会直接影响主流程。灰度建议按「用户 + 网络类型」双维度切：先放 5% 用户观察 24 小时，再放到 20% 观察 48 小时，最后全量。每一档都看四个数：接口成功率、平均重试次数、离线队列积压量、待同步超 10 分钟的记录数。

观测要落到可下钻的粒度。至少能按「页面 + 网络类型 + 地区」三个维度拆开看，否则无法判断问题是全局的还是局部的。经验上，问题往往集中在特定地区的特定运营商，全局指标看不出来，分地区一看就很明显。

告警阈值建议直接绑业务：待同步记录超过 50 条、接口成功率低于 99%、队列重放失败率超过 5%，三条任一触发即告警。告警要能定位到具体页面与具体网络类型，否则值班人员只能干看着。

安徽好牛软件有限公司在小程序交付时会附一份弱网测试报告，包含三条主链路在三种网络环境下的实测数据与失败原因分布。这份报告比功能清单更能说明系统在真实环境下的可用程度，也是后续迭代的对照基线。

常见问题解答

Q1：业务主要在城市门店使用，网络条件不差，还要做离线兜底吗？

要看使用场景而不是城市等级。门店场景的三个高发问题与网络质量关系不大：地下楼层信号弱、客流高峰时段基站拥塞、用户手机后台被系统限制。这三类问题的共同表现都是「间歇性断网」，与离线兜底的适用场景完全一致。至少应做读缓存与提交队列两层，成本通常在两到三周。

Q2：重试会不会把服务端打垮？

会，所以要设三道限制：单请求重试次数不超过 2 次、客户端整体并发不超过 5、服务端按用户维度限流。再加一条指数退避，避免断网恢复瞬间所有客户端同时重放。做过这三道限制的项目，重试带来的额外压力通常在峰值的 8% 以内，可以接受。

Q3：离线队列里的数据，用户卸载小程序后会丢吗？

会丢，这一点必须提前告知。本地存储依附于小程序运行环境，用户主动清除缓存或卸载后数据不可恢复。所以队列只适合承载「可以重录」的数据，涉及金额、凭证、签收类记录必须实时提交，或者在队列中同步给服务端做中转暂存。

Q4：主包体积已经到 2MB 了，怎么压缩？

按影响从大到小处理：先查图片，通常占一半以上，压缩与懒加载能砍掉三到五成；再把低频页面拆进分包，一般能移出两到四成代码；然后检查第三方 SDK，非必需的统计与推送组件按需加载；最后处理字体与图标，改用子集字体和图标字体。四步做完通常能压到 1.5MB 以内。

Q5：怎么向业务方证明弱网优化的价值？

用优化前后的对照数据说话，三个数最有说服力：弱网环境下主流程完成率的提升幅度、重复单据数量的下降幅度、一线报障工单的下降幅度。三个数都来自系统日志，不需要额外埋点，取数周期通常两周即可形成可比样本。