libc++ 的特性测试宏（如 __cpp_lib_span）在对应标准头文件（如 <span>）中定义，而非全局或 __config 中；需先 #include 头文件才能检测，且须结合宏定义、语言标准和头文件存在性三重判断。
libc++ 的特性测试宏在哪定义
libc++ 自身提供一组以 __cpp_lib_* 和 _LIBCPP_VERSION 为核心的预处理器宏，它们不是靠编译器自动注入，而是由 libc++ 头文件在首次包含时主动定义。关键点在于：这些宏只在你 #include 了对应头文件之后才可见。
比如 __cpp_lib_span 要等 #include <span> 才被定义；__cpp_lib_format 要等 #include <format> 后才生效。这和 GCC libstdc++ 的行为一致，但和 MSVC STL（部分宏在 version 中提前暴露）略有不同。
常见误判：在没 include 相关头文件前就写 #if defined(__cpp_lib_span) —— 此时它一定未定义，无论 libc++ 版本多新。
如何安全检测 libc++ 是否支持某个 C++20/23 特性
必须结合「头文件存在性 + 特性宏 + 标准语言模式」三重判断，缺一不可。libc++ 不保证某版本“全量实现”一个标准，只保证所声明的特性在对应头文件中可用。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
-
#include <__config>是 libc++ 的配置入口，但它不定义特性宏，仅提供_LIBCPP_VERSION（如19000表示 libc++ 19.0） - 真正检测应写成：
#include <span> #if defined(__cpp_lib_span) && __cpp_lib_span >= 202002L // safe to use std::span #endif
- 注意：不能只靠
_LIBCPP_VERSION >= 18000推断 C++20 支持，因为旧版 libc++ 可能通过补丁添加单个特性（如 17.0.1 加了std::format但未升__cpp_lib_format值）
为什么 __cplusplus 在 libc++ 下仍不可靠
libc++ 遵循标准，把 __cplusplus 设为 202002L 或 202302L，但这只表示“目标标准”，不代表该 libc++ 构建时启用了全部特性。例如：
- 你用 Clang 16 + libc++ 18 编译
-std=c++20，__cplusplus是202002L，但std::mdspan可能根本没实现（libc++ 18 还没加） - Clang 17 默认启用
-fno-cxx-exceptions时，即使 libc++ 19 已支持std::expected，其头文件内部也会禁用相关代码，导致__cpp_lib_expected不被定义 - 某些特性（如
std::print）在 libc++ 中仍标记为实验性，需额外定义_LIBCPP_ENABLE_EXPERIMENTAL_PRINT才会暴露宏
跨编译器检测 libc++ 特性的实际写法
如果你的代码要同时兼容 libc++、libstdc++ 和 MSVC STL，别硬写三套逻辑。用 libc++ 提供的兼容层更稳：
- 优先查标准特性宏：
__cpp_lib_format、__cpp_lib_ranges，它们在三大 STL 中命名一致、语义一致 - 避免依赖
_LIBCPP_VERSION做功能分支，除非你明确知道该版本号与某特性的绑定关系（如_LIBCPP_VERSION >= 19000才有std::generator） - 对 libc++ 独有扩展（如
_LIBCPP_HAS_NO_INCOMPLETE_FORMAT），只在确认defined(_LIBCPP_VERSION)后使用 - 构建系统层面可配合 xmake 或 CMake 的
check_cxx_source_compiles实际编译测试，比纯宏判断更可靠
最易被忽略的一点：libc++ 的特性宏值（如 __cpp_lib_span）反映的是“该特性被标准化的时间”，不是“libc++ 实现它的时间”。202002L 表示 C++20 第二版草案时间，不代表 libc++ 2020 年就实现了它——实际可能晚两年才落地。
