结论：-std=c++11（或更低）下用std::barrier会链接时报undefined reference to 'std::barrier::arrive_and_wait()'，因其是C++20引入特性，需显式启用-std=c++20且确保工具链、标准库版本均支持。
直接说结论：-std=c++11（或更低）下用 std::barrier 会静默编译失败，但链接时报 undefined reference to 'std::barrier::arrive_and_wait()'——这不是代码写错了，是编译器根本没启用 C++20 同步设施。
为什么 std::barrier 在 GCC/Clang 下不工作？
因为 std::barrier 是 C++20 标准引入的，它依赖底层原子操作和线程调度语义的更新。即使你写了 #include <barrier></barrier>，若编译器未被明确告知启用 C++20，头文件可能被忽略、模板未实例化、符号不生成。
-
g++默认仍为-std=gnu++17（GCC 12 及以前），clang++默认更保守 -
#include <barrier>不报错，是因为头文件存在且语法合法，但内部实现被条件编译屏蔽 - 链接时报
undefined reference，本质是编译阶段压根没生成std::barrier的任何符号
如何验证并修复编译器标准选项？
先确认当前实际生效的标准版本：
g++ -dM -E -x c++ /dev/null | grep __cplusplus
输出类似 #define __cplusplus 201703L 就说明仍是 C++17。要启用 std::barrier，必须显式指定：
立即学习“C++免费学习笔记（深入）”；
- GCC 11+ / Clang 12+：加
-std=c++20或-std=gnu++20 - MSVC 19.30+：需
/std:c++20，且项目属性中“C++语言标准”设为 C++20 - 注意：CMake 中不能只写
set(CMAKE_CXX_STANDARD 20)，还必须加set(CMAKE_CXX_STANDARD_REQUIRED ON)，否则可能 fallback 到旧标准
混合标准引发的隐蔽问题
当项目含多个源文件，部分用 -std=c++20、部分用 -std=c++17 编译时，std::barrier 的 ODR（One Definition Rule）会被破坏：
- 一个 .o 文件里
std::barrier是空壳（因 C++17 下未定义） - 另一个 .o 文件里它是完整实现（C++20 下展开）
- 链接器无法统一，可能随机选一个，导致运行时崩溃或同步失效
- 这种问题在跨模块调用（如 shared library + main）时尤其危险
容易被忽略的 ABI 兼容性陷阱
C++20 引入的同步原语（std::barrier、std::latch、std::semaphore）在不同编译器版本间 ABI 不稳定：
- GCC 12.1 和 GCC 12.2 对
std::barrier内部状态布局做了微调，二进制不兼容 - Clang 14 与 libstdc++ 混用时，若 libstdc++ 来自 GCC 11，则
std::barrier符号名可能不匹配 - 解决方案：确保整个项目（包括所有依赖的静态库、头文件、运行时库）使用同一套工具链版本
最常被跳过的一步：检查你链接的 libstdc++.so 版本是否真支持 C++20 同步设施——有些老旧系统预装的 libstdc++ 虽然标着 “GLIBCXX_3.4.30”，但同步原语是后补的，得用 strings /usr/lib64/libstdc++.so.6 | grep barrier 实锤。
