多标签场景下Web扩展native-messaging API的请求处理方案咨询

单常驻原生实例模式的多标签请求处理规则 #

在所有标签页共享一个长驻原生应用进程的架构下，请求的处理逻辑完全由底层固定机制决定，不存在浏览器runtime层面的强制抢占或者中断：

1. 浏览器侧的转发逻辑：后台脚本通过runtime.connectNative()建立的长驻通信端口，底层是浏览器和原生应用之间的双向stdio管道。来自不同标签页内容脚本的请求，会按照到达后台脚本的顺序，无延迟写入原生应用的stdin管道缓冲区，不会因为前一个请求还在处理就阻塞后续请求的写入。
2. 原生应用侧的代码逻辑决定最终实际表现：
   • 如果原生应用是单线程串行处理模型：读取到一条stdin消息后，同步阻塞直到处理完成、把响应写回stdout，再读取下一条stdin消息，那么跨标签的第二个请求会一直在内核维护的stdin缓冲区排队，直到第一个请求处理完毕才会被读取处理，表现为串行阻塞，全程不会出现第一个请求被中途打断的情况。
   • 如果原生应用是多线程/异步协程模型：每读取到一条stdin消息，就启动独立的执行单元完成处理，不阻塞后续stdin消息的读取，那么跨标签的两个请求会并行处理，各自把响应写回stdout。只要在消息里带上对应的请求来源标识，后台脚本就能准确把响应路由回对应的标签页，不会出现串扰。
   • 无论哪种模型，都不存在“新请求到来自动中断前一个正在处理的请求”的机制，除非后台脚本主动关闭和原生应用的通信端口，触发原生应用的退出逻辑。

单标签页独立原生实例架构的重复请求处理方案 #

改成每个标签页对应独立原生应用进程的模式后，不同标签页的通信通道、进程资源完全隔离，不存在跨标签的通道竞争问题。针对“同一标签页前置请求未完成时重复触发新请求”的场景，增加忙状态校验是完全必要且更合理的实现，相关逻辑要点如下：

• 独立进程隔离只解决了跨标签的资源竞争问题，没有解决单个进程内部的重复请求开销：如果请求涉及本地大文件读写、硬件接口操作、重型本地计算这类高开销操作，重复触发的请求会无谓占用CPU、IO资源，甚至触发本地文件锁冲突、硬件接口占用冲突。
• 校验逻辑不需要全部下沉到原生应用层实现，更轻量的方案是在扩展的后台脚本侧完成：给每个独立的原生应用实例维护一个isBusy标记位，发起新请求前先检查标记状态——如果标记为忙，直接忽略后续的重复请求，或者向内容脚本返回“上一次请求仍在处理中”的提示，不需要把消息透传到原生应用层，减少进程间通信的额外开销。
• 只有当所有请求都是完全幂等、且资源开销极低（比如读取固定路径的配置值）的场景，才可以考虑省略这个校验逻辑。

常见实现误区：不少开发者误以为Native Messaging的长驻端口是全局独占锁，只要原生应用在处理请求，整个通道就会被锁死。实际上通道只是内核维护的流式管道，串行还是并行处理、要不要做抢占，完全由自身业务代码决定，浏览器runtime层不会做强制的限制。

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