面板导览

WebDebugX 不会重新实现 DevTools。它内置官方原版前端，并将其指向运行在其他设备上的页面：

目标	检查器
iOS / iPadOS 页面	WebKit 网页检查器 —— 与 Safari 使用的是同一套
Android 与 Chromium 页面	Chrome DevTools

两者的布局和面板名称存在差异，因为它们来自不同的上游项目。下列能力两侧均具备，仅名称可能不同。

元素 Elements

页面在设备上的实时 DOM，包含计算样式与盒模型。修改会立即作用于正在运行的页面 —— 调整一条规则，设备上的页面随即重绘。

适用于排查：仅在特定视口下失效的布局、被覆盖的样式，以及实际位置与预期不符的元素。

页面自身的日志输出、警告与报错，并可在页面的真实上下文中求值。

适用于排查：功能异常背后真正的错误信息；以及直接查看运行时的真实状态 —— location.href、某个全局变量，或代码预期取到的值。

页面实际加载的脚本 —— 即经过打包与 CDN 分发之后的版本 —— 支持断点、单步执行、调用栈与作用域查看。只要设备能够获取 source map，其解析方式与本地调试一致。

适用于排查：在真正出现问题的那台设备上逐步执行逻辑，而非依据日志推测。

页面发出的每一个请求，包含请求头、载荷、状态与耗时。

这些数据来自页面内部，由此带来两个需要明确的结论：

无需证书，也无需代理。 HTTPS 内容之所以可读，是因为呈现的是页面自身视角下的请求，而非被拦截的网络流量。
这是页面的流量，不是设备的流量。 应用中 web view 之外的原生代码所发出的请求不会出现在这里 —— 那属于抓包工具的范畴，而非 DevTools。

设备上实际存在的 Cookie、localStorage 与 sessionStorage。

适用于排查：已过期的 token、上一版本残留的开关，以及仅存在于测试设备而本机没有的数据。这类内容在抓包中完全不可见，而问题的答案往往就在其中。

在实际出现卡顿的硬件上进行性能分析。中端机型与开发机的性能特征并不一致，仅依据开发机进行优化，优化对象是错误的。

WebDebugX 检查的是网页。它不提供设备级抓包，不解密页面之外的流量，也不检查原生（非 Web）界面。如果需要观察的内容并不经过 web view，则应选用其他工具。