必须用目标机同版本atom执行apm install --production构建，否则因node/abi不匹配、原生模块未编译或engines.atom校验失败导致插件无法激活。
直接复制 node_modules 到插件目录会失败
你复制的 node_modules 很可能来自另一台机器、另一个 Node 版本，或根本不是 Atom 插件专用构建产物。Atom 启动时会校验插件的 engines.atom 兼容性、检查 main 入口路径是否可读、并尝试加载 node_modules 中的模块（如 season、fs-plus）。若这些模块缺失、路径错位、或二进制原生模块（如 node-spellchecker）未针对 Atom 内置 Node 编译，就会报 Error: Cannot find module 'season' 或 Cannot read property 'onDidStopChanging' of undefined。
apm install --production 是唯一能生成可用 node_modules 的方式
这个命令不只是装依赖，它会：
- 读取插件
package.json中的engines.atom，拒绝为不兼容版本构建 - 调用 Atom 自带的
node和npm（非系统全局），确保 ABI 一致 - 执行插件定义的
postinstall脚本（比如编译 native 模块、生成dist/） - 跳过
devDependencies，避免离线环境因缺少构建工具（如 Python、gyp）而中断
错误做法包括：npm install 替代 apm install、在目标机上直接运行 apm install（网络不通）、或用高版本 Atom 构建后拷贝到低版本机上。
必须和目标机 Atom 版本完全一致
Atom v1.69.0 和 v1.72.0 内置的 Electron、Node.js、API 表面相似，但内部事件签名、服务注册方式已变。常见表现是插件“已安装”却完全不激活，DevTools 控制台报 undefined is not a function 或空对象属性访问错误。验证方法：
- 在目标机上打开 Atom →
Ctrl+Shift+I→ 输入process.versions.node和atom.getVersion() - 在构建机上运行
apm --version，确认输出的 Atom 版本号（如apm 3.0.0对应 Atom 1.69.0） - 构建完成后，进入插件目录检查
node_modules/gcc（以linter-gcc为例）是否存在，而非只看顶层有没有node_modules
Windows 用户最容易漏掉的两个路径
即使 apm --version 成功，apm install 仍可能卡死或编译失败，原因常是 PATH 缺失关键路径：
-
C:\Users\<username>\AppData\Local\atom\bin</username>：含apm.exe和atom.exe，用于命令行调用 -
C:\Users\<username>\AppData\Local\atom\app-1.xxx.0\resources\app\apm\bin</username>：含 Atom 自带的node-gyp和构建上下文，原生模块编译必须走这里
漏掉第二条，apm install linter-gcc 会卡在 gyp ERR! stack Error: Can't find Python executable —— 不是因为没装 Python，而是 apm 根本没找到自己该用的 node-gyp。
真正麻烦的不是复制文件，而是每个插件对激活时机、语言绑定、原生模块、甚至 API 版本都敏感。离线部署前，在联网机上跑通 apm test 或至少打开对应文件类型确认提示/诊断功能生效，比反复重试复制更省时间。
