用apm init --package初始化插件项目可生成含activationCommands、main和version字段的规范骨架，漏掉activationCommands导致不激活，main路径错误则加载失败；开发须用atom --dev启动以触发热重载，调试应通过Developer Tools的Sources标签页下断点排查。
用 apm 初始化插件项目时别跳过 apm init --package
直接 clone 模板或手动建文件夹容易漏掉关键结构，apm init --package 会生成符合 Atom 插件规范的骨架，包括 package.json 中必需的 activationCommands、main 和 version 字段。漏掉 activationCommands 会导致插件不自动激活；main 路径写错（比如写成 lib/index.js 但实际是 lib/main.js）会让整个插件加载失败，错误信息通常是 Failed to activate package。
开发阶段必须启用 --dev 模式启动 Atom
只靠 apm link 不足以触发热重载——Atom 默认缓存已加载的插件模块。每次改完代码后，必须用 atom --dev 启动，才能让编辑器读取最新源码。否则你会反复遇到“改了代码但没生效”的情况，尤其在修改 lib/main.js 的命令注册逻辑时，这个坑最隐蔽。
-
--dev模式下，Atom 会禁用所有非开发态插件，避免干扰 - 终端里看到
Starting in dev mode才算真正进入开发态 - 如果用了
apm link但没加--dev，插件可能被加载两次（一次来自全局安装，一次来自 link 路径），引发重复注册命令的错误
调试时优先查 Developer: Toggle Developer Tools 而不是控制台日志
Atom 的插件错误不会全量输出到 DevTools Console，默认只显示顶层异常。真正有用的线索藏在 Sources 标签页下的 atom://.atom/packages/your-package-name/ 路径里——断点打在这里才能看到 TextEditor 实例状态、atom.commands.add 的回调执行路径，以及 atom.packages.getActivePackage 返回值是否为 null。
- 常见误判：看到
Cannot read property 'onDidChange' of undefined，其实是atom.workspace.getActiveTextEditor()返回undefined，因为当前没打开任何编辑器 - 不要依赖
console.log输出判断生命周期，activate()和deactivate()的调用时机受activationCommands触发条件严格约束
轻量插件尽量避开 atom-text-editor 的 DOM 操作
直接操作 atom-text-editor 元素的 innerHTML 或绑定原生 click 事件，极易和 Atom 自身的 TextEditorComponent 渲染逻辑冲突，导致光标错位、软换行失效或装饰丢失。正确做法是用 Atom 提供的 API：
- 插入文本用
editor.insertText()，不是element.innerText += - 添加行内提示用
editor.decorateMarker()，不是element.querySelector('.line').appendChild() - 监听编辑动作用
editor.onDidChange()，而非element.addEventListener('input')
越绕开底层 DOM，插件越稳定——特别是当用户开启多光标或软包裹时，手写的 DOM 逻辑几乎必然崩坏。
