扩展程序可以使用类似于其他消息传递 API 的 API 与原生应用交换消息。支持此功能的原生应用必须注册一个可与扩展程序通信的原生消息传递主机。Chrome 会在单独的进程中启动主机，并使用标准输入和标准输出流与其通信。
原生消息传递主机
如需注册原生消息传递主机，应用必须保存一个用于定义原生消息传递主机配置的文件。
该文件的示例如下：
{
"name": "com.my_company.my_application",
"description": "My Application",
"path": "C:\\Program Files\\My Application\\chrome_native_messaging_host.exe",
"type": "stdio",
"allowed_origins": ["chrome-extension://knldjmfmopnpolahpmmgbagdohdnhkik/"]
}
原生消息传递宿主清单文件必须是有效的 JSON，并且包含以下字段：
name- 本地消息传递主机的名称。客户端将此字符串传递给
runtime.connectNative()或runtime.sendNativeMessage()。此名称只能包含小写字母数字字符、下划线和英文句点。名称不能以英文句点开头或结尾，并且英文句点后面不能跟另一个英文句点。 description- 简短的应用说明。
path- 原生消息传递主机二进制文件的路径。在 Linux 和 macOS 上，路径必须是绝对路径。在 Windows 上，它可以相对于包含清单文件的目录。启动宿主进程时，当前目录设置为包含宿主二进制文件的目录。例如，如果此参数设置为
C:\Application\nm_host.exe，则会从当前目录“C:\Application”启动。 type- 用于与原生消息传递主机通信的接口类型。此参数只有一个可能的值：
stdio。这表示 Chrome 应使用stdin和stdout与主机通信。 allowed_origins- 应有权访问原生消息传递主机的扩展程序列表。
allowed-origins值不能包含通配符。
原生消息传递主机位置
清单文件的位置取决于平台。
在 Windows 上，清单文件可以位于文件系统中的任何位置。应用安装程序必须创建注册表项（HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application 或 HKEY_CURRENT_USER\SOFTWARE\Google\Chrome\NativeMessagingHosts\com.my_company.my_application），并将该项的默认值设置为清单文件的完整路径。例如，使用以下命令：
REG ADD "HKCU\Software\Google\Chrome\NativeMessagingHosts\com.my_company.my_application" /ve /t REG_SZ /d "C:\path\to\nmh-manifest.json" /f
或者使用以下 .reg 文件：
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Google\Chrome\NativeMessagingHosts\com.my_company.my_application]
@="C:\\path\\to\\nmh-manifest.json"
当 Chrome 查找原生消息传递主机时，会先查询 32 位注册表，然后再查询 64 位注册表。
在 macOS 和 Linux 上，原生消息传递主机清单文件的位置因浏览器（Google Chrome 或 Chromium）而异。系统级原生即时通讯主机在固定位置查找，而用户级原生即时通讯主机在用户个人资料目录的 NativeMessagingHosts/ 子目录中查找。
- macOS（系统级）
- Google Chrome：
/Library/Google/Chrome/NativeMessagingHosts/com.my_company.my_application.json - Chromium：
/Library/Application Support/Chromium/NativeMessagingHosts/com.my_company.my_application.json - macOS（用户专用，默认路径）
- Google Chrome：
~/Library/Application Support/Google/Chrome/NativeMessagingHosts/com.my_company.my_application.json - Chromium：
~/Library/Application Support/Chromium/NativeMessagingHosts/com.my_company.my_application.json - Linux（系统级）
- Google Chrome：
/etc/opt/chrome/native-messaging-hosts/com.my_company.my_application.json - Chromium：
/etc/chromium/native-messaging-hosts/com.my_company.my_application.json - Linux（特定于用户，默认路径）
- Google Chrome：
~/.config/google-chrome/NativeMessagingHosts/com.my_company.my_application.json - Chromium：
~/.config/chromium/NativeMessagingHosts/com.my_company.my_application.json
原生消息传递协议
Chrome 会在单独的进程中启动每个原生消息传递主机，并使用标准输入 (stdin) 和标准输出 (stdout) 与其通信。双向发送消息时都使用相同的格式；每条消息都使用 JSON 进行序列化、使用 UTF-8 进行编码，并且前面带有以原生字节顺序表示的 32 位消息长度。来自原生消息传递主机的单个消息的大小上限为 1 MB，这主要是为了保护 Chrome 免受行为不当的原生应用的侵害。发送给原生消息传递宿主的消息大小上限为 64 MiB。
原生消息传递宿主的第一个实参是调用者的来源，通常为 chrome-extension://[ID of allowed extension]。这样一来，当原生消息传递主机清单的 allowed_origins 键中指定了多个扩展程序时，原生消息传递主机便可识别消息来源。
在 Windows 上，原生消息传递主机还会收到一个命令行实参，其中包含对调用 Chrome 原生窗口的句柄：--parent-window=<decimal handle value>。这样，原生消息传递主机便可创建正确设置了父级的原生界面窗口。请注意，如果调用方上下文是服务工作线程，则此值为 0。
当使用 runtime.connectNative() 创建消息传递端口时，Chrome 会启动原生消息传递宿主进程，并使其保持运行状态，直到该端口被销毁。另一方面，如果使用 runtime.sendNativeMessage() 发送消息，而不创建消息传递端口，Chrome 会为每条消息启动一个新的原生消息传递宿主进程。在这种情况下，主机进程生成的第一个消息将作为对原始请求的响应进行处理，并且 Chrome 会将其传递给调用 runtime.sendNativeMessage() 时指定的响应回调。在这种情况下，本地消息传递主机生成的所有其他消息都会被忽略。
连接到原生应用
向原生应用发送消息以及从原生应用接收消息与跨扩展程序的消息传递非常相似。主要区别在于，使用 runtime.connectNative() 而不是 runtime.connect()，使用 runtime.sendNativeMessage() 而不是 runtime.sendMessage()。
如需使用这些方法，必须在扩展程序的清单文件中声明“nativeMessaging”权限。
这些方法在内容脚本中不可用，仅在扩展程序的页面和服务工作器中可用。如果您希望从内容脚本与原生应用通信，请将消息发送到您的服务工作线程，以便将其传递给原生应用。
以下示例创建了一个连接到原生消息传递主机 com.my_company.my_application 的 runtime.Port 对象，开始监听来自该端口的消息并发送一条传出消息：
var port = chrome.runtime.connectNative('com.my_company.my_application');
port.onMessage.addListener(function (msg) {
console.log('Received' + msg);
});
port.onDisconnect.addListener(function () {
console.log('Disconnected');
});
port.postMessage({text: 'Hello, my_application'});
使用 runtime.sendNativeMessage 向原生应用发送消息，而无需创建端口，例如：
chrome.runtime.sendNativeMessage(
'com.my_company.my_application',
{text: 'Hello'},
function (response) {
console.log('Received ' + response);
}
);
调试原生消息传递
当发生某些原生消息传递失败时，输出会写入 Chrome 的错误日志。这包括原生即时通讯主机无法启动、写入 stderr 或违反通信协议的情况。在 Linux 和 macOS 上，可以通过从命令行启动 Chrome 并在终端中查看其输出来访问此日志。在 Windows 上，请按照如何启用日志记录中的说明使用 --enable-logging。
以下是一些常见错误以及解决这些错误的提示：
未能启动原生消息传递主机。
检查您是否拥有执行原生消息传递主机文件的足够权限。
指定的原生消息传递主机名无效。
检查名称是否包含无效字符。仅允许使用小写字母数字字符、下划线和英文句点。名称不能以点开头或结尾，并且点后面不能跟另一个点。
原生主机已退出。
在 Chrome 读取消息之前，与原生消息传递主机的管道已损坏。这很可能是从您的原生即时通讯主机发起的。
找不到指定的原生消息传递主机。
请检查以下事项：
- 扩展程序和清单文件中的名称拼写是否正确？
- 清单是否位于正确的目录中，并且名称是否正确？如需了解预期格式，请参阅原生消息传递主机位置。
- 清单文件是否采用正确的格式？具体来说，JSON 是否有效且格式正确，并且值是否与原生消息传递主机清单的定义相符？
path中指定的文件是否存在？在 Windows 上，路径可以是相对路径，但在 macOS 和 Linux 上，路径必须是绝对路径。
原生即时通讯主机主机名未注册。（仅限 Windows）
在 Windows 注册表中找不到原生即时通讯主机。使用 regedit 仔细检查密钥是否已真正创建，以及是否符合原生消息传递主机位置中记录的所需格式。
禁止访问指定的原生消息传递主机。
扩展程序的来源是否列在 allowed_origins 中？
与原生消息传递主机通信时出错。
这表示原生消息传递主机中的通信协议实现不正确。