手机网页出问题时，最常见的错误报告只有六个字：“打不开，没反应。”
对使用者来说这已经很准确；对修网站的人来说，它可能代表 JavaScript 报错、接口超时、按钮被遮住、缓存没更新、登录状态丢失，甚至只是页面滚到了一个奇怪的位置。
真正有效的下一步，是把“感觉坏了”变成一条能复现的证据。
先记录现场，别急着连续刷新
记下页面完整地址、手机型号、系统版本、浏览器名称和版本，以及从哪一步开始异常。如果问题只在微信内置浏览器、PWA 或无痕模式出现，这个差异非常重要。
能录屏就从进入页面前开始录，尤其要保留地址栏和点击顺序。不要为了截图好看裁掉错误提示；那行字通常比“就是不行”值钱得多。
Android + Chrome：用电脑远程检查
- 在手机开发者选项中打开 USB 调试。
- 用支持数据传输的线连接电脑，在手机上确认这台电脑的调试授权。
- 手机 Chrome 打开出问题的页面，并保持标签页在前台。
- 电脑 Chrome 打开
chrome://inspect/#devices。 - 找到对应设备和标签页，点击 Inspect。
如果设备完全不出现，先查数据线、USB 模式、驱动和手机上的授权弹窗。能充电的线不一定能传数据，这个坑朴素得不像技术问题，却非常高频。
打开 DevTools 后先看哪里
Console：找第一条错误
页面白屏或按钮没反应时，先找最早出现的红色错误。后面几十条可能只是第一处失败引发的连锁反应。记录错误文字、文件名和行号，不要只截一个红叉图标。
Network：请求到底发生了什么
勾选 Preserve log 后重现问题，观察失败请求的状态：
404：路径或资源不存在。401/403：登录、权限或安全策略问题。429：请求过多或服务限流。5xx：服务器端异常。(blocked)、CORS、CSP：浏览器策略或扩展拦截。- 一直 Pending：网络、长连接或服务器没有及时结束响应。
“接口失败”和“页面按钮坏了”看起来可能一样，Network 能把它们分开。
Elements：是不是被遮住了
按钮看得见却点不到，常见原因是透明遮罩、错误的 z-index、弹窗背景没有收起，或元素实际跑出视口。Elements 可以检查点击位置上到底是哪一层。
Application：缓存、PWA 和登录状态
新代码已经部署，手机却还显示旧界面，重点看 Service Worker、Cache Storage、Local Storage 和 Cookie。先确认缓存来源，再清理对应站点数据；不要一出问题就把整个浏览器所有登录状态全清掉。
没有电脑时还能做什么
可以先用浏览器自身能看到的信息缩小范围：
- 同一地址分别在普通标签、无痕模式和另一个浏览器打开。
- 切换 Wi-Fi 与移动网络，判断是否与网络有关。
- 关闭内容拦截或脚本扩展后复测。
- 把 PWA 与普通浏览器标签页做对照。
- 记录准确时间，方便服务器日志对应请求。
开发阶段也可以在测试版本临时加入页面内错误面板，监听 window.onerror 和未处理 Promise。但不要在正式站长期显示完整日志，更不能把令牌、Cookie、用户输入和接口响应原样摆在页面上。
微信内置浏览器为什么格外难查
内置浏览器可能使用不同内核版本、缓存策略、登录环境和网络限制。微信里失败、系统 Chrome 正常，说明范围已经缩小，但不等于一句“微信屏蔽了”就结案。
先比较 User-Agent、失败请求、是否允许下载或文件选择，以及页面是否被微信的导航栏改变可用高度。涉及 WebSocket、WebRTC 或跨域请求时，更要看真实错误而不是猜地区封锁。
最容易浪费时间的排查方式
- 一次修改五个地方，然后不知道哪一项有效。
- 只发一张白屏截图，没有地址、时间和操作步骤。
- 忽略 Console 第一条错误，追着后面的连锁报错跑。
- 把所有失败都归因于缓存，然后反复全站清缓存。
- 为了调试把密钥、完整 Cookie 或用户隐私复制进公开群聊。
一份真正有用的错误记录
至少包含：页面 URL、发生时间、设备与浏览器版本、网络环境、复现步骤、预期结果、实际结果、Console 第一条错误和失败的 Network 请求。
如果涉及部署，还要记下对应提交或版本号。结合Cloudflare Pages 发布流程，可以判断问题出在代码、构建、缓存还是正式域名。
排错的目标不是“打开了开发者工具”
DevTools 本身不会修网页。它的价值是把模糊现象变成可以验证的假设：请求 403、脚本语法错、按钮被遮罩、Service Worker 还在用旧缓存。
找到第一条真正的证据，往往比盲改十次有效。毕竟网页不会因为你刷新得很有气势就主动交代问题。
官方入口：Chrome 远程调试文档