适配器模式在老旧日志框架切换中的核心作用是“桥接”，即新系统按新接口调用、底层复用旧逻辑，不修改原有日志类代码；因其规避重写风险、符合开闭原则、支持灵活转换与灰度切换。
适配器模式在老旧日志框架切换中，核心作用不是替换，而是“桥接”——让新系统按新接口调用，底层仍跑老逻辑，全程不改原有日志类代码。
为什么必须用适配器？
直接重写旧日志类风险高：可能牵扯大量业务代码、破坏稳定性、违反开闭原则。而适配器只新增一层薄薄的转换逻辑，既复用全部旧实现，又满足新接口契约。
- 旧日志类（如 LegacyLogger）已有成熟逻辑，但方法名是
logMessage(String) - 新系统统一依赖 ILogger 接口，要求方法名为
writeLog(String) - 两者签名、命名、甚至日志级别语义都不一致，硬对接会引发编译错误或运行时异常
对象适配器是首选实现方式
Java 不支持多继承，类适配器受限；对象适配器通过组合持有旧实例，灵活、安全、易测试，也符合“合成复用优于继承”原则。
- 适配器类（如 LoggerAdapter）实现目标接口
ILogger - 内部持有一个
LegacyLogger实例，在writeLog()中委托调用其logMessage() - 若需映射不同日志级别（如 error → warn），可在适配器里做轻量转换，不侵入旧类
真实场景：MyBatis 的日志兼容策略
MyBatis 自定义 org.apache.ibatis.logging.Log 接口，却能无缝接入 Log4j、SLF4J、JDK Logging 等——靠的就是一整套适配器：
- 每个第三方日志框架对应一个适配器类（如
Log4jImpl、Slf4jImpl） - 这些类都实现 MyBatis 的
Log接口，并在内部包装对应框架的Logger实例 - 启动时通过
LogFactory自动探测并加载匹配的适配器，对业务层完全透明
切换过程关键点
真正落地时，重点不在写代码，而在控制范围和验证路径：
- 先定义清晰的目标接口（如
ILogger），明确方法签名与行为契约 - 适配器构造函数接收旧日志实例，避免静态单例耦合，便于单元测试
- 上线前用相同输入对比新旧日志输出（时间戳、格式、内容），确认无信息丢失或错位
- 保留旧日志类的 jar 包依赖，仅新增适配器模块，做到灰度切换、随时回滚
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
