装饰器模式在C++异步日志中需避免循环引用、确保线程安全、透传调用：用weak_ptr防反向持有，shared_ptr仅传下游，log方法无锁无等待，统一投递至异步队列；采样须基于trace_id哈希全局一致，而非外层独立采样。
装饰器模式在 C++ 异步日志中间件中不是银弹，但能解耦日志增强逻辑（如采样、脱敏、上下文注入）与核心写入逻辑；关键在于避免 std::shared_ptr 循环引用、确保 async_log 调用链的线程安全，以及让装饰器的 log 方法真正“透传”而非吞掉调用。
如何让装饰器支持异步调用且不阻塞上游
核心是每个装饰器不持有日志后端的同步句柄，只持有 std::shared_ptr<log_backend></log_backend> 并将日志任务投递到统一的异步队列（如 boost::lockfree::queue 或封装好的 thread_pool::post()）。装饰器自身不启动线程，也不做任何耗时操作（比如格式化、文件 I/O）。
- 所有装饰器的
log方法必须是无锁、无等待的：只构造log_entry对象并转发给下游或队列 - 避免在装饰器里调用
std::this_thread::sleep_for或std::mutex::lock()—— 这会污染调用栈，破坏异步语义 - 若需延迟写入（如批量刷盘），应由最底层的
file_backend或专用batching_decorator统一处理，而非每个装饰器各自缓存
层级封装时怎样防止 shared_ptr 循环引用
典型陷阱：装饰器 A 持有 B 的 std::shared_ptr，B 又通过回调或上下文反向持有 A 的 std::shared_ptr，导致引用计数永不归零。日志对象生命周期失控后，程序退出时析构顺序错乱，可能触发 double-free 或 use-after-free。
- 一律使用
std::weak_ptr<log_sink></log_sink>替代反向持有的shared_ptr，尤其在上下文传播（如 trace_id 注入装饰器）中 - 装饰器构造函数只接受
std::shared_ptr类型的下游 sink，禁止提供 setter 或重绑定接口 —— 防止运行时意外形成环 - 用
std::enable_shared_from_this时务必确认 this 指针已由make_shared创建，否则shared_from_this()抛std::bad_weak_ptr
log 方法签名要不要带 std::string_view 和 std::source_location
要，而且必须一致。C++20 的 std::source_location 是低成本获取调用点信息的唯一可行方式；而 std::string_view 避免装饰器层重复拷贝 message 字符串（尤其在多层嵌套时放大开销）。
立即学习“C++免费学习笔记（深入）”；
- 顶层接口统一定义为：
virtual void log(std::string_view msg, std::source_location loc = std::source_location::current()) = 0 - 每个装饰器实现里，先处理自己的逻辑（如添加前缀、过滤、采样判断），再原样传递
msg和loc给下游，不重建source_location - 不要把
loc存进log_entry再序列化 —— 它是编译期常量，应直接展开为file/line/function字段，在格式化阶段使用
为什么采样装饰器不能放在最外层
放在最外层看似高效，实则破坏上下文一致性：比如一个请求链路中，A→B→C 三个服务都用了采样装饰器，各自按 1% 采样，最终只有约 0.0001% 的完整链路被记录，根本无法用于问题定位。
- 采样决策必须基于 trace_id 哈希（如
std::hash<:string_view>{}(trace_id) % 100 ），且在整个链路中复用同一 trace_id</:string_view> - 采样装饰器应紧贴最底层 backend（即倒数第二层），确保所有装饰器（脱敏、上下文注入等）已执行完毕，再决定是否投递
- 若需 per-service 级别开关，用配置项控制装饰器是否启用，而非用采样率模拟“关闭”
真正的难点不在组合多个装饰器，而在确保每层对 log_entry 的修改不可见于上层（比如脱敏装饰器不能改变原始 msg 的内存布局），同时又让下游能拿到完整上下文 —— 这要求 log_entry 必须是值语义、可拷贝、字段松耦合，而不是靠指针共享一块 mutable buffer。
