Safari Web Extension原生消息发送后beginRequest未触发问题

• 第一类高频问题：API调用参数格式错误
  当前代码中browser.runtime.sendNativeMessage的传参不符合Safari扩展API规范：该方法第一个必填参数是系统可识别的原生消息处理Handler的标识字符串，第二个参数才是需要传递的消息对象。现在的代码直接把消息对象作为第一个参数传入，系统无法定位要唤醒的消息处理通道，自然不会触发原生侧的beginRequest方法。
  正确的调用格式示例：

  // 第一个参数替换为你在项目中注册的Native Message Handler对应的唯一标识
  browser.runtime.sendNativeMessage("你的消息Handler标识", { message: "Hello" });
  

• 第二类问题：原生侧target配置缺失
  很多开发者会把实现NSExtensionRequestHandling协议的类直接放在主App或普通Safari网页扩展的target中，这一配置完全不符合通信逻辑：
  • 必须在Xcode项目中单独新建独立的「Safari Web Extension Native Message Handler」target，这个target是系统原生消息通道的唯一唤醒入口
  • 该独立target的Info.plist中，需要正确配置NSExtension节点：将NSExtensionPrincipalClass指向你实现了协议的处理类，关联对应的扩展点标识
  • 主App的配置中需要嵌入关联这个独立的消息处理target，不能仅靠主App内部的类接收消息
• 第三类问题：权限与签名校验异常
  即使代码逻辑正确，以下配置问题会导致消息被系统静默丢弃，不会抛出可见报错：
  • 所有相关target（主App、网页扩展、原生消息Handler）的开发者团队ID、Bundle ID前缀必须完全一致，否则系统会因权限校验失败拦截消息
  • 调试阶段需要在Safari的开发菜单中勾选「允许未签名的扩展」「允许扩展调试」选项，同时在Safari扩展设置中手动开启对应扩展的「与本机应用通信」权限
• 调试提示
  原生消息调用失败时，弹窗的JS控制台不会展示明确的错误栈。需要切到Xcode控制台，筛选Native Message Handler target的输出日志，定位系统层面的拦截原因。

通信链路的正确逻辑为：弹窗JS触发消息 -> Safari系统定位匹配的Native Message Handler -> 唤醒对应独立target的处理类 -> 完成业务逻辑交互，通信过程不会直接跳过系统唤醒步骤调用主App内部方法。

内容的提问来源于stack exchange，提问作者mikro098