企业官网建设流程全解析

开头

玩 Arch Linux 的 GNOME 桌面，十有八九都会去 extensions.gnome.org 装扩展。结果分两种情况：一种顺顺利利，另一种就是开头这个吓人的红字报错——No such native application org.gnome.chrome_gnome_shell。我第一次遇到的时候还以为是浏览器插件坏了，折腾半天卸载重装浏览器扩展，一点用没有，最后才搞清楚问题根本不在浏览器那边，而是系统里少装了一个连接器。

这个报错表面上是浏览器插件在喊“找不到原生应用”，实际是 GNOME 浏览器集成扩展和系统守护进程之间的一座桥断了。Arch 用户遇到尤其多，因为上游把老包chrome-gnome-shell换成了gnome-browser-connector，很多人不知道这回事，照着旧教程装完浏览器扩展，却漏掉了系统端的新包，于是报错就出现了。这篇文章就是把这座桥从头到尾拆开给你看，从原理到修复命令，再到验证步骤，一步步讲清楚。适合刚接触 Arch + GNOME 的新手，也适合升级完系统后突然发现扩展网站连不上的老用户。

对症下药之前，必须先把报错为什么出现这件事说透，否则解决了这次，下次换台机器照样踩坑。

1. 错误背后的原理拆解：这是一座“断了的桥”

1.1 “No such native application”到底是谁在报错

先抛结论：这个报错是浏览器扩展（GNOME Shell Integration，也就是常说的 chrome-gnome-shell 浏览器插件）抛出来的，不是 GNOME 桌面抛出来的。

它的工作机制是：你在浏览器里打开 extensions.gnome.org，网页脚本通过浏览器插件向本机 GNOME Shell 的 D-Bus 服务发请求，查询已安装扩展、安装新扩展。但浏览器有个安全机制——网页和本机程序通信不能直接乱来，必须走“Native Messaging”通道。浏览器会去固定的几个目录里找一个特定名称的 JSON 清单文件，清单里写着“这个原生应用叫什么名字、它的可执行文件在哪”。

这个 JSON 文件就是关键。它注册的 native application 名是org.gnome.chrome_gnome_shell，对应可执行程序一般是/usr/bin/chrome-gnome-shell或者新版包里的/usr/bin/gnome-browser-connector。如果浏览器翻遍所有目录都找不到名为org.gnome.chrome_gnome_shell的清单文件，或者清单里声明的可执行文件不存在，它就会原封不动地报出：

No such native application org.gnome.chrome_gnome_shell

所以这句话不是“GNOME 崩溃了”，也不是“浏览器坏了”，而是浏览器在说：“系统里没有注册这个原生消息主机，我没办法帮你跟 GNOME 通信。”

1.2 Arch 上为什么特别容易踩这个雷

这个坑在 Arch 上发生率极高，不只是新手，很多老玩家换新机器也会中招。

原因要从 Arch 的包历史说起。早年 Arch 仓库里有个叫chrome-gnome-shell的包，负责提供这个 JSON manifest 和可执行文件。大概从 2022 年起上游项目改名重构，新包叫gnome-browser-connector，旧的chrome-gnome-shell被标记为废弃，很多镜像源里直接就移除了。

问题就出在这里：

• 新用户查攻略，搜到一篇两年前的教程，教程上写“执行sudo pacman -S chrome-gnome-shell”，结果提示找不到包。
• 有人改用 AUR 装旧包，装上之后 manifest 路径不兼容，照样报错。
• 有些人装完gnome-browser-connector之后没重启浏览器，浏览器仍然按旧缓存去找 manifest，报错继续。

更隐蔽的情况是：你明明装了新包，但浏览器是Flatpak 版（比如 Flatpak 版 Chrome / Firefox），它运行在沙箱里，原生消息主机的搜索路径和普通系统版不一样，系统里装的 manifest 它根本看不见，于是继续报同样的错。

