日志后端必须用虚函数实现LoggerBackend接口，禁止模板继承；需用shared_ptr管理生命周期以安全切换；write()不得阻塞或格式化，序列化由前端完成。
日志后端抽象必须用虚函数，别用模板
直接继承 LoggerBackend 接口并实现 write() 是最稳妥的路径。模板方案看似灵活，但会导致每个后端生成独立符号，无法在运行时切换；更麻烦的是，不同模板实例之间无法统一管理（比如同时启用文件 + 网络后端）。虚函数表开销可忽略，且支持多态注册、动态替换。
常见错误：把 write() 设为非虚，或用 std::function 包一层再塞进类里——这会让日志调用链变长，还容易因捕获导致生命周期问题。
-
LoggerBackend基类至少含纯虚函数：virtual void write(const char* data, size_t len) = 0; - 所有子类（
ConsoleBackend、FileBackend、TcpBackend）必须 overridewrite() - 避免在
write()内做阻塞 I/O（如未设超时的send()），否则卡住整个日志线程
如何安全地在运行时切换后端？别直接 delete 指针
切换后端不是“删旧换新”那么简单。旧后端可能还在处理缓冲区、持有文件句柄、或正被另一个线程调用 write()。粗暴 delete old_backend; 极易触发 use-after-free 或崩溃。
正确做法是引入引用计数 + 异步清理：让日志分发器（Logger 类）持有一个 std::shared_ptr<loggerbackend></loggerbackend>，所有日志写入都通过该智能指针调用 write()；切换时只更新这个指针，旧对象会在所有 pending 调用结束后自动析构。
立即学习“C++免费学习笔记（深入）”；
- 切勿暴露裸指针给用户或跨模块传递
- 如果后端内部有异步队列（如网络发送用单独线程），需在析构前调用
shutdown()并等待队列清空 - 文件后端切换时，确保
fclose()或close()成功后再释放对象，否则可能丢最后几条日志
控制台/文件/网络三者的 write() 实现差异在哪？
表面都是“把字节写出去”，但底层行为天差地别：控制台依赖 write(STDOUT_FILENO, ...) 或 fputs()；文件要处理 fwrite() + 缓冲策略 + 自动 rollover；网络则涉及 socket 连接状态、重连逻辑、粘包处理。不能共用同一套写入逻辑。
典型坑：用 std::cout 写控制台后端——它带全局锁，高并发下严重拖慢；用 fprintf(stderr, "%s", data) 更轻量；文件后端若每次 write() 都 fseek() 到末尾，性能会崩；网络后端若没检查 send() 返回值是否等于 len，会静默丢数据。
- 控制台：
write(STDOUT_FILENO, data, len)，不加锁，不格式化 - 文件：
fwrite(data, 1, len, m_file)，配合setvbuf(m_file, nullptr, _IOFBF, 64*1024)开大缓冲 - 网络：先检查
m_socket != -1和send(m_socket, data, len, MSG_NOSIGNAL)是否返回len，否则标记断连并触发重连
为什么日志消息要先序列化再交给后端？
因为后端只负责“输出”，不该承担格式化责任。如果让每个后端自己解析 level、timestamp、thread_id，不仅重复造轮子，还会导致控制台输出带颜色而文件里全是 ANSI 转义符，网络传输时又得额外过滤。
正确流程是：日志前端（Logger::log()）把结构化字段（时间戳、等级、消息体等）组装成一条定长/自描述的二进制或文本行（如 "[2024-05-20T14:22:33.123][ERR][tid=1234] connect failed\n"），然后统一传给后端的 write()。这样控制台可原样打印，文件直接追加，网络也只需转发字节流。
- 避免在
write()内做strftime()或std::to_string()—— 这些操作可能分配内存，违反日志“低开销”原则 - 若需结构化输出（如 JSON），应在前端序列化完成，而非让后端二次转换
- 网络后端尤其要注意：不要在
write()中对每条日志做 base64 编码——应由前端决定是否编码，并传入已编码后的data
事情说清了就结束。真正难的不是写三个后端，而是让它们在高并发、异常断网、磁盘满、进程信号中断这些边界下都不丢日志、不崩主线程——这些细节全藏在 write() 的实现里，而不是接口设计上。
