Sublime Text构建系统找不到arm-none-eabi-gcc是因为其GUI启动时不继承shell的PATH环境变量，必须显式写死绝对路径；烧录应封装为独立脚本并用variants分离流程，头文件与宏定义需通过EasyClangComplete手动同步，串口监视器须避让烧录时的USB设备锁。
Sublime Text 本身不支持嵌入式开发的自动识别和烧录，必须手动配置 Build System 并显式写死交叉工具链路径；否则 arm-none-eabi-gcc 或 st-flash 会直接报 command not found，哪怕它们在终端里能正常运行。
为什么 build 系统找不到 arm-none-eabi-gcc
Sublime 启动时默认不继承 shell 的 PATH（尤其 macOS/Linux GUI 启动、Windows 的 PATH 变量未被 GUI 进程加载），所以即使 which arm-none-eabi-gcc 返回了路径，Build System 仍会失败。
- 必须用
which arm-none-eabi-gcc查出绝对路径，例如/opt/gcc-arm-none-eabi/bin/arm-none-eabi-gcc - Windows 用户注意反斜杠需转义或统一用正斜杠：
"cmd": ["C:/gcc-arm/bin/arm-none-eabi-gcc.exe", ...] - 不要用
shell_cmd拼字符串——它绕过环境隔离但无法捕获多行错误，调试困难 -
cmd数组方式更可靠，且 Sublime 能正确解析编译器输出并跳转错误行
烧录命令不能直接塞进 build 配置
像 st-flash、openocd、nrfjprog 行为差异大，有的要先启 server，有的要求芯片处于 DFU 模式，硬编码进 variants 容易静默失败或卡住。
- 把烧录逻辑封装成独立脚本（如
flash_stm32.sh或flash_nrf.bat），开头加set -e（Linux/macOS）或exit /b %errorlevel%（Windows）确保前步失败就中断 - 脚本内做端口检测、重试、超时控制，比如用
ls /dev/ttyACM*或mode COM3验证设备在线 - Build System 中只调用该脚本：
"cmd": ["./flash_stm32.sh", "${file_path}"] - 用
variants分离“仅编译”和“编译+烧录”，避免误触发
头文件和宏定义在 Sublime 里标红或跳转失效
Sublime 自带语法引擎不读 Makefile 或编译命令里的 -I 和 -D 参数，导致 #include "stm32f4xx_hal.h" 标红、Goto Definition 失效、宏条件编译逻辑错乱。
立即学习“C++免费学习笔记（深入）”；
- 装
EasyClangComplete插件（不是 ClangAutoComplete），在它的 settings 里手动填include_dirs和common_flags -
include_dirs用绝对路径或${project_path}变量，例如："${project_path}/Drivers/CMSIS/Device/ST/STM32F4xx/Include" -
common_flags至少包含芯片型号和 HAL 宏：["-DUSE_HAL_DRIVER", "-DSTM32F407xx"] - 别漏掉 CMSIS 和 HAL 库中依赖的其他宏，比如
__weak或__packed相关定义
串口监视器与烧录共用 USB 设备时冲突
烧录过程中 USB 设备（如 ST-Link、J-Link）会被系统锁定，此时串口监视器（如 screen /dev/ttyACM0）会报 Device or resource busy，反之亦然。
- 烧录脚本末尾加延时或设备重枚举等待，比如
sleep 1; lsusb | grep -q 'STMicro' || echo "device not ready" - 串口监视器启动前先检查设备是否空闲：
lsof /dev/ttyACM0（Linux/macOS）或handle.exe -p tty（Windows + Sysinternals） - 不要在同一个 Build System variant 里同时调烧录和串口命令——它们本质互斥
- 推荐用 Terminus 插件开独立终端页签，手动控制串口启停，比自动化更稳
嵌入式开发里最麻烦的从来不是写代码，而是让编辑器“理解”你项目的真实结构：工具链路径、头文件层级、宏开关、硬件状态。Sublime 不会自动猜，你得一项项告诉它——而且每项都得对上实际路径和真实行为。