还有一个高频场景：刚升级完系统。Arch 是滚动更新，一次大版本升级把gnome-shell、gnome-browser-connector都更新了，但你的浏览器还开着旧进程，加载的还是旧配置，此时去扩展网站看，可能就会偶发这个报错。

1.3 用生活类比讲清 Native Messaging

把这个机制类比成打电话订餐可能更好理解。

浏览器是大酒店的前台（网页），GNOME Shell 后厨（桌面服务）。电话线是 D-Bus 总线。前台想点菜，总得有个通讯录查到后厨的分机号。Native Messaging 就是那本通讯录，JSON 清单文件就是通讯录里的一张名片，上面写着“后厨分机号是 10086，分派电话转接的程序在/usr/bin/...”。

现在浏览器拿了名片本，翻遍所有抽屉，就是没有写着org.gnome.chrome_gnome_shell的那张名片——那它当然只能说“找不到这个原生应用”。要么名片本没买（系统包没装），要么名片被放到了另一个抽屉（Flatpak 或路径错误），要么名片上的号码作废了（旧包残留指向不存在的二进制）。

这样理解之后，排查和修复的方向就非常清晰了：想办法让浏览器能找到一张正确的“名片”。

2. 解决思路与工具选型：先装对系统端包，再装对浏览器插件

2.1 Arch 上的唯一正确解法：gnome-browser-connector

从上游项目改名之后，Arch 官方仓库里目前提供的包就是gnome-browser-connector。它做的事情和旧chrome-gnome-shell一样，安装后会替你完成三件事：

• 在系统目录里放好 Native Messaging 的 JSON manifest；
• 提供/usr/bin/gnome-browser-connector可执行程序（部分版本里也叫chrome-gnome-shell，兼容命名）；
• 启动一个 D-Bus 相关的辅助服务（实际是配合 GNOME Shell 的远程扩展安装通道）。

所以在 Arch 上，修复这个报错的第一步其实是两条命令这么简单：

sudo pacman -S gnome-browser-connector

如果系统里还留着旧包，先移掉：

sudo pacman -Rns chrome-gnome-shell

但我不建议直接跑完命令就收工。因为有些服务器镜像还没同步完，或者你之前从 AUR 装过特殊版本，系统里可能残留多个 manifest 文件互相打架。建议先查一下当前状态再动手：

pacman -Qs 'gnome.*browser.*connector|chrome-gnome-shell'

看到安装的包名，再接着往下做。如果提示两个包都存在，务必把chrome-gnome-shell卸干净。

2.2 浏览器端：官方扩展插件务必装对

系统端连接器只是“桥墩”，浏览器端还得有一座“桥面”——GNOME Shell Integration 浏览器扩展。

• Firefox / Chromium / Chrome / Edge：从 extensions.gnome.org 首页点击安装，浏览器会自动识别并跳转到扩展商店页面（Firefox 是 Add-ons 商店，Chromium 系是 Chrome 网上应用店）。
• 安装完浏览器扩展之后，它会在浏览器菜单栏出现一个 GNOME 图标，点击后能显示已连接的 GNOME Shell 版本。

这里有个容易忽略的点：新版连接器对浏览器扩展的版本有最低要求。如果你浏览器扩展装的是很老的 10.x 版本，与新gnome-browser-connector的通信协议对不上，同样会出问题。解决办法是把浏览器扩展移除后重新安装，拿到当前最新版。

2.3 绕开浏览器的备选方案：Extension Manager

如果你就是不想折腾浏览器扩展，或者想绕开整个 Native Messaging 机制，Arch 社区有一个非常好用的第三方工具叫Extension Manager（AUR 里搜索extension-manager即可）。它是原生 GTK 应用，直接通过 GNOME Shell 的 D-Bus 接口管理扩展，完全不依赖浏览器。

