龙芯 loongnix25 下载神器 Motrix Next 安装小记

一台龙芯 3A6000，一个官方根本没适配的架构，一个下载器。记录从"装不上"到"用得爽"的完整过程。

先说结论

在龙芯 loongnix 25（loongarch64）上，Motrix Next 可以完整跑起来，包括三大浏览器的下载接管。但它不像 x86 那样 apt install 一句话搞定——上游只发 x86_64 和 aarch64 包，龙芯用户必须自己编译打包。

整个事情分成两半：

Motrix Next 接管浏览器下载的工作链路

先说一句最关键的：下载数据走的是 HTTP API（127.0.0.1:29110），不走原生消息通道。原生消息只负责"把应用叫起来"。理解这一点，后面很多设计就顺了。

为什么龙芯装不了

Motrix Next 是 Motrix 的重写版，技术栈换成了 Tauri 2 + Vue 3 + Rust，下载引擎换成自研的 aria2-next。问题就出在这儿：

• Tauri CLI 没有 loong64 的 npm 包
• Tauri 打包器硬编码了架构判断
  ，tauri-utils 源码里的 target_triple() 只认 x86、arm、riscv64，没有 loongarch64 分支
• webkit2gtk-4.1-dev 开发包
  ，龙芯源里没有
• aria2-next 引擎
  也没有 loong64 预编译产物

四个卡点，每一个都能让编译停在半路。

主程序编译：四个卡点的解法

卡点一：WebKit 开发包缺失

pkg-config --cflags webkit2gtk-4.1 查不到任何东西，编译直接报错。

龙芯官方源里只有运行时的 webkit 库，没有 -dev 包。解决方案是从龙芯维护的 Debian 移植源下载 .deb，然后做免注册叠加——只取编译需要的 .pc 文件、头文件和 .so 软链接，不动系统包管理器。

这样做有个好处：不会污染 dpkg 数据库，也不会和系统已有的 WebKit 运行库打架。版本号要对齐本机实际的 2.50.6，否则链接阶段会出问题。

卡点二：aria2-next 引擎

引擎是 CMake 的超级构建（superbuild），会自己把依赖拉齐再编译。需要打一个补丁：在 cmake/superbuild/Dependencies.cmake 里给 ARIA2_OPENSSL_TARGET 加上 loongarch64 分支，因为 OpenSSL 3.5.6 其实内置了 linux64-loongarch64 目标，只是上游没写进判断逻辑。

编译完 strip 一下，23MB，放到 src-tauri/binaries/ 下，命名成 motrix-next-engine-loongarch64-unknown-linux-gnu——Tauri 就是按这个命名规则找 sidecar 的。

卡点三：Tauri CLI 无 loong64 包

npm 上确实没有。但 Rust 有：

cargo install tauri-cli --version "^2" --locked

从源码编译，慢一点，但能用。

卡点四：前端构建三连坑

这三个坑一个比一个隐蔽：

第一个，pnpm-workspace.yaml 里 supportedArchitectures.cpu 硬编码了 x64 和 arm64，需要补上 loong64。

第二个，unocss 的根入口静态引入了 JSX 转换器，而它依赖 @oxc-parser/binding-linux-loong64-gnu——这个包 npm 上不存在。解决办法是改成子路径导入，绕过根入口。

第三个最坑：家目录下有个残留的 ~/node_modules/@types/minimatch（只有 package.json，没有 index.d.ts 的 stub 包），TypeScript 向上查找类型时命中了它，报出一堆莫名其妙的类型错误。在 tsconfig.json 里显式限定 typeRoots 才解决。

经验

：TS 的向上查找机制在 monorepo 和家目录混用场景下很容易踩雷，显式限定比靠默认行为可靠。

打包：不改上游源码

主程序编译成功后，Tauri 打包器在最后一步失败——还是那个架构硬编码的问题。

这里我选择不改 Tauri 源码。理由很实际：改源码意味着以后每次升级都要重新打补丁，维护成本高。替代方案是手工复刻官方 deb 的目录布局：

