compat_glog：给日志引擎做一层熟悉的调用界面

为什么需要一层 glog 风格兼容接口

底层日志引擎设计得再清楚，调用端如果每次都要手工构造 LogMessage、绑定 route key、决定 flush 时机，接入成本还是会偏高。

这也是 compat_glog 这一层存在的原因。它并不是要完整复刻 glog，而是给 seastar-log-engine 提供一套更熟悉的使用方式，让调用端可以写出类似下面的代码：

LOG_INFO << "Processing request: " << request_id;
LOG_WARNING_R("user-service") << "slow path";

换句话说，这一层主要解决的是"怎么把底层能力接进已有开发习惯"，而不是重新发明日志语法。

当前头文件 include/log_engine/compat_glog.hh 暴露的核心接口并不多：

再加上一组宏：

这个 API 面说明它的目标很明确：不是做完整日志框架，而是做一层薄兼容。真正的写入能力仍然来自 LogEngine，兼容层只负责把"熟悉的写法"翻译成引擎能消费的消息。

Rendering diagram...

compat_glog 里最关键的对象是 LogLine。它会在构造时记录必要元数据，例如：

调用端通过 .stream() 把内容写进去，最后再由 send() 把这条日志提交出去。

这种 RAII 风格的好处，是调用端仍然可以保留常见的流式拼接习惯，而兼容层内部可以在对象生命周期结束时统一完成消息封装。对使用者来说，接口是熟悉的；对引擎来说，输入边界是稳定的。

Rendering diagram...

从实现思路看，这一层并没有偷偷把写入逻辑复制一遍，而是尽量维持单一出口。

LogLine::send() 最终会把消息转成引擎能接受的形式；在需要时，flush() 负责把暂存内容继续推进到底层写路径。这样一来，compat 层只是入口适配器，不是第二套 writer。

这种边界划分很重要。很多"兼容层"最后会慢慢膨胀成真正的中间层，既持有自己的缓冲，又定义自己的语义，最终和底层实现发生漂移。compat_glog 当前没有走这条路线，而是保持对 LogEngine 的依附关系。

compat 层内部需要一个已绑定的 LogEngine 才能正常工作。也就是说，这套接口默认是在应用已经初始化日志引擎之后使用，而不是一个独立自治的全局组件。

典型用法大致是：

这也解释了为什么接口里会有 is_initialized()。兼容层不是无状态宏包装，它有自己的绑定前提和生命周期边界。

LOG_INFO_R(route_key) 这组宏的存在，不只是多提供几个名字，而是把底层最重要的路由语义明确带到了调用面上。

如果没有 route key，兼容层当然也能提交日志；但一旦业务本身就有用户、租户、流或会话这类天然分片维度，把 route key 直接暴露在日志调用口上，会比事后在别处拼装元数据更自然。

这说明 compat_glog 并没有为了"像 glog"而把底层特色抹平。相反，它保留了最关键的 shard 路由入口，让兼容层仍然服务于日志引擎自己的设计目标。

兼容层还承担一个很现实的职责：当日志引擎还没绑定、提交失败，或者当前环境不满足正常写入前提时，需要有一个保底输出路径。

这里回退到 stderr 的价值，不在于把它当成正式存储，而是在最差情况下仍然保留基本可见性。对于启动早期、异常路径或引擎不可用阶段来说，这种退路比"静默丢日志"要合理得多。

从工程角度看，这是一种很朴素但有效的降级策略。兼容层并没有承诺永远可靠写入，但它至少保证调用端在异常条件下不会完全失声。

如果你的应用已经习惯用流式日志宏，或者希望低成本把现有代码迁移到 seastar-log-engine 上，compat_glog 这一层很有意义。它降低的是接入摩擦，而不是重写底层能力。

但反过来看，它也不是新的核心抽象。真正的吞吐、持久化、路由和恢复保证仍然都来自 LogEngine、AsyncWriter 与 AppendWriter。compat 只是把这些能力包装成更容易落地的调用形式。

compat_glog 的设计比较克制，也因此比较健康。它没有把自己做成一个独立日志系统，而是安静地站在引擎前面，提供熟悉的流式语法、显式的 route key 入口，以及必要时回退到 stderr 的保底行为。

对技术组件来说，这类兼容层最怕的是越做越重，最后和底层实现脱节。当前这份实现没有这个问题，它更像一块接线板：不改变底层电路，只让接入方式顺手很多。