我的看法是：Extension Manager 更适合日常管理，适合只想装几个扩展、不想被浏览器插件绑架的人。但浏览器集成方式也有优势——可以直接在网页上看截图、看评分、一键安装。这篇文章主要解决浏览器方式的报错，所以 Extension Manager 作为后续的替代方案提一嘴，不做展开。

2.4 为什么“只装包”解决不了所有情况

这里必须提一个关键认知：装包只是把桥墩立起来，桥面能不能对接，还取决于运行环境。

举个例子，如果你的 GNOME Shell 版本过老（比如还在 3.36），而连接器对应的是 GNOME 42+ 的新协议，即使 manifest 和可执行文件都正常，浏览器扩展连上后也会在页面里提示版本不匹配。Arch 用户一般滚动升级不存在这问题，但如果你用旧 ISO 安装后长期没升级，就有可能出现。

所以完整解决路径应该是：

1. 确认系统包正确安装、旧包清除。
2. 确认浏览器扩展安装且为最新。
3. 重启浏览器（必要时重启 GNOME Shell 或直接注销登录）。
4. 回到扩展网站验证连接。

3. 实操过程与核心环节实现：从报错到成功安装的全流程

3.1 第一步：清理旧包、安装新连接器

先打开终端，执行下面的命令序列。我建议一步步来，而不是一次性粘贴，方便随时看输出。

# 查看当前是否安装了相关包 pacman -Qs 'chrome-gnome-shell|gnome-browser-connector'

输出可能有三种情况：

• 只有gnome-browser-connector，说明包没问题，继续下一步查浏览器插件。
• 只有chrome-gnome-shell，说明是旧包，直接移除然后装新。
• 什么都没有，这就是报错最直接的原因，装新包即可。

执行：

# 如果存在旧包，先移除 sudo pacman -Rns chrome-gnome-shell # 安装新连接器 sudo pacman -S gnome-browser-connector

安装完成后，验证关键文件是否到位：

ls -l /usr/bin/gnome-browser-connector

正常情况下会输出一个可执行文件。如果是旧包路径，也可能是：

ls -l /usr/bin/chrome-gnome-shell

然后检查 Native Messaging manifest 是否被正确放置到浏览器会搜索的路径。不同浏览器搜索路径不一样，但 Arch 的包一般会同时装好几份。你可以用pacman -Ql查看文件清单：

pacman -Ql gnome-browser-connector | grep native-messaging

常见的 manifest 路径有：

• Chromium：/etc/chromium/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
• Chrome：/etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
• Firefox：/usr/lib/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json
• 用户级目录：~/.local/share/chromium/native-messaging-hosts/等

看到对应文件存在，就说明系统端的“名片”已经放进抽屉了。

3.2 第二步：重启浏览器，刷新连接

很多人装完包后兴冲冲回到扩展网站，结果还是报同样的错。原因多半是浏览器没重启，或者浏览器的原生消息主机缓存还在。

正确操作顺序：

1. 彻底关闭浏览器，不是“关闭窗口”，而是从进程层面退出。Firefox 可以直接退出菜单，Chromium 系用Ctrl+Shift+Q或在系统托盘退出。不确定的话，终端执行pkill -f firefox或pkill -f chrome来收尾。
2. 重新打开浏览器，打开https://extensions.gnome.org。
3. 此时如果浏览器没有 GNOME 扩展图标，先安装/启用浏览器扩展（网站顶部会提示你安装）。
4. 点击浏览器工具栏上的 GNOME 图标，正常应该显示“连接成功，GNOME Shell 版本 xxx”。

如果一次不行，可以刷新页面后再试。这一步看似废话，但根据我的经验，至少有 1/3 的人卡在这里——装的包没问题，就是没重启浏览器。

3.3 第三步：在扩展网站实际安装一个扩展做验证

连接成功后，随便挑一个热门扩展——比如User Themes或者Tray Icons——在网页上拨动开关。正常情况浏览器会弹出 GNOME 原生的系统对话框询问是否允许安装扩展，选择允许之后扩展立刻生效。

