网页能打开，为什么 App 还是提示“网络异常”？

连着商场的 Wi-Fi，浏览器能打开网页，聊天消息也收得到。你切到一个购物 App，商品图片出来了，登录却一直转圈，最后只给一句“网络异常”。

再试一次，还是这样。

用户很容易觉得这句提示在推卸责任：我明明有网，怎么到你这里就异常了？开发收到反馈，也可能先让用户换个网络试试。换成移动数据之后真的好了，但刚才为什么不行，依然没人说清楚。

这类问题需要先放下一个直觉：网络并不是整部手机共用的一个“通或不通”的开关。某个网页能打开，只能证明那一次访问成功了。

你看到一个页面，手机可能访问了好几个服务

假设一个购物首页需要先获取商品列表，再加载图片，点击购买后还要确认登录状态。这些工作未必由同一台服务器完成，也未必使用同一个域名。

图片可能来自内容分发网络，登录由账号服务负责，商品价格和库存又由业务接口提供。页面看起来是一体的，背后的访问路径却分成了几支。

用户看到的现象	可以优先调查的方向
文字正常，图片一直空白	图片请求、资源地址与分发链路
商品能浏览，登录无法完成	账号服务、认证流程及相关依赖
首页正常，提交订单失败	下单接口和服务端处理结果
已打开的内容正常，新页面打不开	缓存、域名解析与新连接建立

这些只是调查方向，不能凭现象直接定案。例如图片加载不出来，也可能是地址失效或格式处理出错，并不一定是网络。

但它提醒我们，没必要因为登录失败，就把整个首页都判成不可用。图片、列表和登录的失败范围可以分别处理。

请求也许还没找到服务器

App 通常使用域名访问服务。建立连接前，系统或应用需要取得对应的网络地址，这个过程涉及 DNS。

可以把域名当成通讯录里的姓名，地址则像联系号码。知道姓名，还得查到一个当前可用的号码，才能继续联系。

如果解析迟迟没有结果，请求可能根本没到业务服务器。服务端日志里找不到它，并不奇怪。团队如果只查接口有没有报错，就会得到“服务器一切正常”的结论。

缓存会让情况更绕一点。浏览器可能已经保存了某个域名的地址，App 第一次访问另一个域名却需要重新解析。于是同一时刻，浏览器看着正常，App 仍然失败。

有时浏览器展示的页面本身就是缓存，甚至没有进行完整的新访问。因此“我刚打开了一个网页”是有用线索，但不是全网连通性的证明。

排查解析问题时，也别直接把域名替换成 IP 当作万能办法。HTTPS 的证书校验和站点选择可能依赖域名，这样测试可能引入另一个错误，让结论更难判断。

连上公共 Wi-Fi，还没走完整个流程

公共网络可能要求先登录、接受使用条款或完成认证。在此之前，设备能够连接热点，却只能访问受限的地址。

这种网络被称为带认证门户的网络。相关架构明确区分了设备接入、访问限制与用户完成门户交互等环节，连上无线网络并不意味着已经获得正常的外网访问能力。RFC 8952：认证门户架构

浏览器适合完成网页认证，普通 App 却不一定能把同样的流程呈现出来。某些请求能通过，另一些被限制，用户看到的就可能是局部可用。

即使认证已经完成，目标服务仍可能因为路由、服务端故障或其他链路问题不可达。系统显示网络可用，通常只是依据它自己的检测结果，不能替所有业务地址做保证。

测试公共 Wi-Fi 问题时，应分别记录是否完成认证、目标请求是否真的发出，以及失败发生在哪一阶段。只记一个 Wi-Fi 名称，通常还不够。

“网络异常”可以简短，但不能什么都往里装

连接超时、证书校验失败、账号过期、服务器返回错误，如果最后都变成同一句提示，用户只能反复点重试，团队也失去了线索。

用户不需要看到 DNS 错误码或连接堆栈。他需要知道当前哪个动作没完成，以及下一步是否有用。

图片失败，可以在图片区域提供重试；账号服务暂时不可用，可以保留浏览能力，说明暂时无法登录。只有确认需要完成网络认证时，才提示去完成认证，不能见到超时就随意猜原因。

诊断记录则应该更具体：访问的是哪类服务、在哪个阶段失败、用了多久、是否拿到响应，以及能关联到服务端记录的请求标识。分享时再对敏感信息做脱敏。

这两套表达服务不同的人。用户看到一句能采取行动的话，开发拿到能继续调查的证据，两者不冲突。

局部失败时，页面能不能保住剩下的部分？

如果一个非必要的图片请求失败，整页就一直加载，用户会觉得整个 App 都坏了。其实商品文字可能早就拿到了。

页面可以先显示已经可用的内容，让失败区域单独结束等待。恢复网络后，再补齐缺失部分。

但保留内容不等于假装所有数据都有效。价格、库存或账号状态没有确认，就不能用一份旧结果继续完成交易。哪些区域可先展示，哪些操作必须等待确认，需要按业务来定。

一个实用的检查办法是问：这个依赖失败后，用户还能安全地做什么？能看详情就保留详情，不能下单就说明原因。比把全部页面替换成一个错误图标更容易理解。

怎样测试“只有一部分用不了”

测试不必一开始就复刻整个商场网络。可以从一个明确依赖开始：让图片服务暂时不可达，观察文字是否正常显示；再单独测试登录服务或业务接口。

每次先验证受影响的范围确实符合预期。多个域名可能共享一个 IP，一个域名也可能对应多个动态地址。按 IP 拦截不能天然保证只影响某个业务，更不等于能够精确屏蔽一条 HTTP 请求。

需要精确控制某个接口时，应使用受控测试服务或相应的应用层测试手段。测试 DNS 超时、连接失败和服务端明确返回错误，也属于不同条件，别把它们混成一个“断网用例”。

可以先保留四项验收：

• 可用区域是否仍能使用，页面能否结束无意义的等待；
• 失败区域是否给出准确反馈，重试是否只影响必要范围；
• 必须确认的数据缺失时，是否阻止了不安全的后续操作；
• 依赖恢复后，内容和操作能否恢复正常。

首次打开与重复打开最好各测一次。缓存可能帮用户渡过故障，也可能让测试根本没有访问到原本想拦截的服务。

从“有网吗”问到“哪次访问失败了”

浏览器正常、App 异常，并不矛盾。两者可能访问不同服务，走不同路径，也可能一个使用缓存，另一个需要建立新连接。

下次遇到这类反馈，先确认失败的是图片、登录还是某个业务动作，再看解析、连接和响应。范围缩小后，“换个网络试试”可以成为一项对照实验，而不必成为排查的最后一句话。