std::chrono::duration加减不自动检测溢出，行为未定义；小位宽（如int）或高精度（如nanoseconds）类型更易溢出；需手动用numeric_limits边界值预检。
std::chrono::duration 加减是否自动检测溢出
不检测。所有 duration 算术运算（+、-、*= 等）都基于底层整数类型直接运算，无运行时溢出检查。一旦超出 Rep 类型的表示范围（如 int 溢出），行为是未定义的 —— 可能静默回绕、崩溃或产生错误结果。
哪些 duration 类型容易在加减中溢出
小位宽或高精度类型风险更高，尤其在长时间跨度或高频累加场景下：
-
std::chrono::milliseconds用int作Rep时，仅支持 ±24.8 天（INT_MAX / 1000 / 3600 / 24）；换成long long可撑到约 ±292 年 -
std::chrono::nanoseconds即便用long long，也只覆盖 ±292 年；若用int，连 2.15 秒都存不下 -
std::chrono::hours看似安全，但若参与大跨度计算（如“当前时间 + 1000000 小时”），仍可能溢出
手动做溢出检测的实用方法
标准库不提供内置检测，需自己判断。核心思路是：在运算前检查操作数是否会导致结果越界。常用策略：
- 用
std::numeric_limits<Rep>::max()和::min()获取边界值，对Rep做算术比较（注意符号） - 对加法
a + b：若a > 0 && b > 0，检查a > numeric_limits<Rep>::max() - b；若均为负，检查a - 避免直接调用
count()后做裸整数运算 —— 先提取Rep值，再按上述逻辑判断，最后用duration<Rep, Period>(value)构造 - 更稳妥的做法是统一使用
long long作为Rep，例如using my_ms = std::chrono::duration<long long, std::milli>，大幅降低溢出概率
为什么 duration_cast 不触发溢出但可能截断
std::chrono::duration_cast 本身不溢出，但它会向目标精度做向下取整（truncation），且不报错。例如：
立即学习“C++免费学习笔记（深入）”；
auto d = std::chrono::milliseconds(2999); auto s = std::chrono::duration_cast<std::chrono::seconds>(d); // 得到 2s，不是 3s，也不警告
这种“静默截断”在需要向上取整（如超时判断）时很危险。若需进一法则，得手动判断余数：d.count() % 1000 != 0 ? s.count() + 1 : s.count()。真正的溢出风险仍来自原始 duration 的构造或算术，而非 duration_cast。
最易被忽略的是：哪怕你用了 steady_clock::time_point 测间隔，只要中间做了大量 duration 累加（比如统计总耗时），就仍要面对底层 Rep 溢出问题 —— 时钟类型保单调性，不保数值安全。