如果这一步出现“无法连接到 GNOME Shell”或者实际扩展没出现在系统里，那问题可能不在 Native Messaging，而在 GNOME Shell 侧的 D-Bus 权限或扩展版本兼容。可以回到桌面，打开终端验证 GNOME Shell 的 D-Bus 服务是否正常响应：

gdbus call --session \ --dest org.gnome.Shell \ --object-path /org/gnome/Shell \ --method org.gnome.Shell.Extensions.List

如果返回一长串 JSON 数组，说明 DBus 服务正常。如果返回类似“Error: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown”的信息，说明 GNOME Shell 根本没有在这个会话里运行，或者你当前用的不是 GNOME 桌面会话——比如跑到 KDE 里装 GNOME 扩展，那肯定连不上。

3.4 第四步：处理最难缠的 Flatpak 浏览器沙箱问题

如果你用的是 Flatpak 版浏览器（例如 Flathub 上的 Firefox、Chrome），那情况会变得微妙。Flatpak 沙箱限制了进程对系统路径的访问，浏览器在沙箱里找 Native Messaging manifest 时，默认只能看到~/.local/share/flatpak/和~/.var/app/<应用名>/下的用户级目录，系统级/usr/lib/...里即使装了包它也看不见。

解决方案有两种，选一种操作：

方案 A：给 Flatpak 浏览器授权访问系统路径（不推荐，破坏沙箱语义）

用flatpak override把/etc、/usr/lib等路径暴露给应用，治标不治本，而且沙箱内权限放开会有安全风险。

方案 B：不用 Flatpak 版浏览器，用系统原生包

Arch 官方源的firefox、chromium、google-chrome（AUR）都是普通包，直接运行在宿主环境，能正常读取/usr/lib等系统路径，最省心。我的建议就是别为这事折腾 Flatpak 覆盖，Arch 用户直接用 pacman 装浏览器才是正路。

3.5 验证清单：一张表确认每个环节

4. 常见问题与排查技巧实录

4.1 高频报错的速查表

我收集了几个实际踩过的坑，把症状和解决办法放一张表里，方便直接对照：

4.2 排查思路：三层递进法

遇到这个报错，不要病急乱投医。我推荐三层递进排查法：

第一层，查物理存在：manifest 文件在不在，可执行文件在不在。用ls和pacman -Ql确认。如果文件都不全，补装包即可。

第二层，查桥面对接：浏览器是否读到 manifest。这层不好直接观察，但可以借助浏览器的原生消息日志来辅助判断。Chromium 系的调试方式是在地址栏输入chrome://extensions，打开“GNOME Shell integration”的服务工作者（Service Worker）控制台，看控制台里有没有关于 native messaging 的错误；Firefox 则在about:debugging里找扩展的“调试”按钮，同样看控制台日志。

第三层，查对端状态：GNOME Shell 的 D-Bus 服务是否正常。用前面说的gdbus call命令测试。如果 D-Bus 都连不上，前面两层查得再仔细也白搭。

举个例子，我见过一个兄弟，他系统里 manifest 文件齐全，浏览器扩展也重装了好几次，就是报错。我让他查 D-Bus，发现 GNOME Shell 进程根本挂掉了，一直在崩溃重启。把抽风的第三方扩展卸掉、重启 GNOME Shell 后，浏览器那边什么都不用改就好了。这个案例充分说明排查顺序有多重要——不要只盯着浏览器报错信息本身。

4.3 独家避坑：关于org.gnome.chrome_gnome_shell这个名字本身

有个细节值得多说一句。这个 native application 的名字始终是org.gnome.chrome_gnome_shell，即使新包叫gnome-browser-connector，manifest 文件名也是这个名字——不能改。浏览器通信协议里要求的是这个名字，改了名字浏览器就找不到。

