插件必须放入~/.atom/packages（Windows为%USERPROFILE%.atom\packages），Atom仅扫描该路径子目录；离线安装需在同版本Atom中执行apm install --production生成node_modules，否则因缺依赖或兼容性问题失效。
插件必须放进 ~/.atom/packages（Windows 是 %USERPROFILE%\.atom\packages）
Atom 启动时只扫描这个固定路径下的子目录，其他位置（比如 ~/.atom 根目录、~/.atom/installed-packages、云同步文件夹）一律忽略。常见错误包括：
- 把解压后的插件文件夹拖进了
~/.atom，而不是它的packages子目录 - 下载的是
linter-gcc-master.zip，解压出来是linter-gcc-master/，结果又手动建了个linter-gcc文件夹，再把里面内容塞进去——多了一层嵌套，Atom 找不到package.json - Windows 用户启用了 OneDrive 同步
.atom，实际路径变成C:\Users\name\OneDrive\.atom\packages，但 Atom 默认读本地路径，导致“明明复制了却没反应”
apm install --production 必须在目标 Atom 版本下执行
离线安装不是“复制即用”，关键动作是生成 node_modules 并完成 Atom 特定构建。直接 npm install 多数时候不够，因为：
-
apm会读取package.json中的engines.atom字段做兼容性校验，npm不管这个 - 某些插件（如
linter-gcc）含原生模块，apm install会调用内置node-gyp和匹配的 Electron 头文件，npm install可能用错 Node 版本或缺失头文件 -
--production参数跳过devDependencies，减小体积且避免构建失败（离线环境尤其重要）
操作流程：在与离线机**完全一致版本**的 Atom（例如 v1.69.0）中，进入插件目录，运行：apm install --production
执行后检查该目录下是否真实生成了 node_modules，且其中包含插件声明的依赖（如 gcc、atom-linter 等子目录）。
哪些插件复制过去也白搭
三类插件无法真正离线使用，即使 node_modules 齐全、路径正确，启动时仍会失败：
- 依赖实时 API 的：如
autocomplete-atom-api（首次启用时连接 GitHub 拉 API 文档）、platformio-ide（强制校验云端 toolchain） - 含动态下载逻辑的：如部分
language-rust版本会在打开 .rs 文件时尝试拉取语法定义 - 需要全局
apm运行时支持的：如sync-settings，本质是包装了apm login和apm publish，离线机从未连过服务器就无法初始化
这类插件控制台通常报 Failed to fetch https://... 或卡在 loading 状态，不是路径或构建问题，而是设计上就不支持离线。
重启后插件不生效？先开控制台看报错
别凭感觉判断“装好了”。打开开发者工具（Ctrl+Shift+I），切到 Console 标签页，重点关注：
-
Error: Cannot find module 'fs-plus'→ 插件根目录缺package.json，或"main"字段指向的入口文件不存在/大小写不匹配 -
Failed to activate package 'linter' because it depends on 'linter@^3.0.0'→ 依赖插件（如linter）本身没装，或没进packages目录 -
Cannot read property 'onDidStopChanging' of undefined→ 插件是在高版本 Atom 下构建的，但装到了低版本 Atom 上，activationHooks或 API 已移除
最麻烦的不是复制或路径，而是每个插件对激活时机、依赖粒度、构建产物的要求都不一样——autocomplete-python 要等 language-python 加载并打开 .py 文件才触发，go-plus 还得额外配好 gopls 二进制路径。离线前，务必在联网机器上跑通一次 apm install --production && apm test，确认它到底依赖什么。
