script插件必须配置真实解释器绝对路径，否则Python/Node/Shell均无法运行；需手动切换右下角语言为对应类型、启用终端模式（Ctrl+I）、禁用Script Panel，并通过which命令获取路径填入Command字段。
script 插件必须配真实解释器路径，否则 Python/Node/Shell 都跑不起来
Atom 本身不执行代码，script 插件只是个“调度员”：它根据文件后缀（如 .py、.js、.sh）去调用系统里对应命令。但默认配置往往指向不存在的路径或错误版本。
- 右下角语言名（如 “Plain Text”）必须手动切为
Python/JavaScript/Bash，快捷键Ctrl+Shift+L（Win/Linux）或Cmd+Shift+L（macOS） - 运行前务必按
Ctrl+I（Win/Linux）或Cmd+I（macOS）启用终端模式——否则input()、read -p类交互直接跳过 -
script设置里勾选Use Terminal，禁用Use Script Panel（后者不支持 stdin） - 检查解释器路径：在终端运行
which python3或which node，把输出结果填进script的Command字段（例如/usr/local/bin/node）
HTML/CSS/JS 开发别用 Open in Browser，HTTP 服务才是刚需
右键 → Open in Browser 插件本质是用 file:// 协议打开，所有现代前端特性都会失效：ES6 import 报错、fetch('./data.json') 跨域、相对路径引用 CSS/JS 404。
- 本地起服务最简方案：
python3 -m http.server 8000（Python 3.7+ 自带） - 更推荐：
npx http-server -p 8000（无需全局安装，支持 MIME 类型自动识别） - 要热重载：
npx live-server --port=8000，保存即刷新，错误直接打在终端里 - 务必禁用
atom-html-preview插件——它默认占:3000端口，和live-server冲突，浏览器卡在 “Connecting…”
C/C++ 编译失败？c++-build 插件不自动找 gcc，路径和编码都得手填
c++-build 插件不会自动探测编译器位置，Windows 默认设 MinGW，macOS/Linux 默认找 gcc，但在 Apple Silicon Mac 上可能是 arm64-apple-darwin23-gcc，WSL 里可能是 /usr/bin/gcc，填错就报 gcc not found。
- 先确认编译器真实路径：终端运行
which gcc（macOS/Linux）或where gcc（Windows） - Atom 设置 → Packages →
c++-build→ Settings → 填入绝对路径到Compiler Path栏（如/opt/homebrew/bin/gcc-14） - Windows 输出乱码？把
Encoding改成cp936；WSL/macOS 改成utf8 - 注意：文件必须有
.c或.cpp后缀，否则c++-build当纯文本处理，根本不会触发编译按钮
全栈调试链路：linter + autocomplete + git-plus 缺一不可
全栈开发不是只跑通就行，代码质量、补全效率、提交节奏都要闭环。这三个插件组合能覆盖日常高频痛点：
-
linter-eslint（JS）、linter-csslint（CSS）、linter-htmlhint（HTML）——实时标出语法/风格问题，配合lint-on-save自动修复 -
autocomplete-plus（内置）+atom-ide-ui+ide-typescript—— 提供类型提示、方法签名、跳转定义，接近 VS Code 的智能感知 -
git-plus—— 终端里敲git commit -m "xxx"太慢，直接在 Atom 右键文件→Git: Commit，或 Ctrl+Shift+P 输入Git: Push - 注意：
linter类插件依赖项目根目录下存在对应配置文件（如.eslintrc.js），否则静默失效
全栈开发里最容易被忽略的，是语言识别与解释器路径的耦合关系——文件后缀决定用哪个解释器，解释器路径决定能不能真跑起来，中间断一环，整个流程就卡死在黑屏或报错上。
