离线安装atom插件前必须用官方deb/rpm/msi包重装本体，禁用.zip等绿色版；再在同版本atom中执行apm install --production构建含node_modules的副本；依赖实时api、动态下载或全局apm的插件无法离线使用。
离线安装前必须确认 Atom 本体是否合规
不支持离线插件的 Atom 本体，99% 的问题都出在这一步。AtomSetup-x64.zip、GitHub 上的 atom-mac.zip（非 Apple 签名版）、或从第三方镜像下载的 “绿色版” 都无法运行 apm，因为缺失 resources/app/apm 和签名验证机制。
正确做法只有一条：在目标机器上用官方安装包重装 Atom —— Windows 必须是 AtomSetup-x64.exe，Debian/Ubuntu 必须是 atom-amd64.deb（用 dpkg -i 安装），CentOS/RHEL 必须是 atom.x86_64.rpm（用 yum localinstall）。这些包会自动补全 libasound2、libxkbfile1 等底层依赖，zip 包完全不提供。
apm install --production 是唯一有效的离线构建命令
所谓“离线安装”，本质不是复制文件，而是生成一个带完整 node_modules 的可运行副本。直接从 GitHub 下载源码 zip、或 git clone 后拷进去，一定会失败 —— 因为 require('season')、require('atom-linter') 这类模块根本不存在。
- 必须在与目标机**完全一致版本**的 Atom 下执行：
apm install --production linter-gcc -
--production参数不可省：跳过devDependencies，避免构建失败且减小体积 - 执行后进入
~/.atom/packages/linter-gcc，确认存在node_modules目录，且里面包含gcc、atom-linter等子目录 - 切勿用
npm install替代 —— 它不会执行apm特有的 postinstall 脚本（比如编译 native 模块），linter-gcc就会调不起gcc
哪些插件根本不能离线用
就算你把 node_modules 打包过去，以下三类插件在离线环境下必然失效：
- 依赖实时 API 的插件：
autocomplete-atom-api（需连 GitHub 获取最新文档）、platformio-ide（启动强制校验云端 toolchain） - 含动态下载逻辑的插件：
language-rust某些版本会在首次启用时拉取rustc语法定义 - 需要全局
apm运行时支持的插件：sync-settings本质包装了apm login和apm publish，离线机没连过服务器就卡死
这类插件启动时通常报 Failed to fetch https://... 或卡在加载阶段，和路径、构建都没关系。
手动复制后仍不生效？检查这三点
插件文件夹放对了位置，但 Atom 不识别、不激活、无提示，常见原因如下：
-
package.json中"name"字段必须与文件夹名**完全一致**（大小写敏感），例如文件夹叫autocomplete-python，就不能写成"name": "atom-autocomplete-python" - 缺少前置语言包：如
autocomplete-python依赖language-python，它不加载，补全就不会触发；activationHooks 写错（比如写成"python"而非"language-python:grammar-used"）也会导致不激活 - 入口文件路径错误：
"main": "./lib/main.js"对应的文件实际不存在，或大小写不匹配（Lib/main.js在 Windows 下就找不到）
真正麻烦的不是复制，而是每个插件的激活时机、依赖粒度、构建要求都不一样 —— autocomplete-python 靠语法包触发，linter 靠事件监听，go-plus 还得调外部 gopls 二进制。离线部署前，最好先在有网机器上跑通一次 apm test，看它到底依赖什么。
