直接用 time(nullptr) 获取秒级时间戳最简单标准，返回 time_t 类型，线程安全、跨平台、语义清晰；避免用 std::chrono 手动转换易出错。
直接用 time(nullptr) 就行，别绕弯
绝大多数场景下，获取秒级时间戳（即从 1970-01-01 00:00:00 UTC 到现在的秒数）最简单、最标准的方式就是调用 time(nullptr)，返回值类型就是 time_t。它不依赖平台、无需手动转换、线程安全（C++11 起保证），且语义清晰。
常见错误是试图用 std::chrono::system_clock::now() 然后自己除以秒——这反而容易出错：比如忘记用 duration_cast、误用 count() 得到纳秒却当秒用、或在 Windows 上遇到 time_t 是 64 位而某些旧代码假设为 32 位的问题。
示例：
time_t now = time(nullptr); // now 就是秒级时间戳，可直接传给 ctime(), localtime(), mktime() 等
time_t 的实际类型和跨平台注意事项
time_t 是 typedef，不是固定整数类型。POSIX 要求它是算术类型，但 C++ 标准只规定它是能表示时间的实现定义类型。实际中：
立即学习“C++免费学习笔记（深入）”；
- Linux/macOS：通常是
long int（64 位系统上为 64 位） - Windows（MSVC）：默认是 64 位（自 VS2015 起），但旧项目若定义了
_USE_32BIT_TIME_T会退化为 32 位——这会导致 2038 年问题 - 嵌入式或裁剪 libc 环境（如 newlib）：可能为 32 位且无 Y2038 修复
所以如果你要序列化或跨进程传递 time_t，别直接按 int32_t 或 int64_t 解析；稳妥做法是用 static_cast<long long>(t)</long> 或 std::to_string(t) 转成明确宽度的整数或字符串。
需要高精度？别用 time()，改用 std::chrono
time(nullptr) 只保证秒级精度，底层通常调用 gettimeofday() 或 GetSystemTimeAsFileTime()，但 POSIX 规定其分辨率至少为 1 秒（实际常为 1 秒，部分系统可能略高，但不可依赖）。
如果你真正需要毫秒/微秒级时间戳（比如日志打点、性能测量），必须用 std::chrono：
auto now = std::chrono::system_clock::now(); auto secs = std::chrono::duration_cast<std::chrono::seconds>(now.time_since_epoch()).count(); auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(now.time_since_epoch()).count();
注意：secs 和 time(nullptr) 结果一致（误差在 1 秒内），但 ms 是自 epoch 起的毫秒总数，不是“当前秒内的毫秒”。别混淆 time_since_epoch() 和 time_of_day()。
时区陷阱：time_t 本身是 UTC，但显示/解析易出错
time_t 值永远是 UTC 秒数，不带时区信息。但人眼看到的 “2024-06-15 14:30:00” 是本地时区解释结果。常见坑：
- 用
localtime(&t)解析后没检查返回值（可能为nullptr，如时区数据缺失） - 调用
mktime()传入的tm结构体未设tm_isdst = -1，导致夏令时判断失败 - 跨时区同步时，把
localtime输出的字符串当 UTC 存储，造成 8 小时偏差
如果业务逻辑必须处理本地时间，建议统一转成 UTC 时间戳（time_t）存储和传输，仅在展示层做一次 localtime 或 gmtime 转换。
真正要注意的是：time_t 看似简单，但它的隐式时区含义、平台类型差异、以及和 std::chrono 的精度错位，才是日常踩坑主力。别把它当成一个“随便取的整数”。
