混合开发里，WebView 是个又爱又恨的东西：它让你能把一套 H5、一张 TradingView 图表、一段第三方页面塞进原生 App 里复用，但一旦它出问题，你想看看里面的 console、DOM、网络请求，麻烦就来了。
最近我在一个 React Native 股票项目里调 K 线详情页——这页用 react-native-webview 加载了一份本地打包的 TradingView Charting Library。我把 iPhone 真机连上 Mac，打开 Safari 的「开发」菜单，想连进 WebView 看图表里的报错，结果设备子菜单下空空如也，那个 WebView 死活不出现。
第一反应是「WebView 没加载成功吧？」——但页面上图表明明渲染出来了，onLoadEnd 也回调了。折腾一圈后发现，这根本不是加载问题，而是 iOS 16.4 起 WebKit 的一个默认行为变更叠加了 Debug / Release 构建的差异。这篇文章把整个排查链路和最终的「可复制检查清单」完整复盘，对任何在原生里嵌 WebView（TradingView、H5 活动页、内嵌文档、第三方 SDK 页面）的场景都通用。
在本篇文章中，我们将从浅入深，一起搞定以下内容：
- 为什么「WebView 加载成功」和「Safari 能看到它」是两回事
iOS 16.4的关键变更：WKWebView的isInspectable默认变成了falsereact-native-webview的webviewDebuggingEnabled到底做了什么__DEV__陷阱：为什么你的TestFlight / Release包永远连不上- 设备端那个置灰的「网页检查器」开关藏在哪
- 一张从头到尾的真机
WebView调试检查清单 Android端chrome://inspect对照玩法- 临时给
Release包开调试的正确姿势与安全红线 - 进阶：怎么调
file://本地加载的TradingView图表
# 一、先分清两个独立的事实
排查这类问题，最容易掉的坑是把两件不相干的事混在一起：
- WebView 有没有把内容加载出来——这是
App内部的事，看onLoadEnd/onError回调、看页面有没有渲染就知道。 - Safari 的网页检查器能不能连进这个 WebView——这是
WebKit「是否允许被远程检查」的开关，跟加载成不成功完全无关。
我一开始就栽在这：图表渲染出来了 → 我默认「加载成功 = 应该能被 Safari 看到」。但这两件事在 iOS 16.4 之后被彻底解耦了。一个加载得好好的 WKWebView，只要它的 isInspectable 是 false，Safari 的「开发」菜单里就永远不会列出它，哪怕你连真机连得再对。
所以正确的排查顺序是：先确认 WebView 允许被检查（isInspectable / webviewDebuggingEnabled），再去折腾连接链路。顺序反了，你会在「检查数据线、重插 USB、重启 Safari」上浪费一下午。
# 二、iOS 16.4 的关键变更：isInspectable 默认关了
这是整件事的根因，也是最容易被老经验坑到的地方。
iOS 16.3 及更早：只要 App 是 Debug（开发签名）构建，里面所有的 WKWebView / SFSafariViewController 默认就能被 Safari 网页检查器连上，你不需要写任何额外代码。很多人「以前真机调 WebView 一直好好的」就是吃了这个默认红利。
从 iOS 16.4 / iPadOS 16.4 / macOS 13.3 开始，Apple 在 WKWebView 上加了一个新属性 isInspectable（Objective-C 里是 inspectable），并且默认值是 false。也就是说：
从 iOS 16.4 起，任何 WKWebView 默认都不可被检查。无论 Debug 还是 Release，你必须显式把
webView.isInspectable = true，Safari 的开发菜单才会列出它。
官方原文档对应的说法是：
// iOS 16.4+ / macOS 13.3+
// 默认 NO，必须显式打开才能被 Web Inspector 连接
webView.inspectable = YES;
// Swift
if #available(iOS 16.4, *) {
webView.isInspectable = true
}
