tai_clock在主流编译器中仍为实验性特性，需编译选项、系统支持及运行时检测三重保障，不可直接使用。GCC需-fconcepts -D_GLIBCXX_USE_TAI_CLOCK且glibc≥2.37；Clang/MSVC未实现；内核需≥5.11并支持CLOCK_TAI；TAI-UTC偏移须动态获取，不可硬编码。
std::chrono::tai_clock 在当前主流编译器（GCC 13/Clang 16/MSVC 19.38）中仍处于实验性支持状态，且不保证跨平台行为一致——它不是“开箱即用”的标准时钟，而是一个尚未稳定、依赖系统底层 TAI 支持的可选扩展。
为什么 tai_clock 编译不过或返回 time_since_epoch() 为零？
常见错误现象：error: 'tai_clock' is not a member of 'std::chrono'，或调用 tai_clock::now() 后得到一个看似合理的 time_point，但转换为秒后始终是 0 或极小值。
- GCC 需显式启用：必须加编译选项
-std=c++20 -fconcepts -D_GLIBCXX_USE_TAI_CLOCK（仅 GCC 13+，且 glibc 版本需 ≥ 2.37） - Clang 目前（16/17）未实现该时钟，即使加
-std=c++20也无定义 - MSVC 完全未提供
tai_clock符号，__cpp_lib_chrono宏值也不包含对应特性 - 即使编译通过，若内核或 C 库不暴露
CLOCK_TAI（Linux 5.11+ 才正式支持），tai_clock::now()会 fallback 到system_clock或直接失败
如何安全检测并使用 tai_clock？
不能依赖 __cpp_lib_chrono，它不区分是否含 tai_clock；必须运行时探测 + 编译期 guard。
- 先检查宏：
#ifdef __GLIBC_PREREQ且__GLIBC_PREREQ(2,37)，再确认defined(_GNU_SOURCE) - 运行时验证：调用
clock_gettime(CLOCK_TAI, &ts)，检查返回值与errno（ENOSYS表示内核不支持） - 若不可用，应降级到
system_clock+ 已知 TAI-UTC 偏移表（如 IERS 发布的闰秒文件），而非硬链接tai_clock - 注意：即使可用，
tai_clock::time_point的period是纳秒，但底层精度取决于CLOCK_TAI实现，实测在某些 ARM64 服务器上仍只有微秒级抖动
tai_clock 和 utc_clock、system_clock 的偏移不是常量
很多人误以为 “TAI = UTC + 37 秒” 可以写死，这是危险的。TAI-UTC 偏移随闰秒增加而累加，且 utc_clock（C++20）本身也依赖系统时区数据库和闰秒表。
立即学习“C++免费学习笔记（深入）”；
-
tai_clock::now()返回的是纯原子时计数，不含任何跳变；utc_clock::now()则模拟了真实 UTC 跳秒行为 - 两者差值理论上等于当前 TAI-UTC 偏移，但该值需从系统获取（如读
/usr/share/zoneinfo/leap-seconds.list），不能硬编码 - 跨进程或长时间运行服务中，若未定期刷新闰秒表，用
tai_clock算出的 UTC 时间可能偏差整秒 - 示例验证方式：
auto t1 = tai_clock::now();<br>auto u1 = utc_clock::now();<br>auto delta = t1 - u1; // 此 delta 是 time_point 差，需 .count() 并换算为秒
真正用好 tai_clock 的关键不在语法，而在确认你的整个软件栈（内核 → C 库 → 编译器 → 运行环境）都对 TAI 有端到端支持；否则，它只是一个名字漂亮、行为不确定的符号。
