__DATE__ 和 __TIME__ 是编译时固化字符串宏，直接拼接使用即可写入日志；不可加括号调用，需注意时区不一致、空格格式及日志接口类型匹配问题。
编译时间怎么塞进日志——用 __DATE__ 和 __TIME__ 最简方案
直接说结论：__DATE__ 和 __TIME__ 是 C++ 预处理器宏，编译时就固化成字符串字面量，能安全写入日志。但它们不是运行时值，别指望每次启动程序都刷新。
典型错误是试图在日志函数里“调用”它们，比如 log(__DATE__()) —— 这会报错，因为它们不是函数，加括号就语法错误。
- 正确写法就是直接当字符串用：
"Compiled on " __DATE__ " at " __TIME__ - 注意：两个宏之间不能有空格或分号，必须靠拼接（C++ 字符串字面量自动拼接规则）
- 如果日志系统只接受
std::string或const char*，直接传进去就行，无需转换
想让时间格式更统一？小心 __TIME__ 的本地时区陷阱
__TIME__ 输出格式固定为 "HH:MM:SS"，但它的值取决于编译机器的本地时钟，不是 UTC，也不是构建服务器时区设置的结果——它就是编译那一刻系统 date 命令吐出来的本地时间。
常见坑：CI/CD 流水线里不同节点时区不一致，导致日志里出现多个“编译时间”，看似同一版本，时间却差 8 小时。
立即学习“C++免费学习笔记（深入）”；
- 如果需要可重现、跨环境一致的时间戳，不要依赖
__TIME__，改用构建脚本注入（如 CMake 的configure_file+$<code>FORMAT_TIME） - 若坚持用宏，至少确认所有编译机
tzdata和系统时区配置一致（比如全设为UTC） -
__DATE__格式固定为"Mmm DD YYYY"（注意 DD 是带前导空格，不是零填充），解析时得留心空格
写进日志文件的实操要点——别让宏被优化掉或乱码
宏展开后是窄字符字符串（const char[]），只要日志系统没强制转宽字符或做非法 reinterpret_cast，就不会出问题。但真有人遇到日志里显示乱码或空白，往往是因为下面几个原因：
- 日志框架对字符串做了额外编码（比如自动 base64 或 URL encode），需关掉对应选项
- 用了
wchar_t日志接口却传了窄字符串，导致截断或乱码；检查接口签名，匹配const char*版本 - 宏放在条件编译块里，而该块被预处理器跳过（比如
#ifdef DEBUG外围没定义），结果日志里根本没内容 - 示例写法：
LOG_INFO("Startup. Build: " __DATE__ " " __TIME__);——确保LOG_INFO是接受const char*的变参宏或函数
CMake 项目里怎么稳稳拿到编译时间？别硬啃预处理器
纯宏方案在大型工程里容易失控，尤其要支持多平台、交叉编译或构建缓存时。__DATE__ 每次编译都变，可能破坏增量构建或二进制一致性。
更可控的做法是让构建系统生成一个头文件，把时间作为常量注入：
- CMake 中用
string(TIMESTAMP BUILD_TIME "%Y-%m-%d %H:%M:%S" UTC)获取 UTC 时间 - 用
configure_file(build_info.h.in build_info.h)把时间写进头文件 -
build_info.h.in内容示例：#define BUILD_TIMESTAMP "${BUILD_TIME}" - 代码里
#include "build_info.h"，然后用BUILD_TIMESTAMP替代__DATE__和__TIME__ - 这样时间由 CMake 控制，可复现、可测试、可强制 UTC，且不干扰预处理器逻辑
真正难的不是塞时间，是怎么让这个时间在开发、CI、Release 包里语义一致——宏看着快，但一旦涉及协作和发布，构建系统那一层才管得住。
