最安全做法是用C++20的std::chrono::sys_days配合year_month_day：先floor到当日零点，再加days，最后转为年月日字段输出；C++17及更早需用mktime归一化tm结构并注意时区陷阱。
用 std::chrono 加天数最安全
直接对 std::chrono::system_clock::time_point 加 std::chrono::days(100) 是标准且跨平台的做法，避免手算月份天数、闰年、时区偏移等陷阱。C++20 起 <chrono></chrono> 原生支持日历运算，比旧式 tm + mktime 稳定得多。
关键点：
- 必须用
std::chrono::sys_days作为日期中间类型，它把时间点对齐到“午夜 UTC”，才能正确加减天数 - 不能直接对
time_point加days后再转tm——可能因本地时区导致日期偏差一天 - 起始日期建议用
std::chrono::floor<:chrono::days>(tp)</:chrono::days>截断到当日零点，否则毫秒级偏移可能影响结果
#include <chrono>
#include <iostream>
<p>auto today = std::chrono::floor<std::chrono::days>(
std::chrono::system_clock::now()
);
auto later = today + std::chrono::days{100};
std::cout << later.time_since_epoch().count() << "\n"; // 输出自纪元以来的天数
输出为 YYYY-MM-DD 格式要过一道转换
sys_days 本身不提供格式化，得转成 year_month_day 再提取字段。C++20 的 <format> 尚未被所有编译器（如 GCC 12 默认）完全支持，稳妥做法是手动拼接。
常见错误：
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 误用
std::chrono::year_month_day{today}：构造函数接受的是sys_days，不是任意time_point - 忽略
year()返回的是std::chrono::year类型，需调.operator int()或.value()才能打印 - 月份和日直接用
month().operator unsigned()，但更推荐unsigned{md.month()}避免隐式转换警告
auto ymd = std::chrono::year_month_day{later};
std::cout << ymd.year() << "-"
<< std::setfill('0') << std::setw(2) << unsigned{ymd.month()} << "-"
<< std::setw(2) << unsigned{ymd.day()} << "\n";
兼容 C++17 及更早版本怎么办
没有 std::chrono::days 和 year_month_day？别硬套 C++20 接口。老办法是用 std::tm + mktime，但必须注意：加 100 天后要重新归一化，否则 tm_mday 超出范围会导致 mktime 自动进位（这是正确行为，但容易误以为出错）。
实操要点：
- 初始化
tm时设tm_isdst = -1，让系统自动判断夏令时 - 加天数后必须调一次
mktime，它会修正tm_mon、tm_year等字段 - 第二次调
mktime（可选）能处理某些 libc 对首次归一化不彻底的问题，尤其在跨年边界 - 别依赖
tm_wday或tm_yday的初始值——它们在mktime前是未定义的
std::tm t = {};
t.tm_year = 2024 - 1900;
t.tm_mon = 5;
t.tm_mday = 15;
t.tm_hour = 0;
t.tm_isdst = -1;
auto time = mktime(&t);
t.tm_mday += 100;
mktime(&t); // 第一次归一化
mktime(&t); // 保险起见再归一化一次
别忽略时区和夏令时的隐性影响
哪怕你只关心“日期”，system_clock::now() 返回的是 UTC 时间点，而 mktime 解释 tm 时按本地时区处理。如果你在 UTC+8 时区执行 mktime，它会把传入的“2024-06-15 00:00:00”当成本地时间，再转成 UTC 时间戳——这可能导致计算出的“100 天后”在 UTC 时间上差出若干小时，进而影响 year_month_day 判断。
规避方式：
- 全程用
sys_days（C++20）——它基于 UTC 日历，无时区歧义 - 若用
tm，统一用timegm（非标准但广泛支持）替代mktime，它把tm当作 UTC 时间解析 - 绝对不要混用：比如用
localtime解析今天，再用gmtime输出结果
真正麻烦的不是算不准，而是不同机器、不同时区、不同 libc 实现下结果不一致——这点在自动化脚本或服务端逻辑里最容易暴露。
