用std::chrono::system_clock加duration获取未来时间点，应直接对time_point加时长，避免手动处理time_t或tm；需注意时区转换、线程安全及时钟选择（system_clock用于日历时间，steady_clock用于耗时测量）。
用 std::chrono::system_clock 加 std::chrono::minutes(5) 得到未来时间点
核心就是把当前时间点和一个时长相加，system_clock::now() 返回的是 time_point，它支持直接 + duration。别用 time_t 或 tm 手动加秒数，容易出错且不跨平台。
实操建议：
- 始终用
std::chrono::system_clock::now()获取当前时间点，不是steady_clock（后者不映射到日历时间） -
std::chrono::minutes(5)是最直观的写法；也可以写5min（C++14 起支持字面量，需#include <chrono>并用using namespace std::literals） - 如果后续要转成可读字符串或
time_t，再调用system_clock::to_time_t()，不要提前转
转成 time_t 和本地时间字符串时注意时区
system_clock 的时间点是 UTC 基准，但 std::localtime 会按系统时区转换 —— 这不是 bug，是设计如此。如果你期望“5 分钟后”在本地时间上显示正确，这步没问题；但若服务部署在 UTC 服务器而前端要展示用户本地时间，就得额外处理时区偏移。
常见错误现象：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 直接对
time_t调用localtime却没考虑夏令时切换，导致显示差 1 小时 - 用
gmtime转成 UTC 时间后又用strftime格式化，结果比预期早 8 小时（比如东八区场景） - 没检查
localtime返回值是否为nullptr（线程不安全版本在某些平台可能失败）
需要高精度或避免时钟跳变？慎用 system_clock
如果业务逻辑依赖“真实流逝时间”（比如超时控制、心跳间隔），system_clock 可能被 NTP 调整或手动修改，造成时间点倒流或跳跃。这时应优先考虑 steady_clock，但它不能直接表示日历时间。
使用场景判断：
- 定时任务触发、日志打点、缓存过期 —— 用
system_clock，因为它对应真实世界时间 - 函数执行耗时测量、重试间隔、防抖等待 —— 用
steady_clock，抗系统时间扰动 - 想兼顾两者？可以记录
system_clock::now()作为起始点，再用steady_clock测相对耗时，但别混着加减
完整可运行示例（C++17）
#include <chrono>
#include <iostream>
#include <ctime>
int main() {
auto now = std::chrono::system_clock::now();
auto later = now + 5min; // 或 std::chrono::minutes(5)
std::time_t t = std::chrono::system_clock::to_time_t(later);
std::cout << "5 minutes later: "
<< std::put_time(std::localtime(&t), "%Y-%m-%d %H:%M:%S")
<< "\n";
}
注意：std::put_time 和 std::localtime 都不是线程安全的；生产环境若多线程并发调用，得加锁或改用 localtime_r（POSIX）或 _localtime64_s（MSVC）。
最容易被忽略的是：即使你只算时间点，只要涉及 localtime/gmtime 和格式化，就绕不开 C 运行时的时区状态（tzset()）、线程安全性和平台差异。别假设“跑通了就 OK”。
