同一时钟类型的time_point可直接用<、>等比较，无需转duration；不同类时钟（如system_clock与steady_clock）不可比，因语义隔离；跨时钟需统一转换；steady_clock适合超时控制，system_clock受系统时间调整影响。
直接用 <、> 比较就行
只要两个 time_point 是同一时钟类型（比如都是 std::chrono::system_clock::time_point），就能直接用关系运算符比较，不需要转成 duration 或秒数。C++ 标准库已为 time_point 重载了全部六种比较操作符。
常见错误是试图用 .time_since_epoch().count() 手动比大小——这不仅多此一举，还可能因整数溢出或精度丢失出错（尤其用 microseconds 等高精度单位时）。
-
t1 < t2返回true表示t1更早 - 支持
==、!=、<=、>=、>全部运算符 - 不同模板参数的
time_point（如不同duration）仍可比较，编译器会自动做隐式转换
注意时钟类型必须一致才能安全比较
不同类时钟（如 system_clock 和 steady_clock）的 time_point 类型不兼容，强行比较会编译失败。这不是设计缺陷，而是语义隔离：一个表示墙上时间，一个表示单调递增的运行时长，二者无公共零点，无法直接比先后。
典型报错信息类似：no match for 'operator<' (operand types are 'std::chrono::steady_clock::time_point' and 'std::chrono::system_clock::time_point')
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 若需跨时钟判断，必须先统一到某个时钟（例如用
system_clock::to_time_t()转成time_t，但会丢失亚秒精度） -
high_resolution_clock是别名，实际可能等价于前两者之一，不能假设它和别的时钟可比 - 自定义时钟需显式提供
is_steady和now()，否则无法参与标准比较逻辑
比较结果受系统时钟跳变影响
用 system_clock 的 time_point 比较时，如果系统时间被手动调整（如 NTP 同步导致回拨或快进），t1 < t2 的结果可能违反直觉：一个“更晚”获取的 time_point 反而比之前的小。
这是 system_clock 的固有行为，不是 bug。如果你需要绝对单调的顺序（比如日志排序、超时控制），应改用 steady_clock。
-
steady_clock不受系统时间修改影响，适合测间隔、设超时 - 但
steady_clock::time_point无法直接对应到年月日，打印或调试时需转成相对值（如.time_since_epoch().count()） - 某些嵌入式平台的
steady_clock分辨率较低，需实测确认是否满足需求
避免隐式转换带来的精度截断
当两个 time_point 使用不同 duration 类型（如一个是 milliseconds，另一个是 nanoseconds），比较时会触发隐式转换，目标类型由模板参数推导规则决定，通常转为更高精度的类型。但若显式用了 auto 接收 time_since_epoch()，就可能意外丢失精度。
例如：auto d = tp.time_since_epoch(); 在 tp 是 nanoseconds 时可能推导为 nanoseconds，但若后续赋值给 milliseconds 变量，就会静默截断。
- 比较本身安全，但取
count()做其他计算前，务必确认duration类型 - 用
decltype(tp.time_since_epoch())::rep查原始计数值类型，避免依赖auto - 跨线程传递
time_point时，确保所有地方用相同时钟和 duration，否则容易出现“看起来相等却比较不等”的情况
真正麻烦的从来不是怎么比，而是没想清楚该用哪个时钟、在什么上下文里比——尤其是混用 system_clock 和 steady_clock 时，编译器拦得住类型错误，拦不住语义错误。
