离线安装atom插件失败主因是未执行apm install --production导致node_modules缺失、构建不全或本体安装不合规；须在同版本atom中运行该命令，同步安装依赖并确保官方安装包完整。
离线安装 Atom 插件报错，基本不是路径放错了，而是 node_modules 没生成、apm 构建流程没走完，或本体安装方式不合规——这三类问题覆盖了 95% 的失败案例。
报 Cannot find module 'xxx' 是因为插件目录缺 node_modules
常见现象：重启 Atom 后插件不显示，控制台刷出 Error: Cannot find module 'season'、Cannot find module 'fs-plus' 等错误。这不是模块名写错了，是插件根目录下压根没有 node_modules 文件夹。
- GitHub 下载的 ZIP 或
git clone得到的是源码，不是可运行副本；Atom 启动时不会自动执行依赖安装 - 必须在与目标机**完全一致版本**的 Atom 环境中，进入插件目录执行
apm install --production（不是npm install） - 执行后检查目录是否存在
node_modules，且里面包含该插件实际依赖的包（如linter-gcc应有gcc、atom-linter子目录） - 用
npm install替代会漏掉apm特有的 postinstall 步骤（比如编译 native 模块），导致linter-gcc调不起gcc命令
右上角红色报错反复出现，说明构建未闭环
手动执行 npm install lodash.random → 报 Cannot find module 'atom-utils' → 再装 → 又报新错……这是典型“补丁式安装”，本质是跳过了 apm install --production 对 package.json 的完整解析和依赖树收敛。
-
apm install --production会一次性装全dependencies，并跳过devDependencies，体积小、兼容性强 - 逐个
npm install不仅慢，还可能引入与 Atom 内置 Node 版本不匹配的二进制模块（如spell-check里的hunspell） - 若已陷入循环报错，先删掉整个插件文件夹，重新走
apm install --production流程，别修修补补
插件装了但不激活，大概率是 activationHooks 或依赖缺失
比如 autocomplete-python 安装后无提示，不是插件坏了，是它根本没被触发加载——Atom 不靠“启用开关”启动这类插件，而靠打开 .py 文件 + language-python 已就位。
- 检查插件根目录
package.json中"activationHooks"字段是否正确（例如应为"language-python:grammar-used"，不是"python"） - 确认
"main"指向的入口文件存在，且路径大小写完全匹配（Windows 下尤其敏感） - 必须同步离线安装前置依赖，如
language-python、linter、linter-ui-default—— 少一个，整条链就断 - 某些插件（如
minimap）还需额外构建步骤：apm link或npm run build，源码 ≠ 可运行态
本体安装方式错误，所有离线操作都白搭
如果 Atom 本体是解压 AtomSetup-x64.zip、或从非官方镜像下载的“绿色版”，那后续所有插件安装都会失效——因为 resources/app/apm 二进制缺失，或签名验证机制被绕过。
- Windows 必须用
AtomSetup-x64.exe（.zip 是无效包） - Debian/Ubuntu 必须用
atom-amd64.deb（dpkg -i），不能用.tar.gz - CentOS/RHEL 必须用
atom.x86_64.rpm（yum localinstall自动解决 glibc） - macOS 必须用官网
Atom-mac.zip（Apple 签名完整包），不是 GitHub Release 里的源码包
真正麻烦的不是复制文件，而是每个插件对激活时机、依赖粒度、构建要求都不一样：autocomplete-python 靠语法包触发，linter 靠事件监听，go-plus 还得调外部 gopls 二进制。离线部署前，在有网机器上跑通一次 apm install --production && apm test，比盲目拷贝快得多。
