离线安装 atom 插件必须用同版本 atom 的 apm install --production 构建,生成 node_modules 并验证 main 入口、依赖版本及文件夹名与 package.json 一致;直接复制源码会因缺失构建步骤、依赖或网络请求而失败。

离线安装 Atom 插件,不是把 GitHub 源码解压扔进 ~/.atom/packages 就完事——90% 的失败都卡在这一步。必须生成 node_modules,且路径、入口、依赖版本三者全对,插件才可能被 Atom 加载。
为什么直接复制源码会白屏或报 Cannot find module
Atom 启动时只加载已构建完成的插件目录,不执行任何自动安装逻辑。GitHub 上下载的 zip 或 git clone 得到的是源码,不含 node_modules,也未运行 postinstall 脚本(比如编译 native 模块、生成 lib/ 目录)。常见报错包括:
-
Error: Cannot find module 'fs-plus'→ 缺node_modules,或package.json中"main"字段指向不存在的文件(如写成./src/main.js但实际只有./lib/main.js) -
Failed to activate package 'linter' because it depends on 'linter@^3.0.0'→ 依赖插件没一并离线安装,或版本不匹配 - 控制台空空如也,插件列表里也不显示 → 文件夹名与
package.json中"name"不一致(如文件夹叫autocomplete-python,但package.json写的是"name": "atom-autocomplete-python")
必须用 apm install --production,在同版本 Atom 下构建
apm 是 Atom 官方包管理器,它和 npm 不兼容:锁版本策略不同、engines.atom 校验逻辑不同、postinstall 脚本执行路径也不同。离线部署前,你得在一台**和目标机完全一致 Atom 版本**(如 v1.69.0)的联网机器上操作:
一款AI工具,主要用于管理 OpenClaw 所使用的来自 OpenRouter 的免费 AI 模型。自动按质量对模型进行排序,配置回退机制以应对速率限制,并更新 opencla...,适合需要提升相关任务效率的用户。
- 进入插件目录(如
~/.atom/packages/linter-gcc),运行apm install --production - 确认生成了
node_modules,且里面包含该插件真正依赖的子目录(如gcc、atom-linter) - 检查
package.json中"main"字段是否指向有效 JS 入口(如"main": "./lib/main.js"),且该文件确实存在 - 不要用
npm install替代 —— 即使成功,也可能漏掉apm特有的构建步骤,导致linter-gcc调不了gcc可执行文件
哪些插件根本没法离线用
有些插件从设计上就拒绝离线:它们启动时硬性发起网络请求,失败即卡死或报错。这类插件即使把整个 node_modules 拷过去也没用:
- 依赖实时 API:如
autocomplete-atom-api(首次启用会拉取 GitHub 上的 Atom API 文档) - 含动态下载逻辑:如某些
language-rust版本会在打开.rs文件时尝试下载语法定义 - 需要全局
apm运行时支持:如sync-settings,本质是包装apm login和apm publish,离线机从未连过服务器就无法初始化 - 报错典型特征:
Failed to fetch https://...、Network request failed、控制台卡在 pending 状态
最麻烦的不是“怎么装”,而是每个插件激活时机、依赖粒度、构建产物路径都不一样:autocomplete-python 靠 language-python 加载触发,go-plus 得调外部 gopls 二进制,minimap 还要先 npm run build 出 dist/。离线前,务必在有网机器上跑通一次 apm test 或手动开对应类型文件验证功能是否真可用。










