不能直接覆盖安装旧版llvm工具链，因为覆盖会不可逆地破坏旧项目依赖的abi、诊断格式等行为；正确做法是通过homebrew多版本formula（如llvm@15）显式安装、pin锁定，并用完整路径调用，或手动构建时指定独立前缀（如/opt/llvm-15.0.7）并精确控制path。
为什么不能直接覆盖安装旧版 LLVM
LLVM 工具链（clang、llc、lld 等）默认安装到 /usr/local/bin 或 Homebrew 的 Cellar/llvm@xx 目录，升级时若用 brew install llvm 或 make install，新二进制会直接覆盖旧的——这不是“升级”，是“替换”。一旦覆盖，旧项目依赖的 clang++-14 行为（比如 ABI、诊断格式、内联汇编语法）就不可逆地失效了。
Homebrew 用户：用版本化 formula 显式保留旧版
Homebrew 支持多版本共存，但必须主动锁定旧版，否则 brew upgrade 会一并清除旧 bottle。
- 先查已安装的旧版本：
brew search llvm@（如llvm@15、llvm@16） - 若未安装，用历史 formula 安装（例如 macOS 12 上需用
llvm@15）：brew install llvm@15 - 安装后立即 pin（钉住）它：
brew pin llvm@15—— 这会阻止brew upgrade删除或更新它 - 验证路径：
ls -l $(brew --prefix llvm@15)/bin/clang++，确保它没被 symlink 到新版 - 使用时显式调用：
$(brew --prefix llvm@15)/bin/clang++ -std=c++17 foo.cpp，避免依赖$PATH中的默认clang++
手动构建用户：安装到独立前缀 + 精确控制 PATH
自己从源码构建 LLVM 时，最容易失控的点是 cmake -DCMAKE_INSTALL_PREFIX 设错。一旦设成 /usr/local，就和系统级工具混在一起，无法隔离。
- 每次构建都指定唯一安装路径，例如：
cmake -DCMAKE_INSTALL_PREFIX=/opt/llvm-15.0.7 ... - 不要用
sudo make install往系统目录写；用普通用户权限安装到/opt或$HOME/llvm-15 - 在 shell 配置中按需切换：
export PATH="/opt/llvm-15.0.7/bin:$PATH"，而不是无差别追加 - 检查是否生效：
which clang和clang --version必须一致；若不一致，说明$PATH里有别的 clang 在前面
嵌入式或 MCU 场景：triple 和 target 必须匹配旧工具链行为
即使保留了旧版 clang 可执行文件，如果链接时用了新版 lld 或新版 libc++，仍可能因 ABI 不兼容导致运行时崩溃——尤其在裸机 Cortex-M 项目中。
- 旧工程若依赖
arm-none-eabi-clang-14，就别混用lld-16；应统一从同一 LLVM 版本构建全套工具链 - Keil MDK 中的 ARM Compiler 5（AC5）本质是闭源封装，无法“升级保留”，只能独立安装原包，且不能与 AC6 共享
ARMCC_PATH - 检查实际调用链：
clang --target=armv7m-none-eabi --print-prog-name=ld，确认它返回的是你期望的lld路径，而非系统默认的 GNUld
brew upgrade 或 source ~/.zshrc 后悄然失效。
