移动端网页调试怎么这么难？WebDebugX 等5种工具实测体验
最近在给一个 Hybrid App 项目做移动端适配，遇到个老大难问题：WebView 页面在 iOS 上表现一切正常，Android 上却死活点不动某个按钮。最离谱的是，这个 bug 还不一定复现，每次重启又好了。
我一开始以为是 CSS 或 JS 写得有问题，但用 console.log 打了半天也没看出什么。于是开始研究各种调试工具，趁这次机会总结一下这几种工具的体验，也算是给有类似需求的开发者一点参考。
Chrome DevTools + 模拟器
最基础的办法，调试 Android WebView，理论上 Android 系统自带的浏览器或 WebView 是支持远程调试的。在 Chrome 浏览器里 chrome://inspect/#devices 可以连上模拟器或真机。
优点：
- 上手简单
- 接近熟悉的 DevTools 界面
缺点：
- 只能调试 Android，iOS 完全不行
- 有时连接不上，设备识别有延迟
- WebView 要打开调试开关才能看到内容
结论：入门可用，但局限性大。
Safari 开发者工具
用 Mac 开发的同学可能都用过 Safari 的调试工具，可以连接 iOS 真机上的 Safari 页面。
优点：
- 调试原生 Safari 页面还不错
- 连线比较稳定
缺点：
- WebView 页面看不到（unless 你控制了 app 的调试配置）
- 功能不如 Chrome DevTools 丰富
结论：仅限 iOS + Safari 场景，WebView 基本无用。
Charles / Proxyman / Fiddler
这些抓包工具倒是挺稳的，网络层能看到很多东西。比如：
- 查看请求 headers、body、响应内容
- 重放请求、模拟失败
- 观察加载时间
缺点显而易见：
- 看不到 DOM / JS / 样式
- 只是网络层，页面逻辑一头雾水
结论：搭配使用不错，但调试网页不够全面。
WebDebugX
这是我在逛 GitHub 的时候看到有人推荐的工具，本来没抱太大希望，结果真香。
WebDebugX 支持跨平台运行，我用的是 Linux 版，几乎 plug and play。连接 Android 或 iOS 设备后，可以实时调试 Web 页面或 WebView。
（图片来源网络，侵删）实际用例：我调试一个页面支付流程时，发现某些状态参数丢失。用 WebDebugX 的控制台 + 网络面板查了下，原来是 session 跨域 cookie 没同步成功，前端也没有 fallback 逻辑。
功能亮点：
（图片来源网络，侵删）- 类似 Chrome DevTools 的调试体验（元素、控制台、源码、网络、性能）
- 真机页面实时同步改动
- 网络请求可以断点、拦截、修改
- 性能面板能查内存和 CPU 使用
结论：目前我主力使用的调试工具，特别适合 WebView 开发。
RemoteDebug + ADB 端口转发
这个方式比较折腾。你得在 JS 中手动插入 remote debug client，再通过 ADB 把端口转发到本地。理论上能实现调试，但流程比较原始。
（图片来源网络，侵删）适合哪些人？框架开发者、高级调试场景、或是爱折腾的人。
我试过一次，花了两个小时配置环境，最后还是放弃了。
总结
调试移动端网页确实不容易，不同工具有各自擅长的领域：
- 快速看请求：用 Charles
- Android WebView：Chrome DevTools
- iOS 原生浏览器：Safari 开发者工具
- 高效调试 WebView：我推荐 WebDebugX
欢迎大家留言说说你们还用过什么调试工具，有哪些奇技淫巧，一起提升调试效率！
