worker进程亲和力是hybrid桥接的辅助可控手段，非直接防护机制；它通过绑定专用实例实现来源可信、能力授权、链路完整性三类断言，配合协议层验签等基础规则形成“隔离执行+边界断言”双控策略。
Worker进程亲和力本身不是Hybrid桥接的直接防护机制，它无法“验证转发边界”，但可作为辅助手段增强桥接调用的可控性与可观测性——关键在于把Worker用作沙箱化执行单元，配合桥接协议层的校验逻辑，形成“隔离执行 + 边界断言”的双控策略。
明确Worker在Hybrid中的定位
在跨平台Hybrid中（如Blazor Hybrid、React Native、或基于WebView2/WebKit的自研容器），Worker（Web Worker 或 .NET Worker / Android HandlerThread / iOS dispatch_queue）不直接参与JSBridge通信，而是被用作：
- 原生能力调用前的参数预处理与合法性断言（例如：校验URL白名单、Token有效期、设备指纹一致性）
- 敏感操作的异步隔离执行（如加密签名、本地密钥派生、截图水印注入），避免阻塞主线程且与WebView JS上下文物理隔离
- 桥接日志的独立采集与上报通道，绕过WebView可能被篡改的console或fetch拦截
构建带亲和约束的桥接验证链
所谓“亲和力”，实际指将特定类型桥接请求绑定到专用Worker实例（而非随意分配），确保其运行环境具备确定性。实现方式因平台而异：
-
Blazor Hybrid（WebView2 + MAUI）：在C#侧为每类高风险桥接方法（如
NativeBridge.capturePhoto()）分配专属TaskScheduler或ThreadPool.UnsafeQueueUserWorkItem绑定CPU核心掩码（需Process.GetCurrentProcess().ProcessorAffinity配合），并在Worker入口强制校验调用来源Origin与Bundle Hash -
Android（X5/Chrome WebView）：使用
HandlerThread创建固定Looper线程，在JSBridge.onCall()中通过Looper.myLooper() == trustedHandler.getLooper()确认执行线程身份；同时检查WebView.getCurrentUrl()是否在预载入的可信离线包签名列表中 -
iOS（WKWebView）：借助
dispatch_queue_attr_make_with_qos_class创建QoS受限队列，在桥接回调中调用pthread_self()比对预注册的worker线程ID，并结合WKWebView.configuration.websiteDataStore的持久化状态判断当前会话是否已被重置
动态验证转发边界的三个落地动作
真正起效的不是Worker本身，而是它触发的三类可验证断言：
-
来源可信断言：Worker启动时读取WebView的
document.baseURI或location.href哈希，与原生侧维护的“已审核页面指纹库”比对，不匹配则拒绝后续所有桥接调用并上报异常事件 -
能力授权断言：Worker执行桥接前，向原生权限中心发起同步查询（如
PermissionManager.check("camera", origin)），仅当返回GRANTED且附带时效签名时才转发至目标API -
链路完整性断言：Worker在桥接调用前后分别采集
performance.now()、process.uptime()（或等效原生指标），若两次采集间隔超过阈值或出现非预期跳变，判定为Hook注入或调试器劫持，自动终止本次调用并清空内存缓存
不依赖Worker也能守住的底线
Worker亲和只是加分项，真正不可妥协的是桥接协议层的基础规则：
- 所有JSBridge调用必须携带
origin、nonce、timestamp三元组，由原生侧统一验签 - 禁止暴露
eval、require、exec类万能接口，能力注册表必须静态声明且不可热更新 - 调试开关（如
jsbridge.debug = true）必须编译期剥离，运行时无法通过任何JS路径开启
Worker的价值，在于让这些规则在隔离环境中被严格执行，而不是替代它们。
