Chrome扩展MV3迁移后Service Worker无法接收原生应用消息求助

常见性说明 #

这种“能发不能收”的半连接状态在MV3扩展迁移中确实存在，核心原因是Chrome的Service Worker生命周期特性或原生端连接的隐性异常，导致通信通道单向失效但未触发断开事件。

可能的触发原因 #

• 原生端（C++）出现隐性连接失效：比如线程阻塞、句柄泄漏、系统资源回收导致无法向扩展推送消息，但Chrome侧的端口对象仍被标记为活跃，不会触发port.onDisconnect。
• Service Worker被闲置终止后重启：MV3的Service Worker在闲置约5分钟后会被销毁，即使后续被唤醒，之前的通信端口底层通道已失效，但端口对象本身未被清理，导致只能发不能收。

判断是否需要重连的方法 #

1. 心跳检测机制（最可靠） #

在扩展与原生应用之间建立定时心跳交互：

• Service Worker每隔固定时间（如30秒）发送心跳消息：port.postMessage({type: "heartbeat"})
• 原生端收到心跳后立即回复确认消息：{type: "heartbeat_ack"}
• Service Worker维护一个计时器，若连续2-3次未收到ACK，判定连接异常，触发重连逻辑。

2. 业务消息超时检测 #

针对需要响应的业务请求，设置超时阈值（如10秒）：

• 发送业务消息时启动计时器，若超时未收到回复，先尝试发送心跳验证连接，若仍无响应则重连。
• 注意区分业务自身的处理超时和连接异常，可通过消息类型做差异化判断。

3. 原生端主动反馈（需原生配合） #

在C++原生应用中添加连接状态检测：

• 检查与扩展通信的管道/套接字的可写状态，若发现无法发送消息，主动关闭连接并重启。
• 原生端主动断开后，Chrome后续发送消息时会触发port.onDisconnect，此时可在监听事件中直接触发重连。

重连的注意事项 #

• 重连前务必调用port.disconnect()销毁旧端口，避免资源泄漏。
• 新端口创建后，重新绑定所有port.onMessage监听事件，因为新端口是独立对象。
• 加入重连退避策略：首次重连等待5秒，失败后依次递增等待时间（如10秒、20秒），防止无限循环重连占用资源。

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