asyncappender并非真正异步，因其仅将日志提交至内存队列，仍依赖单个后台线程消费；队列默认大小仅256、满时若neverblock=false会阻塞业务线程，且includecallerdata=true会因栈帧解析拖慢性能。
为什么直接用 AsyncAppender 不等于真正异步
很多人以为给 Logback 配一个 AsyncAppender 就万事大吉，结果压测时发现日志吞吐没提升、甚至 GC 反而变多。根本原因是：AsyncAppender 只是把日志事件提交到内存队列，但后续仍依赖单个后台线程消费；如果日志格式复杂（比如含 Throwable 堆栈）、或队列满后默认策略是丢弃（DiscardingThreshold），实际会丢失日志或阻塞业务线程。
-
AsyncAppender的queueSize默认仅 256，高并发下极易打满 - 队列满时，
neverBlock=false（默认）会导致业务线程阻塞在put()上，和同步日志无异 -
includeCallerData=true会显著拖慢性能，因为要解析栈帧，生产环境必须关掉
如何配置 AsyncAppender 让它不拖累主线程
关键不是“加不加”，而是“怎么加”。重点控制队列行为、拒绝策略和资源隔离：
- 显式设置
queueSize至少 1024（根据日志峰值 QPS × 平均处理延迟估算） - 设
neverBlock=true：队列满时直接丢弃日志，避免阻塞业务线程（宁可丢日志，不可卡服务） - 关闭
includeCallerData和discardingThreshold（后者在neverBlock=true下无效） - 绑定独立的
Appender（如RollingFileAppender），不要复用其他 appender 的 encoder 或 filter
<appender name="ASYNC_FILE" class="ch.qos.logback.classic.AsyncAppender"><appender-ref ref="FILE"></appender-ref><queuesize>2048</queuesize><neverblock>true</neverblock><includecallerdata>false</includecallerdata></appender>
异步日志中 MDC 为什么会丢失
MDC 是基于 ThreadLocal 的，而 AsyncAppender 的消费线程和业务线程不是同一个。典型现象是：日志里看不到 traceId、userId 等上下文字段。
- 必须在日志事件创建前，调用
MDC.getCopyOfContextMap()把当前上下文快照存入LoggingEvent - Logback 1.3+ 自动支持（需确保使用
logback-classic≥ 1.3.0）；旧版本需自定义LoggingEvent包装器或改用log4j-to-slf4j桥接层做兼容 - 若用 Spring Boot，检查是否启用了
spring.sleuth.log.slf4j.enabled=true（Sleuth 3.x 后已默认集成 MDC 透传）
要不要用 logback-kafka-appender 替代文件异步
当单机磁盘 I/O 成瓶颈、或需要集中分析时，Kafka 方案才有意义。但它引入新问题：网络抖动导致日志堆积、序列化开销、消费者端可靠性保障。
- Kafka appender 本身仍是同步发送（除非封装成批量异步 producer），不能直接替代
AsyncAppender - 更稳妥的做法是：本地用
AsyncAppender + RollingFileAppender写磁盘，再用filebeat或fluentd异步采集发 Kafka - 如果硬要用
logback-kafka-appender，务必设置producerConfig中的retries=2147483647和acks=all，并监控kafka.producer.error指标
真正难的不是配对异步开关，而是理解日志生命周期里哪一环在阻塞、谁持有上下文、以及丢日志时你能否接受——这些决定了 queueSize、neverBlock 和 MDC 处理方式的实际取值。
