手写简易日志系统只为调试、嵌入式受限或精细控制，核心是实现「能打日志、不崩、不丢行、带时间戳和级别」的最小闭环；接口用可变模板避免类型不安全，锁保护write()而非格式化，时间戳用std::chrono+gmtime保证线程安全，严格检查I/O错误并降级到stderr。
为什么不用现成库而要手写简易日志系统
因为只是调试用、嵌入式资源受限、或想控制输出格式/线程安全粒度。手写不为替代 spdlog 或 glog，而是快速获得「能打日志、不崩、不丢行、带时间戳和级别」的最小闭环。一旦发现需要异步刷盘、按天切文件、动态调级，就该切回成熟库。
核心函数怎么设计：log 接口与线程安全
最简接口就是 log(level, fmt, ...)，但 C++11 后推荐用可变模板避免 vprintf 的类型不安全。关键点在于：多线程下多个线程同时调 log 不能导致输出错乱（比如一条日志的前半截和另一条的后半截混在一起）。
- 用
std::mutex锁住整个写入流程（不是锁格式化，是锁write()调用），简单有效 - 避免在锁内做耗时操作：时间戳用
std::chrono::system_clock::now()获取后立刻转字符串，别在锁里调localtime_r - 不要用
std::endl—— 它强制 flush，性能差；用'\n'即可，让std::ofstream自己缓冲
示例片段：
void log(LogLevel level, const char* fmt, ...) {
va_list args;
va_start(args, fmt);
std::string msg = format_message(level, fmt, args); // 格式化在锁外
va_end(args);
<pre class="brush:php;toolbar:false;">std::lock_guard<:mutex> lock(mtx_);
out_ <p>}</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/gongju/2823" title="C++14"><img
src="https://img.php.cn/upload/manual/001/431/639/6ac8b33c327c4749.png" alt="C++14" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="overflowclass">C++14</a>
<p class="overflowclass">C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。</p>
</div>
<a rel="nofollow" href="/xiazai/gongju/2823" title="C++14" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div></:mutex>时间戳和级别字符串怎么生成才不拖慢主线程
每次日志都实时查系统时间 + 格式化成 "2024-05-22 14:30:22.123" 很快，但频繁调 strftime + gettimeofday 会引入微小延迟。更关键的是，如果用 std::put_time 配 std::localtime，后者在某些 libc 实现中是非 reentrant 的，多线程下可能出错。
- 用
std::chrono::system_clock::now()获取time_point，再用time_t sec = time_point.time_since_epoch().count() / 1e9拆秒和毫秒 - 秒部分用
std::gmtime（线程安全）+std::put_time格式化，再拼接毫秒 - 级别字符串（如 "[INFO]"）直接用
static constexpr数组查表，别 runtime 构造
文件写入失败了怎么办：open 失败、磁盘满、权限不足
日志系统崩溃不是最糟结果，最糟的是静默丢日志还假装成功。必须检查每个 I/O 调用的返回值。
- 构造时
out_.open(path, std::ios::app | std::ios::out)后立刻检查out_.is_open() == false，失败则 fallback 到stderr并记录错误（但别递归调自己） - 每次
out_ 后检查 <code>out_.fail()，若失败（如磁盘满），关闭文件并尝试 reopen；连续失败 3 次则只往stderr写 - 不要用
std::ofstream的异常模式（exceptions(std::ios::failbit | std::ios::badbit)），它会让日志函数意外抛异常，上层很难处理
真正难处理的是日志系统自身依赖的路径被其他进程占用（如 Windows 下文件被记事本打开），这时 open 会失败，得接受“此时无法写文件”这个事实，而不是死等或重试。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