/usr/bin/motrix-next                       主程序 /usr/bin/motrix-next-engine                下载引擎 /usr/bin/motrix-next-browser-launcher      原生消息 launcher /usr/lib/MotrixNext/{data,native-messaging}  资源 /usr/share/applications/MotrixNext.desktop   桌面入口

关键点：Tauri 运行时会按 <可执行文件目录>/../lib/<产品名> 去找资源，目录布局对了就能正常启动。

最终产物 21.8MB 的 deb 包，dpkg -i 装上，菜单里就能看到 MotrixNext。

Motrix Next 主界面

一个黑窗口，差点让前面的努力白费

装完启动，窗口是黑的。

这种问题最难受——进程活着，就是看不见界面。排查思路是变量隔离：应用源码里有个 gpu_guard，强制设置了两个 WebKit 环境变量：

WEBKIT_DISABLE_COMPOSITING_MODE=1 WEBKIT_DISABLE_DMABUF_RENDERER=1

用 WebKit 自带的 MiniBrowser 加上同样的环境变量测试，100% 复现崩溃，日志里是 WebProcess CRASHED——WebKit 的渲染进程在创建 surfaceless EGL 上下文时 abort 了。龙芯的显卡驱动栈对这种模式支持不完整。

解法很优雅：不去改环境变量，而是用应用自带的开关。写一个配置文件：

{   "preferences": {     "hardwareRendering": true   } }

放到 ~/.local/share/com.motrix.next/config.json，应用启动时读这个值，就不会去设那两个环境变量了。

⚠️ 重要提醒：装好之后千万别在「设置 → 高级」里关掉硬件渲染，会再次黑窗口。这个选项在龙芯上是反向的。

浏览器接管：Chromium 系的经验

Chromium 系的三个浏览器（龙芯浏览器 / 360 / Chromium）走的是同一套机制：

1. 扩展放到本地目录，用 --load-extension 加载
2. 原生消息清单写到各浏览器的 NativeMessagingHosts/ 目录
3. 用 allowed_origins 声明允许的扩展来源

有个细节值得说：扩展的 ID 是可以自己固定的。Chromium 用扩展公钥的 SHA256 前 16 字节推导 ID，所以只要在 manifest 里写入自己生成的 key，ID 就固定了。这次固定为 hldkohpmjkaifacejbebmdhbecgpgglm，好处是原生消息清单里能写死，不用每次重新配置。

另一个细节：龙芯浏览器的偏好文件是 base64 加密的，没法直接改配置注入扩展。最后的办法是用用户级 desktop 文件覆盖，在 Exec 行加上 --load-extension 参数——不动系统文件，升级也不会丢。

Firefox：完全不同的路

Firefox 这边机制完全不同，值得单独说：

最关键的是签名。Firefox 未签名的扩展只能通过 about:debugging 临时加载，重启浏览器就没了。想常驻就必须走 AMO 签名。

好在官方扩展已经上架 AMO，直接下载签名版 XPI：

# 从 AMO API 查最新版本和下载链接 curl -s "https://addons.mozilla.org/api/v5/addons/addon/motrix-next-extension/"

拿到签名 XPI 后放进 profile 的 extensions/ 目录，文件名必须等于扩展 ID：

~/.mozilla/firefox/<profile>/extensions/motrix-next-extension@aninsomniacy.dev.xpi

Firefox 就是靠文件名来识别 profile 内直接安装的扩展的。

原生消息清单写到 ~/.mozilla/native-messaging-hosts/，字段换成 allowed_extensions：

{   "name": "com.motrix.next.browser",   "path": "/usr/bin/motrix-next-browser-launcher",   "type": "stdio",   "allowed_extensions": ["motrix-next-extension@aninsomniacy.dev"] }

一个把我卡住的细节

配好之后测试，launcher 报 untrusted_caller。反复检查清单没问题，扩展 ID 也没写错。

去翻官方源码才明白——validate_browser_caller 函数里，Firefox 的调用格式是两个参数：