我之前见过有人尝试“优化”，把 JSON 文件改成了org.gnome.browser_connector.json，结果可想而知，报错更严重。所以记住了：manifest 的文件名和 JSON 里"name"字段都必须保持org.gnome.chrome_gnome_shell不变。这个名字是协议层面的兼容约定，不是随便起的。

如果你想手动检查某份 manifest 是不是这份协议，用cat看看：

cat /usr/lib/mozilla/native-messaging-hosts/org.gnome.chrome_gnome_shell.json

正常内容类似：

{ "name": "org.gnome.chrome_gnome_shell", "description": "GNOME Shell browser integration", "path": "/usr/bin/gnome-browser-connector", "type": "stdio", "allowed_origins": [ "chrome-extension://likdammnmodgmhdjajnnbcniklmaeggm/", "moz-extension://..." ] }

如果path指向的文件不存在，或者name变了，那浏览器一定报错。这种手动审查的方法，是我在排查环境差异比较大的机器时最常用的招。

4.4 升级系统后的“隐性复发”

Arch 滚动更新的特性决定了这个报错不会一次性解决。下次sudo pacman -Syu之后，如果gnome-browser-connector更新，但浏览器还开着，连接可能短暂失效。这通常不是大问题，关闭浏览器重开就恢复。如果你习惯长时间不关浏览器，且启用了“休眠标签页”类功能，旧标签页里的扩展页可能一直保持旧状态，这时候在扩展网站刷新一下页面基本就好。

另外一个常见诱发情况：升级后gnome-shell进入新的大版本（比如 45 升 46），此时不仅连接器要更新，部分旧扩展也可能不兼容导致桌面报错。这不是 Native Messaging 的问题，是扩展本身的兼容问题，别混淆在一起排查。

4.5 手动注册的终极方案（不推荐但值得会）

如果安装了包仍然无法让浏览器识别，最后一招是手动注册用户级 manifest。这个方法适合极少数包管理器无法满足需求的场景，比如你自己编译安装了 Docker 容器里的连接器。

原理很简单：浏览器在用户目录里也会搜索原生消息清单。对 Chromium 系，把 JSON 文件放到~/.local/share/chromium/native-messaging-hosts/即可；对 Firefox，放到~/.mozilla/native-messaging-hosts/；对 Chrome 则是~/.config/google-chrome/NativeMessagingHosts/。放好之后让 JSON 里的path指向真实存在的可执行文件。

但我不推荐日常使用这个方案，因为手动注册的 manifest 不会随系统包升级更新，哪天连接器更新了，你手动注册的内容还指着一个旧路径，反而留下隐患。了解它，是为了在极端情况下能自救，正常还是靠包管理器。

5. 写在最后的一些实在话

我自己第一次调到这个坑时，花了整整一个晚上，从浏览器扩展改成 AUR 版旧包，又从旧包切回官方新包，最后发现就是没重启浏览器。第二天想想又气又笑。

后来我养成一个习惯：凡是遇到“No such native application”这类报错，先问自己一句，协议对端的系统包装了没、服务起了没，而不是死磕报错客户端本身。这个方法不只适用于 GNOME 扩展，Chrome 的 gpg 密钥集成、VS Code 的 git 凭据助手，背后的 Native Messaging 机制如出一辙。报错里那个org.gnome.chrome_gnome_shell就是一个注册名，学会用pacman -Ql反查包内文件、用gdbus验证远端服务，基本上任何同类问题你都能自己排查。

如果只是想快速装扩展，我的建议是直接用 Extension Manager 这种原生工具，省心。要是你更习惯网页浏览找出感兴趣的扩展，那就按本文这套步骤来，把包装好、浏览器重启彻底、D-Bus 服务确认正常，这三板斧下去，报错基本上不会再出现在你面前。

顺带说一句，升级系统后如果又碰到这个报错，先深呼吸，把浏览器关了再重开，别急着重新装包。我这个过来人已经把弯路替你走完了，你要做的就是记住这条捷径。