离线安装 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）的联网机器上操作：
- 进入插件目录（如
~/.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 或手动开对应类型文件验证功能是否真可用。
