必须使用交叉工具链并严格配置编译选项与路径：CC需显式指定完整路径，MARCH和MABI须匹配硬件能力，--sysroot指向工具链sysroot，输出目录按工具链隔离，缺失检查与参数审计不可省略。
直接用本地 gcc 编译出来的二进制，跑不到 RISC-V 或 ARM 板上——必须换交叉工具链、改编译选项、管好头文件和库路径。Makefile 不是简单替换 gcc 为 riscv64-unknown-elf-gcc 就完事，漏掉任一环节都会卡在链接失败或运行崩溃。
交叉编译器路径和变量必须显式声明
不能依赖 PATH 里碰巧有的交叉工具链，也不能让 Make 自己猜。一旦项目迁移到新机器或 CI 环境，which riscv64-unknown-elf-gcc 可能返回空，导致静默 fallback 到本地 gcc，编译通过但烧录后不启动。
-
CC必须设为完整路径或带前缀的命令，例如：CC = riscv64-unknown-elf-gcc或更稳妥的CC = /opt/riscv/bin/riscv64-unknown-elf-gcc - 配套的
AR（归档）、OBJCOPY（生成 bin）、SIZE（查看段大小）也要一并定义，否则make flash类目标会报 command not found - 用
$(shell which $(CC) 2>/dev/null)做存在性检查，缺失时$(error "Cross compiler $(CC) not found")主动中断，别等链接时报一堆 undefined reference
-march 和 -mabi 必须匹配目标芯片硬件能力
写错 -march 是最隐蔽的崩溃源：代码能编译、能烧录、甚至能跑几条指令，然后在执行原子操作或压缩指令时硬复位。这不是 Makefile 写得不对，而是它没强制校验这些参数。
- 常见组合示例：
-march=rv32imac -mabi=ilp32（裸机小资源 MCU），-march=rv64gc -mabi=lp64（Linux SoC） - 不要写成
-march=rv32i却在代码里调__atomic_fetch_add——imac里的a（原子扩展）没开，链接时不会报错，运行时 trap - 把
MARCH和MABI拆成独立变量，和CFLAGS拼接：CFLAGS += -march=$(MARCH) -mabi=$(MABI)，方便不同板子切配置
头文件与库路径要指向交叉工具链自带的 sysroot
用主机系统的 /usr/include 编译，等于拿 glibc 的头去喂 newlib/rt-thread，struct timespec 定义对不上、clock_gettime 符号找不到是常态。
- 加
--sysroot是关键：CFLAGS += --sysroot=/opt/riscv/riscv64-unknown-elf（路径以你安装位置为准） - 如果工具链没自带 libc（比如某些 bare-metal 构建），需显式禁用标准库：
CFLAGS += -nostdlib -nostartfiles，并手动指定crt0.o位置 -
INCLUDES变量只追加额外路径，如自己的include/，别覆盖--sysroot自带的搜索逻辑
目标文件输出路径必须隔离，避免混入 host 构建产物
同一项目既跑 x86 单元测试又交叉编译固件时，若 .o 全扔 ./obj/ 下，make clean 会误删 host 测试的目标文件，且 make -j 可能并发读写冲突。
- 按工具链命名输出目录：
OBJ_DIR = obj-$(CC_NAME)，其中CC_NAME = $(notdir $(CC))（提取riscv64-unknown-elf-gcc） - 所有
.o规则强制创建子目录：$(OBJ_DIR)/%.o: src/%.c | $(OBJ_DIR)，依赖项$(OBJ_DIR)是 mkdir 命令 - 最终可执行文件也带前缀：
TARGET = firmware.elf→$(CC_NAME)-$(TARGET)，防止app被本地构建覆盖
最难调试的不是语法错误，而是交叉环境里“看起来成功”的构建——二进制体积正常、file 显示架构正确、串口有输出，但某次中断响应慢了 10ms，最后发现是 -mabi=ilp32e 用了实验性扩展，而芯片手册明确写了不支持。Makefile 的责任不是让编译通过，是让每一个参数可审计、可复现、可切换。
