直接用 std::async 包日志会出竞态，因装饰器若含共享状态且被多线程并发调用 log()，易致数据错乱；应无状态化装饰器、统一重载 write()、用 shared_ptr 管理生命周期、限流等耗时操作须下沉至异步线程执行。
为什么直接用 std::async 包日志会出竞态？
因为日志写入本身不是线程安全的——哪怕你用 std::mutex 锁住文件句柄，std::async 默认启动的 std::launch::async 策略仍可能让多个日志任务在不同线程里并发调用同一装饰器实例的 log() 成员函数，而装饰器对象若持有共享状态（比如缓冲区、计数器、格式化器），就极易出现数据错乱或析构未定义行为。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 所有装饰器类必须是无状态的（stateless），或确保每个实例只被一个线程持有；更稳妥的做法是把状态下沉到最底层的
FileSink或BufferedSink，上层装饰器只做纯转发+逻辑增强 - 避免在装饰器构造时捕获
this传给std::async，改用值语义包装：例如std::async(std::launch::async, [msg = std::move(msg), sink = this->next_]() mutable { sink->write(msg); }); - 别依赖
std::async的返回值std::future去“等日志写完”——这会阻塞调用方，违背异步中间件本意；真正需要同步的场景应由上层业务显式调用flush()
AsyncDecorator 必须重载 write() 而非 log()
很多初学者试图在装饰器里重写 log() 并在里面调用 std::async，结果发现日志顺序错乱、部分消息丢失。根本原因是：日志接口契约通常约定 log() 是入口门面，而 write() 才是实际落盘动作——只有统一拦截 write()，才能确保所有路径（包括 error()、warn()、info()）都走异步链路。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 基类定义纯虚函数
virtual void write(const std::string& msg) = 0;，所有装饰器（AsyncDecorator、LevelFilterDecorator、JsonFormatDecorator）都只重载write() -
AsyncDecorator的write()内部不做任何格式化或过滤，只负责提交任务：pool_.enqueue([msg = std::move(msg), next = next_]() { next->write(msg); }); - 如果使用第三方线程池（如
thread_pool库），确认其enqueue()是无锁且支持移动语义的；否则自己封装一层std::queue<:function>> + std::mutex</:function>会引入额外延迟
多层级链式封装时，next_ 指针生命周期怎么管？
典型错误是把装饰器栈建在栈上：FileSink file; AsyncDecorator async{file}; LevelFilterDecorator filter{async};——一旦 async 析构，filter.next_ 就变成悬垂指针，后续调用直接崩溃。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 强制要求所有装饰器接受
std::shared_ptr<sink></sink>构造，而非裸指针或引用：AsyncDecorator(std::shared_ptr<sink> next)</sink> - 顶层构建用
std::make_shared链式创建：auto logger = std::make_shared<jsonformatdecorator>(std::make_shared<levelfilterdecorator>(std::make_shared<asyncdecorator>(std::make_shared<filesink>("app.log"))));</filesink></asyncdecorator></levelfilterdecorator></jsonformatdecorator> - 避免循环引用：装饰器内部不持有对自身链的反向引用（例如不要在
AsyncDecorator里存std::weak_ptr<asyncdecorator></asyncdecorator>）；若需回调（如失败重试），用外部注入的std::function替代
异步日志链里加 RateLimitDecorator 为什么反而卡主线程？
因为限流逻辑（比如令牌桶）若放在 write() 入口同步判断，每次日志都要查时间戳、更新计数器、可能 sleep——这等于把异步链的第一跳又拖回同步路径。用户感知就是“开了异步，但 UI 还是卡”。
实操建议：
立即学习“C++免费学习笔记（深入）”；
- 限流必须下沉到真正执行写入的底层 Sink（如
FileSink），或者作为独立的前置队列控制器（RateLimitedQueue），在AsyncDecorator提交任务前做批处理丢弃 - 推荐方案：在
AsyncDecorator和next_之间插入BatchingSink，它缓存 N 条日志再批量提交，此时限流可基于 batch 数量或时间窗口做，避免每条日志都判断 - 切记：任何带锁、sleep、系统调用的操作，都不能出现在装饰器的
write()同步路径中；它们必须被推到异步线程里执行，哪怕多一次内存拷贝
链越长，各层职责越要割清楚：格式化不管线程，过滤不管限流，异步不管落盘——漏掉任意一环，所谓的“多层级链式封装”就会退化成一堆互相拖累的耦合体。
