最可靠方式是std::chrono::system_clock::now()配合duration_cast，得到自1970-01-01 utc起的微秒整数；避免使用time_t、high_resolution_clock或windows filetime。
用 std::chrono::system_clock 获取微秒级绝对时间（UTC）
标准库最可靠的方式是 std::chrono::system_clock，它返回自纪元（1970-01-01 00:00:00 UTC）起的绝对时间，精度由实现决定，但主流平台（Linux/macOS/MSVC）均支持微秒级或更高。
关键点：不能直接用 time_t 或 std::time()，它们只到秒；也不能依赖 std::chrono::high_resolution_clock，它不保证是绝对时间（可能为单调时钟）。
-
system_clock::now()返回time_point，需转换为微秒单位再转成整数 - 推荐用
duration_cast<:chrono::microseconds></:chrono::microseconds>，避免浮点误差 - 转换后调用
.count()得到long long类型的微秒数
auto now = std::chrono::system_clock::now();
auto us = std::chrono::duration_cast<:chrono::microseconds>(
now.time_since_epoch()).count();
// us 是自 1970-01-01 00:00:00 UTC 起的微秒数
</:chrono::microseconds>
Windows 下 GetSystemTimeAsFileTime 的坑
Windows API 提供 GetSystemTimeAsFileTime，返回 FILETIME（100 纳秒为单位），看似更精细，但容易误用：
- FILETIME 是自 1601-01-01 起的 100 纳秒数，不是 Unix 纪元，直接减 116444736000000000LL 再除 10 才得微秒 —— 容易算错常量
- 该函数不线程安全？不，它是安全的；但若在多线程中频繁调用且未考虑时钟跃变（如 NTP 校正），结果可能跳变
- 跨平台代码中混用此 API 会破坏可移植性，除非明确限定 Windows-only 场景
除非你已在做底层系统编程、且需要和 Windows 事件日志或注册表时间对齐，否则优先用 std::chrono::system_clock。
注意时区与字符串格式化不是“绝对时间”的一部分
获取微秒级绝对时间 ≠ 获取带时区的可读字符串。常见误区是立刻调用 std::put_time 或 strftime：
-
system_clock::to_time_t()丢弃微秒，只保留秒级部分 - 想输出 “2024-05-22 14:35:22.123456” 这种格式，必须手动拆解
time_point：先转time_t得秒，再用duration_cast<microseconds></microseconds>取余数 - C++20
<chrono></chrono>的zoned_time和format可简化，但 C++11/14/17 无原生支持，别强求一行搞定
性能与精度的实际表现
微秒级“绝对时间”在不同场景下意义不同：
- Linux 上
clock_gettime(CLOCK_REALTIME, ...)通常能稳定提供微秒甚至亚微秒精度，system_clock底层往往就调它 - macOS 的
system_clock基于mach_absolute_time+ 偏移换算，实测分辨率约 1 微秒，但抖动略大 - Windows 的
QueryPerformanceCounter精度高，但不是绝对时间；GetSystemTimeAsFileTime理论上每 15.6ms 更新一次（取决于硬件），实际调用频率过高反而可能返回重复值 - 如果你只是做日志打点或超时判断，微秒值本身是否“绝对精确”不如“单调递增+跨进程可比”重要 —— 此时应考虑
steady_clock，而非system_clock
真正难的是在高并发下确保两次 system_clock::now() 调用不因系统时钟回拨或 NTP 调整而倒流，这没法靠单次调用规避，得靠业务层加逻辑判断或改用单调时钟做相对测量。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
