离线安装Atom本体必须使用deb/rpm/msi官方安装包，禁用.zip；Windows用AtomSetup-x64.exe，Debian/Ubuntu用atom-amd64.deb，CentOS/RHEL用atom.x86_64.rpm，否则缺失apm及底层依赖导致启动失败。
离线安装 Atom 本体必须用 deb/rpm/msi，别碰 .zip
Atom 官方早在 2024 年就彻底停更 .zip 发行版，Windows/macOS/Linux 各平台仅维护带签名和依赖声明的安装包。在离线环境硬解压 AtomSetup-x64.zip 或 atom-mac.zip，结果一定是启动失败或缺失 apm —— 因为这些包根本不含 resources/app/apm 目录。
正确做法只有一条路径：
- Debian/Ubuntu：下载
atom-amd64.deb（或atom-arm64.deb），运行dpkg -i atom-amd64.deb；系统会自动提示缺哪些库（如libasound2、libxkbfile1），用apt install -f补齐 - CentOS/RHEL：用
atom.x86_64.rpm，执行yum localinstall atom.x86_64.rpm，它能自动解决 glibc 版本兼容性 - Windows：只认
AtomSetup-x64.exe，双击运行；AtomSetup-x64.zip是无效包，解压后无任何可执行文件
apm install --production 是唯一可靠的插件离线构建方式
直接把 GitHub 源码 clone 进 ~/.atom/packages，再跑 npm install，大概率失败。原因很实在：很多插件（比如 linter-gcc）的 package.json 里写了 devDependencies，而 npm install 默认不装它们；但 apm install --production 会强制拉全所有依赖，包括编译期需要的 node-gyp 工具链和原生模块。
关键约束有三个：
- 联网机与离线机的 Atom 版本必须完全一致（例如都是
v1.69.0），否则node_modules里的二进制模块（如spell-check的 native binding）会加载失败 - 执行命令前，确保联网机已装好对应版本的 Node.js（
apm绑定的是 Atom 自带的 Node，但构建时仍需系统级python和make） - 构建完成后，进入插件目录确认存在
node_modules，且里面包含所有子依赖（如gcc、atom-linter），不能只靠package.json和源码
三类插件根本没法离线用，提前识别能省半天劲
不是所有插件都能“打包带走”。以下三类在离线环境下注定失效，强行复制只会看到控制台报错：
- 依赖动态 API 调用的插件：比如
autocomplete-atom-api，它每次输入都向api.atom.io请求补全数据；离线后Failed to fetch是必然结果 - 含远程资源加载逻辑的插件：像
platformio-ide，启动时硬编码请求https://dl.platformio.org下载工具链，没网络就卡死在 splash screen - 使用新版 Atom API 但离线机 Atom 版本太老的插件：例如插件用了
TextEditor::onDidStopChanging（v1.70+ 引入），而你的 Atom 是 v1.58，控制台直接报Cannot read property 'onDidStopChanging' of undefined
Windows 用户最容易漏掉的 PATH 路径
哪怕本体和插件都装对了，apm install 在 Windows 上仍可能卡住或报 gyp ERR! stack Error: Can't find Python executable。这不是缺 Python，而是 Atom 的构建上下文路径没配全。
必须手动把这两个路径加入系统 PATH：
-
C:Users\AppDataLocaltomin（含apm.exe和atom.exe） -
C:Users\AppDataLocaltompp-1.60.0 esourcespppmin（老插件构建时依赖这个路径下的node-gyp和npm）
漏掉第二条，apm 就找不到正确的 node-gyp 版本，所有需要编译的插件（如 spell-check）都会失败。这个细节在官方文档里藏得极深，但却是 Windows 离线部署成败的关键分水岭。
