插件放对位置但没反应，首要确认Atom本体是否为官方安装包：Windows须用AtomSetup-x64.exe，Debian/Ubuntu用atom-amd64.deb，CentOS/RHEL用atom.x86_64.rpm；.zip“绿色版”缺失resources/app/apm及签名机制，导致apm命令失效、插件无法加载。
插件放对位置但没反应？先确认 Atom 本体是不是“真安装”
离线安装失败，八成不是插件的问题，而是 Atom 自身就不具备运行插件的基础能力。官方明确要求：Windows 必须用 AtomSetup-x64.exe，Debian/Ubuntu 必须用 atom-amd64.deb，CentOS/RHEL 必须用 atom.x86_64.rpm。用 .zip 解压的“绿色版”或第三方打包版，resources/app/apm 路径大概率缺失或损坏，导致后续所有 apm install 命令失效。
验证方式很简单：apm --version 能输出版本号，且 process.versions.node 在 DevTools 控制台里能查到（通常是 v12.x 或 v14.x），才算过关。否则别急着装插件，先重装官方包。
为什么直接扔 GitHub 源码进 ~/.atom/packages/ 会白屏？
GitHub 上下载的插件 zip 是源码，不是可运行副本。Atom 启动时不会自动执行依赖安装或构建，它只加载已准备就绪的目录。常见报错包括：
-
Error: Cannot find module 'fs-plus'→ 缺node_modules -
Failed to activate package 'color-picker' because it depends on 'season@^7.0.0'→ 依赖未解析、版本不匹配 - 界面白屏或插件列表里完全不显示 →
package.json中"main"字段指向错误文件，或入口文件根本不存在
正确做法是：在与目标机**完全一致 Atom 版本**的联网机器上，进入插件目录后执行：
apm install --production
执行完检查目录下是否有 node_modules，且里面包含该插件实际运行所需的子模块（如 linter-gcc 里要有 gcc 和 atom-linter）。
apm install 和 npm install 到底该用哪个？
优先用 apm install，尤其对含原生模块或需 Atom 特定构建流程的插件（如 linter-gcc、spell-check）。原因很实在：
-
apm自带与 Atom 绑定的 Node 和 npm，锁版本、路径、头文件都对得上；npm用的是系统全局环境，极易因 Node 版本错位导致require失败 -
apm install --production会跳过 devDependencies，体积小、构建快，还执行了postinstall脚本（比如编译 native 模块）；npm install不保证这一步 - 某些插件（如
autocomplete-python）的激活逻辑依赖apm注入的生命周期钩子，npm install后可能“装上了却从不启动”
例外情况：纯 JS 插件（无 native 模块、无 gyp 构建）、且你已确认其 package.json 里没有 apm-only 的字段，此时 npm install 可作为备选，但务必进插件目录执行，不能全局。
哪些插件离线注定失败？别白费功夫
三类插件在离线环境下无法真正启用，拷全了 node_modules 也一样：
- 依赖实时 API 的：如
autocomplete-atom-api（启动时拉 GitHub 上的 Atom API 文档）、platformio-ide（校验云端 toolchain） - 含动态下载逻辑的：如部分
language-rust版本会在首次启用时请求rustc语法定义文件 - 需要全局
apm运行时支持的：如sync-settings，本质是包装了apm login和apm publish，离线机没连过服务器就卡死在初始化阶段
这类插件控制台通常报 Failed to fetch https://... 或长时间卡在 “Loading...”。遇到这种报错，不用折腾路径或依赖，直接换替代方案——比如用本地 rust-analyzer 替代在线拉取的 Rust 语法插件。
真正麻烦的不是“怎么装”，而是每个插件的激活时机、依赖粒度、构建要求都不一样。离线部署前，最省事的办法是在有网机器上跑通一次 apm install --production && apm test，看它到底要什么、怎么活。
