Chrome原生消息替代方案：自用多端扩展最快连接Redis的实现问询

先澄清认知偏差：Chrome 原生消息机制（Native Messaging）并未被弃用，当前所有Chrome稳定版依然完整支持 chrome.runtime.connectNative、chrome.runtime.sendNativeMessage 两个API。你之前检索不到相关说明，是因为Chrome官方文档调整了导航结构，把原生消息相关的API说明整合到了独立的Native Messaging模块下，不再在chrome.runtime的根API列表直接放置跳转入口，不存在功能下线的情况。

第一优先级：基于Native Messaging的本地轻量Redis代理（速度最快） #

这是比你当前HTTP转发方案延迟低一个数量级的实现，完全适配你个人自用、多台云端机器部署的场景：

• 实现逻辑：根本不需要搭建完整的Web服务器，仅需编写百行以内的轻量程序（Node/Python/Rust均可）作为Chrome的原生消息宿主进程。这个进程直接在本地和目标Redis建立TCP长连接，接收扩展通过原生消息通道发来的Redis命令，执行后将结果通过标准输入输出回传给扩展即可。
• 性能优势：
  • 通信走Chrome和本地进程的标准输入输出通道，没有TCP握手、TLS协商、HTTP头解析的固定开销，同机器下单次通信延迟可以压到1ms以内
  • 可以直接复用Redis客户端的pipeline、连接池能力，批量命令的吞吐量和本地原生Redis客户端无差异
  • 不需要开放任何对外网络端口，没有公网暴露的安全风险
• 多机部署适配：仅需把这个宿主程序、对应的原生消息配置清单，通过云主机的初始化脚本批量部署即可。因为是个人自用，不需要走Chrome扩展的审核流程，直接以开发者模式加载扩展就能正常调用原生消息API。

第二优先级：基于WebSocket的长连接转发（改动量最小、性能次优） #

如果你不想额外编写原生宿主程序，可以在现有HTTP转发架构上做最小改动，把性能拉到接近原生消息的水平：

• 把原来的无状态HTTP短连接接口替换为WebSocket长连接服务
• 省掉每次请求重复的TCP/TLS握手、HTTP头部解析的固定开销，整体延迟比普通HTTP接口低60%以上
• 基于WebSocket长连接可以直接批量传输Redis命令，不需要反复建立网络连接，吞吐量比普通HTTP高2~3倍

不推荐的无效路径 #

• 尝试用扩展内的WASM版Redis客户端直连Redis：浏览器网络栈不支持原生TCP套接字，WASM也绕不开这个限制，无法直接和Redis的TCP端口建立连接，本质上还是要走HTTP/WebSocket通道，没有性能提升
• 公网直接暴露Redis端口让扩展连接：首先扩展根本没法发送符合Redis协议的原生TCP包，其次暴露Redis端口有极高的安全风险，完全不适合自用场景

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