[manifest_path, extension_id]     if extension_id == FIREFOX_EXTENSION_ID         && manifest_file_name(manifest_path) == format!("{HOST_NAME}.json")

我之前只传了扩展 ID 一个参数，落在 _ => Err(UntrustedCaller) 分支里了。按正确格式（清单路径 + 扩展 ID）测试，立刻返回 {"ok":true}。

这件事的教训：遇到"看起来配置都对但就是不工作"的情况，别在配置层面反复试，直接去看源码。源码里的校验逻辑是最权威的文档。

Firefox 扩展管理器——Motrix Next Extension 已启用

顺手清掉的两个历史包袱

aria2c 可以退休了

Motrix Next 内置了 aria2-next 引擎，系统里那份独立的 aria2c 就是多余的了——一个下载工具就够了。

清理过程比较顺：先停用并禁用用户的 systemd 服务，备份配置到 ~/aria2-backup/，再卸载。

这里遇到个小插曲：apt-get purge aria2 被系统里无关的 libreoffice 依赖异常挡住了。根因是之前有人往软件源里加了个 backports 临时源，导致 libreoffice 这个纯依赖壳元包的版本和实际组件对不上，卡在"半安装"状态，把 apt 的依赖求解器整个搞瘫了。

处理方式是删掉那个卡住的元包（先模拟确认只删壳、不动组件），依赖树就恢复正常了。

⚠️ 踩坑提醒：这种情况千万别跑 apt --fix-broken install，它会从 backports 拉一整套新版本组件，把冲突扩大化。正确做法是定位到具体的半装包，单独处理。

Firefox 其实早就装好了

顺手补装了 Firefox 的简体中文语言包。这里也有个小发现：Debian 系里 Firefox 的包名是 firefox-esr（延长支持版），而且语言包是独立的包，主体装完不代表界面是中文的：

sudo apt install firefox-esr-l10n-zh-cn

ESR 版本对政务环境其实更合适——安全补丁稳定，一年才跳一个大版本，不像快速迭代版那样天天更新。

最终效果

现在浏览器里点任何下载链接，都会自动转到 Motrix Next，多线程加速。magnet 链接和 torrent 文件也做了协议关联，双击直接进下载队列。

关于龙芯适配的一点感想

这次折腾下来，最大的感触是：国产架构上跑 Linux 应用，"能不能装"和"能不能用"是两回事。

编译通过只是第一步，运行期还有图形栈、驱动、字体渲染等一堆问题在等着。这次遇到的 WebKit 渲染进程崩溃就是典型——代码没问题，是底层驱动栈的能力边界问题。

而且会发现一个规律：上游绕不开的架构硬编码，往往可以用"绕过"而不是"修改"来解决。打包器不认 loongarch64？那就手工打包，不改 Tauri 源码。这样上游升级时不会给自己挖坑。

另外，配置类问题真的要多翻源码。这次 launcher 的参数校验，如果只在配置层面猜，可能猜一天都猜不出来。源码里的那几行 match 分支，比任何文档都直接。

龙芯的生态还在建设中，很多路得自己走一遍。但走通了之后写下来，下一个人就能少踩几个坑——这也是我把这些细节都记下来的原因。

参考文档

项目与源码

• Motrix Next 主仓库：https://github.com/AnInsomniacy/motrix-next
• 浏览器扩展仓库：https://github.com/AnInsomniacy/motrix-next-extension
• Firefox 扩展（AMO）：https://addons.mozilla.org/firefox/addon/motrix-next-extension/
• 原生消息 launcher 源码（调用者校验逻辑）：src-tauri/native-messaging/src/lib.rs

本机安装路径

构建脚本（工作目录 /home/huzhou/motrix-build/）

相关技能文档

• ~/.workbuddy/skills/loong64-tauri-app-build/SKILL.md
   — Tauri 2 应用龙芯本地构建与打包全流程
• ~/.workbuddy/skills/chromium-download-bridge/SKILL.md
   — 浏览器下载接管（扩展 ID 推导、原生消息 shim）