最可靠方法是先得下月1日00:00:00再减1秒：C++20用year_month_day_last+sys_days，C++17及以下用tm+mktime归一化；必须避免手动设23:59:59，以防时区与夏令时误差。
用 std::chrono 和 std::tm 计算本月最后一秒
直接取“本月最后一秒”的时间戳，不能靠简单加减天数（比如假设每月31天），必须考虑不同月份天数、闰年、时区。C++20 的 std::chrono::year_month_day_last 是最干净的解法；C++11/14/17 则需手动构造 std::tm 并用 mktime 归一化。
关键逻辑是：先得到下月第一天的 00:00:00，再减去 1 秒 —— 这比“找当月最后一天再设 23:59:59”更可靠，避免手动处理时分秒溢出或夏令时跳变。
示例（C++20）：
auto now = std::chrono::system_clock::now();
auto ymd = std::chrono::year_month_day{std::chrono::floor<std::chrono::days>(now)};
auto ym = ymd.year() / ymd.month();
auto last_day = ym / std::chrono::last;
auto last_second = std::chrono::sys_days{last_day} + std::chrono::hours{23} + std::chrono::minutes{59} + std::chrono::seconds{59};
auto timestamp = std::chrono::system_clock::to_time_t(last_second);
C++17 及以下：用 mktime 安全归一化日期
手动填 std::tm 时，月份要填 tm_mon = next_month % 12，年份要进位；填完必须调 mktime，否则 tm_mday 超出范围（如设成 32）不会自动修正，mktime 会把它转成下个月对应日。
立即学习“C++免费学习笔记（深入）”；
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 不要直接设
tm_sec = 59; tm_min = 59; tm_hour = 23;后就调mktime—— 必须先设成下月 1 日 00:00:00，再减 1 秒 -
mktime输入的tm默认按本地时区解释，若需 UTC，请用timegm（POSIX）或手动转时区 - 填
tm_year时别漏掉 +1900，填tm_mon时别漏掉 0-index（1 月是 0）
时区陷阱：为什么 localtime + mktime 不等于恒等变换
mktime 把 struct tm 当作本地时间解析，并应用当前系统的时区规则（含夏令时）；而 localtime 把时间戳转成本地时间，也依赖同一套规则。但如果你在夏令时切换窗口附近操作（例如 10 月最后一个周日凌晨 2 点回拨），两次转换可能不闭合。
更稳的做法：
- 全程用 UTC 时间戳运算（用
timegm替代mktime，用gmtime替代localtime） - 或者明确指定时区（C++20
std::chrono::zoned_time） - 避免在 10 月/3 月最后一个周日凌晨 1–3 点之间做此类计算
跨平台兼容性注意点
timegm 不是标准 C 函数，在 Windows 上需定义 _CRT_SECURE_NO_WARNINGS 并用 _mkgmtime 替代；macOS 和 Linux 原生支持 timegm。
如果必须兼容旧编译器且不用 C++20：
- 用
mktime+localtime组合，但提前用tzset()固定时区（如setenv("TZ", "UTC", 1); tzset();） - 避免依赖
tm_gmtoff字段（GNU 扩展，Windows 不可用） - 测试 2 月 28/29 日、12 月 31 日、闰年 2024 等边界情况
真正容易被忽略的是：系统时区数据库是否更新 —— 某些嵌入式环境或老旧容器镜像的 tzdata 版本太老，会导致 mktime 对历史夏令时规则判断错误，从而让“本月最后一秒”偏移 3600 秒。
