Android WebView中window.JSInterface调用失败主因是API 17+需加@JavascriptInterface注解且不可带window.前缀；iOS WKWebView须用messageHandlers且注册须在加载前；跨平台应以_platform标识环境并用事件总线处理回调。
安卓 WebView 中 window.JSInterface 调用失败的典型原因
Android 原生通过 addJavascriptInterface 暴露对象到 JS 上下文，但默认仅在 API 17+ 安全启用。低于该版本或未加 @JavascriptInterface 注解的方法，在 JS 中调用会静默失败（无报错，但函数不执行）。
- 必须在 Java 方法上显式添加
@JavascriptInterface，否则 Android 4.2+ 会忽略该方法 - JS 调用时不能带
window.前缀（如JSInterface.doAction()可行，window.JSInterface.doAction()在部分系统上失效） - 若 WebView 启用了
setJavaScriptEnabled(true)但仍无响应，检查是否漏掉removeJavascriptInterface("searchBoxJavaBridge_")等系统保留名冲突
iOS WKWebView 中 WKScriptMessageHandler 无法收到消息
iOS 不支持直接挂全局对象，必须走 WKScriptMessageHandler + WKUserContentController 的消息通道。JS 调用 window.webkit.messageHandlers.myHandler.postMessage(...) 后，原生侧收不到，大概率是注册时机或 name 不匹配。
- 务必在
WKWebView初始化后、加载页面前注册 handler（即userContentController.add(self, name: "myHandler")） - JS 中的
name必须与 Swift/ObjC 注册时完全一致（大小写敏感），且不能含空格或特殊字符 - 传参只能是 JSON-serializable 类型（
String/Number/Array/Dictionary），传function或undefined会导致整个 postMessage 失败且无提示
跨平台 JS 插件桥接层如何判断运行环境
不能依赖 navigator.userAgent 做硬判断（容易被伪造或随 WebView 版本变化），推荐用特征检测 + 原生透出标识结合的方式。
- Android 侧可在注入 JS 前，通过
evaluateJavascript("window._platform = 'android';")打标 - iOS 侧在
WKNavigationDelegate的didCommit阶段注入window._platform = 'ios'; - JS 层统一用
if (window._platform === 'android')分支，避免反复查userAgent或webkit对象存在性 - 慎用
typeof window.webkit !== 'undefined'判断 iOS —— 某些安卓定制 WebView 也暴露了webkit
回调函数在双端传递时为什么总丢参数
原生调 JS 回调时，iOS WKWebView 严格限制参数类型，Android 则对序列化宽松但需注意线程。常见表现是回调触发了，但 data 是 null 或 {}。
立即学习“前端免费学习笔记（深入）”；
- iOS：必须用
postMessage发送字面量对象，不能传 JS 函数引用；如需“回调”，应由 JS 事先注册一个全局唯一 ID 的函数，原生通过evaluateJavaScript调用它（例如callJSCallback('cb_123', {ok: true})） - Android：可直接调用 JS 函数，但需确保该函数在全局作用域（
window.xxx），且避免闭包中引用大对象（可能引发内存泄漏） - 统一建议：所有跨端回调都走「事件总线」模式（如
document.dispatchEvent(new CustomEvent('native:ready', {detail: {...}}))），规避原生直接调 JS 的兼容差异
postMessage 会在页面未完成加载（DOMContentLoaded 之前）被丢弃，而 Android addJavascriptInterface 却能在任意时机调用——这意味着桥接初始化逻辑必须和页面生命周期对齐，不能只靠 JS 端 onload 触发。 
