应使用 clang++ 而非 clang 编译 C++ 文件，因其自动链接 libstdc++ 或 libc++ 并启用 C++ 模式；若用 clang 则需手动链接标准库，否则出现 undefined reference 错误。
clang++ 命令编译失败：找不到 stdc++ 或报错 undefined reference to `std::cout`
直接用 clang（而非 clang++）编译 C++ 文件，链接阶段会漏掉标准库，导致符号未定义。这是最常见也最容易忽略的起点错误。
- 用
clang++代替clang—— 它自动链接libstdc++或libc++，并启用 C++ 模式 - 若显式指定标准库，加
-stdlib=libc++（macOS 默认）或-stdlib=libstdc++（Linux 常见），但通常不需手动加 - 避免混用
clang+-lstdc++：可能因 ABI 不匹配（如 libc++ 和 libstdc++ 混用）引发运行时崩溃
生成可执行文件：从源码到 a.out 的最小可行命令
clang++ main.cpp 就能生成默认输出 a.out，但实际开发中需要控制输出名、标准版本和警告级别。
- 指定输出文件：
clang++ -o hello main.cpp - 启用 C++17 标准（推荐）：
clang++ -std=c++17 -o hello main.cpp；C++20 用c++20，注意部分特性需较新 Clang 版本（如 12+） - 开启基础警告：
-Wall -Wextra，能捕获未初始化变量、隐式转换等常见隐患 - 调试信息必须加
-g，否则lldb无法查看变量或设断点
链接外部库：比如用 pthread 或自定义静态库
Clang 默认不链接 POSIX 线程库，#include <thread> 编译通过，但链接时报 undefined reference to `pthread_create`。
- 链接系统库：
clang++ -std=c++17 -lpthread -o demo demo.cpp——-lxxx必须放在源文件之后 - 链接静态库：
clang++ -std=c++17 -o app app.cpp ./libmylib.a，路径需写全，不能只写-lmylib（那是动态库查找逻辑） - 头文件路径用
-I/path/to/include，库文件路径用-L/path/to/lib，二者不可互换
运行时报 dyld: Library not loaded（macOS）或 cannot open shared object file（Linux）
这说明运行时找不到动态库，不是编译问题，而是链接时没指定运行时库搜索路径。
立即学习“C++免费学习笔记（深入）”；
- macOS 上用
-rpath @executable_path/../lib或-rpath /usr/local/lib，让可执行文件记住去哪里找 dylib - Linux 上等价的是
-rpath '$ORIGIN/../lib'（注意单引号防止 shell 展开），$ORIGIN指可执行文件所在目录 - 临时解决运行问题可用
export DYLD_LIBRARY_PATH=/path/to/lib（macOS）或export LD_LIBRARY_PATH=/path/to/lib（Linux），但不推荐用于发布 - 用
otool -l ./hello | grep -A2 LC_RPATH（macOS）或readelf -d ./hello | grep RUNPATH（Linux）验证 rpath 是否生效
Clang 编译链里，编译、链接、运行三个阶段各自独立，每个阶段出问题的表现和修复方式差异很大。最容易被跳过的其实是链接器行为——它不报语法错，只在最后一步甩出一堆 undefined reference，而根源往往藏在命令参数顺序或库类型选择里。
