apm install --production是离线插件构建的唯一可靠方法；必须在与目标机完全一致的atom版本下执行，生成含node_modules的可运行副本，直接复制github源码包必然失败。
apm install --production 是离线插件构建的唯一可靠路径
直接复制 GitHub 源码包到 ~/.atom/packages/ 几乎必然失败，因为 Atom 启动时不会执行 npm install，也不会补全 node_modules。必须用 apm install --production 在与目标机**完全一致版本**的 Atom 下运行，才能生成可运行副本。
常见错误包括：
- 在 Atom v1.72.0 下构建插件，却装到 v1.69.0 的离线机 → 激活时报
Cannot read property 'onDidStopChanging' of undefined - 用
npm install替代apm install→ 缺少postinstall脚本（如编译 native 模块），linter-gcc无法调用系统gcc - 忽略
--production参数 → 多装devDependencies，体积膨胀且可能触发不兼容构建逻辑
执行后务必进插件目录确认存在 node_modules，且其中包含该插件实际依赖的子目录（如 gcc、atom-linter）。
哪些插件根本不能离线用
不是所有插件都能靠“拷过去就跑”，三类插件在离线环境下注定失效：
- 依赖实时 API：如
autocomplete-atom-api（需连接 GitHub 获取最新文档）、platformio-ide（启动强制校验云端 toolchain） - 含动态下载逻辑：如某些
language-rust版本会在首次启用时拉取rustc语法定义文件 - 需要全局
apm运行时支持：如sync-settings本质是包装apm login和apm publish，离线机从未连过服务器就无法初始化
这类插件即使把整个 node_modules 拷过去，控制台也会报 Failed to fetch https://... 或卡在加载阶段。
手动兜底：git clone + npm install 只在特定条件下有效
当 apm install --production 不可用（比如目标机 Atom 版本太老、apm 二进制损坏），才考虑手动方案，但要注意边界：
- 必须确保插件不含原生模块（如
spell-check、term3）——否则npm install会因缺少node-gyp和 Python 报错 - 不能跳过
language-python这类前置依赖 ——autocomplete-python离线安装后无补全，大概率是因为它根本没被激活，而激活前提是language-python已加载且打开的是.py文件 -
package.json中的"main"字段必须指向真实存在的入口文件，路径大小写必须与实际文件名完全一致（Windows 下敏感）
手动操作前，先在有网机器上跑通 npm install && apm test，看它到底依赖什么、是否需要额外构建步骤。
离线部署前必须验证 Atom 本体是否合规
所有离线插件安装失败的底层原因，80% 出在 Atom 本体安装方式错误：
- Windows：只认
AtomSetup-x64.exe，AtomSetup-x64.zip是无效包，解压后双击无响应 - Debian/Ubuntu：必须用
atom-amd64.deb，执行dpkg -i；.tar.gz或第三方“绿色版”缺失resources/app/apm和签名机制 - macOS：必须用官网
Atom-mac.zip（Apple 签名完整包），不是 GitHub Release 里的源码压缩包
非官方安装包会导致 apm 二进制缺失或损坏，后续所有构建、重编译、依赖检查都会静默失败——这不是插件的问题，是基础环境不可信。
