C++适配器模式实战：从接口转换到STL隐藏设计思想

适配器模式是我在每个C++项目里几乎都会碰到的设计模式。它不复杂，但非常实用，尤其当你需要把第三方库、旧模块或者不同团队写的接口拼到一起时，适配器能省下大量改调用方的功夫。这篇文章我会结合自己踩过的坑，把C++里适配器模式的两种主流实现、真实场景案例、STL里隐藏的适配器思想，以及面试中常被问到的点一次讲透。不管你是刚学C++的设计模式，还是准备面试看八股文，或者正在改造遗留代码，都能从这里找到直接能用的思路。

学习适配器模式最忌讳的是停留在UML类图层面。类图看懂了，一写代码还是不知道基类该定义成什么样、继承该用公有还是私有、参数该传引用还是传值。所以这篇文章我不会只画概念图，我会直接给你完整的C++代码、编译运行步骤，再告诉你为什么这么写，以及哪些写法在真实工程里容易翻车。

1. 适配器模式到底在解决什么问题

1.1 从插头转换器说起

适配器模式的核心意图一句话就能概括：把一个类的接口转换成客户端期望的另一个接口，让原本因为接口不兼容而无法协作的类可以一起工作。

你每天都会用到这个模式。你从国内带一个两脚插头的笔记本充电器，到酒店发现墙上的插座是三孔的，你怎么办？你不需要拆开充电器改线路，也不需要把墙上的插座砸了重装，你只需要一个几块钱的转换插头。这个转换插头就是适配器：它的一端适配三孔插座，另一端适配你的两脚插头，中间的转换逻辑对两端都是透明的。

C++里的适配器模式就是同样的道理。你有一段遗留系统，日志类叫LegacyLogger，接口是void WriteLine(const std::string&)。你们组引入了新框架，框架里定义的日志接口是void Log(LogLevel level, const std::string& message)。这时候你不想为了框架去改遗留系统里上百处WriteLine调用，也不想为了遗留系统去改框架的接口定义，你就在中间加一个适配器类：

class FrameworkLogAdapter : public IFrameworkLogger { public: void Log(LogLevel level, const std::string& message) override { std::string formatted = "[" + levelToString(level) + "] " + message; legacy_.WriteLine(formatted); } private: LegacyLogger legacy_; };

看到没有，框架拿着它的IFrameworkLogger接口指针，根本不知道底层是一个老掉牙的遗留类。遗留类也毫不知情，它只知道自己被调用了一个WriteLine。这就是适配器的价值：两端解耦，中间转换。

1.2 什么时候该用适配器，什么时候不该用

很多人学设计模式容易犯一个毛病：觉得模式越多越好，见到接口对不上就上适配器。这其实是个坑。适配器适合下面这些场景：

• 想复用现有类，但它的接口和当前系统期望的接口不一致，且接口短期内不打算改。
• 想在多个有相似功能但接口不同的库之间做切换。比如日志库，你希望代码里统一调用自己定义的接口，底层今天可以接spdlog，明天可以换成log4cplus。
• 测试驱动开发中，给外部依赖打桩。你定义了一个统一的存储接口，用适配器把真实存储库包进来，测试时再换个内存实现的适配器。

不该用适配器的场景也很明显。如果接口原本就是你们自己维护的，且改动成本可控，直接改接口往往比加适配器更干净；如果调用方和实现方之间只是参数顺序不同，优先考虑加默认参数或者写一个轻量重载函数，不要为了“用模式”而用模式。另外，适配器嵌套多层以后，调用链会非常难追踪，遇到bug时你在调试器里翻一层又一层，非常痛苦。后面我会专门讲这个坑。

还有一个容易混淆的点：适配器模式和装饰器模式区别在哪。两者在代码结构上很相似，都包含一个成员对象，但意图完全不同。适配器是为了“接口转换”，让原本不兼容的东西能配合；装饰器是为了“增强功能”，在兼容接口的基础上叠加新的行为。比如给流加缓冲、加密、压缩，这是装饰器；把旧日志接口包装成框架日志接口，这是适配器。搞混了这个，面试和实际设计都会出问题。

2. 两种标准实现方式精讲

2.1 对象适配器：组合优先的思路

适配器模式有两种经典实现，最常用的是对象适配器，也叫组合适配器。它的思路是：适配器类同时实现目标接口，并且持有一个被适配者的对象指针或引用。所有调用都转发给被适配者。

我以一个媒体播放场景为例子。假设系统里已经有一个能播放mp4的老类OldMediaPlayer，但客户端现在期望的是通用的MediaPlayer接口，支持play(MediaType type, const std::string& filename)，其中MediaType可以是mp3、mp4、vlc。

#include <iostream> #include <string> enum class MediaType { Mp3, Mp4, Vlc }; class MediaPlayer { public: virtual ~MediaPlayer() = default; virtual void play(MediaType type, const std::string& name) = 0; }; // 被适配者：老播放器，只能播放mp4，接口还很死板 class OldMediaPlayer { public: void playMp4(const std::string& fileName) { std::cout << "老播放器正在播放 MP4: " << fileName << std::endl; } }; // 对象适配器 class MediaAdapter : public MediaPlayer { public: explicit MediaAdapter(std::shared_ptr<OldMediaPlayer> old) : oldPlayer_(std::move(old)) {} void play(MediaType type, const std::string& name) override { switch (type) { case MediaType::Mp4: oldPlayer_->playMp4(name); break; case MediaType::Mp3: std::cout << "适配器扩展支持 MP3: " << name << std::endl; break; case MediaType::Vlc: std::cout << "适配器扩展支持 VLC: " << name << std::endl; break; } } private: std::shared_ptr<OldMediaPlayer> oldPlayer_; }; int main() { auto oldPlayer = std::make_shared<OldMediaPlayer>(); MediaAdapter adapter(oldPlayer); adapter.play(MediaType::Mp4, "旅行记录.mp4"); adapter.play(MediaType::Vlc, "演示视频.vlc"); return 0; }

这里有几个工程细节值得注意。第一，适配器持有了shared_ptr而不是裸指针，这样调用方在适配器销毁前不需要担心被适配对象被提前释放。如果你确认适配器的生命周期一定短于被适配者，用裸指针或者引用也可以，但一定要在注释里写清楚生命周期约定。第二，play函数接收std::string参数时用的是const&，避免不必要的拷贝。第三，基类析构函数声明为virtual，这是多态删除的硬性要求，少了这个关键字，通过基类指针delete派生对象属于未定义行为。

对象适配器的最大优点就是低耦合。适配器不需要知道被适配者的内部结构，只依赖它的公开接口；即便继承层级再复杂，适配器都无所谓。同时它也符合“组合优于继承”的原则，一个适配器可以同时包装多个被适配者，灵活性非常高。

2.2 类适配器：私有继承实现接口转换

类适配器是另一种实现方式，它利用继承关系，让适配器同时继承目标接口和被适配者。在C++里，为了不暴露被适配者的接口，通常使用私有继承。

还是同一个媒体播放器例子，我们用类适配器重写：

class ClassAdapter : public MediaPlayer, private OldMediaPlayer { public: void play(MediaType type, const std::string& name) override { switch (type) { case MediaType::Mp4: // 私有继承，可以直接调用基类方法 playMp4(name); break; case MediaType::Mp3: std::cout << "类适配器扩展支持 MP3: " << name << std::endl; break; case MediaType::Vlc: std::cout << "类适配器扩展支持 VLC: " << name << std::endl; break; } } };

有些教材会把类适配器写成一个继承目标接口类、一个继承实现类的双重公有继承。但在C++里我强烈建议至少把实现继承设为私有，否则适配器会把被适配者的所有公开方法也暴露给调用方，破坏封装。私有继承的含义是“在实现层面复用实现细节，但对外不构成is-a关系”，从语义上讲，这正好符合适配器的定位。

类适配器的优点是少了一次间接调用，性能上通常比对象适配器好一点点，而且如果被适配者有protected成员方法，类适配器还能访问到，这是对象适配器做不到的。但它也有明显劣势：多个被适配者需要多继承，C++多继承会引入复杂性和各种初始化顺序问题；私有继承还可能导致调试器里看到一堆奇怪的基类，阅读体验差；而且Java等语言里没有多继承，类适配器实现起来很别扭。所以跨语言的经验是：优先用对象适配器，类适配器只在确实需要访问protected接口、或者对性能极其敏感时再用。

2.3 组合优先，继承慎用

每次有人问我适配器用哪种实现，我的答案都是同一个：默认用对象适配器。这不是因为类适配器不好，而是组合带来的灵活性收益远远大于那一点点点性能优势。

组合的好处是可以在运行时切换被适配者。比如你的适配器内部持有的是std::shared_ptr<RelationalDB>，今天连的是MySQL，明天要切到PostgreSQL，只要被适配者都满足同一个底层接口，适配器一行都不用改。继承在编译期就绑定了类型，做不到这种动态切换。

另一个原因是C++继承的“脆基类问题”。一旦被适配者的基类实现发生变动，类适配器可能静默改变行为，甚至编译报错一些莫名其妙的地方。组合则只依赖公开接口，只要接口稳定，实现随便改，对适配器没有影响。我见过太多因为多重继承加上菱形继承把简单功能搞复杂的项目，能用组合解决的，真的没必要上继承。

3. 实战：统一日志接口适配第三方库

3.1 场景还原：一个真实的日志切换需求

我参与过的一个项目，原来一直在用log4cplus，代码里到处都是LOG4CPLUS_INFO(logger, "...")之类的宏。后来因为性能瓶颈要切换到spdlog，但项目有几十万行代码，不可能一个个改调用点。团队给出的方案就是：定义一套自己的日志门面接口，然后分别给log4cplus和spdlog写适配器，业务代码只依赖门面接口。

这个案例非常适合理解适配器模式。它完美体现代码里“面向接口编程”的价值。我先把最终的接口设计写出来：

// LogTarget.h #pragma once #include <string> enum class LogLevel { Debug, Info, Warn, Error }; class LogTarget { public: virtual ~LogTarget() = default; virtual void log(LogLevel level, const std::string& message) = 0; }; // 一个简易门面，全局只用这一个入口 class Logger { public: static void init(std::unique_ptr<LogTarget> target) { instance().target_ = std::move(target); } static void debug(const std::string& msg) { instance().write(LogLevel::Debug, msg); } static void info(const std::string& msg) { instance().write(LogLevel::Info, msg); } static void warn(const std::string& msg) { instance().write(LogLevel::Warn, msg); } static void error(const std::string& msg) { instance().write(LogLevel::Error, msg); } private: static Logger& instance() { static Logger logger; return logger; } void write(LogLevel level, const std::string& msg) { if (target_) target_->log(level, msg); } std::unique_ptr<LogTarget> target_; };

这个门面本身不依赖任何具体的日志库。它只认识LogTarget，所有日志库都通过适配器塞到target_里。业务方不管底层是log4cplus还是spdlog，写Logger::info("hello")就够了。以后想换库，只需要重新写一个适配器，然后在main()函数里换Logger::init(...)那一行。

3.2 给spdlog写适配器

假设我们选型用spdlog作为新底层，那适配器可以把spdlog的logger封装起来：

// SpdlogAdapter.h #pragma once #include "LogTarget.h" #include <spdlog/spdlog.h> #include <memory> class SpdlogAdapter : public LogTarget { public: SpdlogAdapter() { logger_ = spdlog::stdout_color_mt("console"); spdlog::set_pattern("[%Y-%m-%d %H:%M:%S] [%^%l%$] %v"); } void log(LogLevel level, const std::string& message) override { switch (level) { case LogLevel::Debug: logger_->debug(message); break; case LogLevel::Info: logger_->info(message); break; case LogLevel::Warn: logger_->warn(message); break; case LogLevel::Error: logger_->error(message); break; } } private: std::shared_ptr<spdlog::logger> logger_; };

适配器的主要工作就是枚举映射：把我们内部的LogLevel映射到spdlog的level。真实项目里可能还要处理配置、刷新策略、按天滚动等逻辑，这些都可以封装在适配器内部，对上层透明。

我还加了格式设置，把日志格式统一成带时间戳的格式。这样在做日志分析时，无论底层切到哪个库，日志格式都能保持一致，下游的日志采集脚本不用跟着改。

3.3 给log4cplus写适配器，并验证编译期隔离

再写一个log4cplus的适配器，你就能直观看到适配器模式对库切换的贡献：

// Log4cplusAdapter.h #pragma once #include "LogTarget.h" #include <log4cplus/logger.h> #include <log4cplus/loggingmacros.h> class Log4cplusAdapter : public LogTarget { public: Log4cplusAdapter() { logger_ = log4cplus::Logger::getInstance(LOG4CPLUS_TEXT("global")); } void log(LogLevel level, const std::string& message) override { switch (level) { case LogLevel::Debug: LOG4CPLUS_DEBUG(logger_, message); break; case LogLevel::Info: LOG4CPLUS_INFO(logger_, message); break; case LogLevel::Warn: LOG4CPLUS_WARN(logger_, message); break; case LogLevel::Error: LOG4CPLUS_ERROR(logger_, message); break; } } private: log4cplus::Logger logger_; };

这两个适配器的接口签名完全一致，都满足LogTarget。切换方式如下：

#include "Logger.h" #include "SpdlogAdapter.h" // #include "Log4cplusAdapter.h" int main() { Logger::init(std::make_unique<SpdlogAdapter>()); Logger::debug("这是一条调试日志"); Logger::info("用户登录成功"); Logger::warn("磁盘空间不足"); Logger::error("数据库连接失败"); return 0; }

当你决定从spdlog切回log4cplus，只需改两个地方：include头文件、Logger::init(std::make_unique<Log4cplusAdapter>())。main之外一百万个业务调用点一行都不用动。这就是面向接口设计的威力，适配器是这个设计里不可或缺的桥梁。

值得说明的是，真实项目里Logger门面可以是任意形态，不一定是单例，你也可以做成依赖注入的方式，把适配器对象传给需要日志的模块。重要的是核心思想：上游语言只说“我要记一条info日志”，下游语言说“我只会按特定格式写”，中间的翻译交给适配器。

3.4 工程里的注意点：生命周期与线程安全

日志适配器看起来很简单，但在实际工程里容易踩几个坑。

第一是生命周期问题。上面的Logger单例持有unique_ptr<LogTarget>，所以在程序结束前，适配器对象会一直存活。但如果你是手动把适配器对象传给其他类，要确保适配器的生命周期覆盖所有使用它的地方。我见过一个bug，一个大对象持有一个LogTarget*，而适配器是函数里的局部变量，函数一返回指针就悬空，后面一打日志就崩。

第二是线程安全。日志接口必然会被多线程调用。我们的示例代码里，Logger::write只做了指针判断，没有加锁。如果适配器线程安全（比如spdlog默认是线程安全的），那问题不大；但如果你自己写了一个非线程安全的适配器，就必须在门面或者适配器内部加锁。这个细节不处理好，上线以后会出现偶发的日志乱序甚至崩溃，还特别难排查。

4. 实战：STL里到处是适配器思想

4.1 容器适配器：stack、queue和priority_queue

很多C++学习者第一次接触“适配器”这个词，是在STL文档里看到“容器适配器”。std::stack、std::queue、std::priority_queue就是典型的容器适配器。它们本身不直接实现存储，而是包装了std::deque、std::vector等底层容器，对外只暴露简化的接口。

比如std::stack，它的默认底层容器是std::deque，但你完全可以指定用std::vector：

#include <stack> #include <vector> #include <string> std::stack<int, std::vector<int>> intStack; intStack.push(1); intStack.push(2); while (!intStack.empty()) { std::cout << intStack.top() << std::endl; intStack.pop(); }

std::stack把vector的push_back转发成push，把back转发成top，把pop_back转发成pop。这不就是适配器吗？它把“支持尾部操作的顺序容器”这个接口，转换成“后进先出”这个更高级、更贴合语义的接口。原型、八股文里问“stack的底层实现”时，你要是能主动说出“stack是一个容器适配器，默认包装了deque，也可以指定vector或list”，这一下就跟只会背答案的应聘者拉开了差距。

std::queue同理，默认底层容器是deque。要注意的是，std::queue不能直接用std::vector做底层容器，因为vector没有pop_front。这个细节也是面试常考的点，能说清楚的话，证明你真的理解适配器和容器之间的接口约定。

4.2 迭代器适配器：反转迭代器与插入迭代器

迭代器这一层也大量使用了适配器思想。最常见的std::reverse_iterator，就是把普通迭代器适配成反向遍历的迭代器。你别看它用起来就一个rbegin()，底层做的事情其实很巧妙：反向迭代器内部持有一个正向迭代器，它的operator++对正向迭代器执行--，operator--执行++。

#include <vector> #include <iostream> int main() { std::vector<int> nums = {1, 2, 3, 4, 5}; for (auto it = nums.rbegin(); it != nums.rend(); ++it) { std::cout << *it << " "; } std::cout << std::endl; return 0; }

这个例子输出5 4 3 2 1。能看到，使用方式跟普通迭代器几乎一模一样，但底层行为完全反转了。std::reverse_iterator把“向前移动”的迭代器接口，适配成了“向后移动”的迭代器，这就是接口适配的又一个实例。

插入迭代器也很有意思。std::back_inserter把一个容器包装成“每次赋值都调用push_back”的输出迭代器。你可以用它配合std::copy往容器尾部追加元素，而不需要手动扩容：

#include <vector> #include <iterator> #include <algorithm> #include <iostream> int main() { std::vector<int> src = {10, 20, 30}; std::vector<int> dst; std::copy(src.begin(), src.end(), std::back_inserter(dst)); for (int val : dst) { std::cout << val << " "; } std::cout << std::endl; return 0; }

back_inserter的本质就是定义了一个迭代器适配器，它让“解引用赋值”这个接口变成了“调用push_back”这个操作。std::front_inserter和std::inserter同理。理解了这一层，你在写算法时就能明白，泛型算法其实根本不关心你要往哪种容器里装东西，它只关心迭代器是否满足接口约定。

4.3 函数适配器：std::function和std::bind

在C++里，还有一个很容易被忽略但极其重要的适配器用途，发生在函数和回调上。std::function本质上就是一个通用的函数包装器，它能把函数指针、仿函数、lambda、成员函数指针统统包装成统一的std::function对象，并且提供一致的调用语法。这就是一种函数接口的适配。

#include <iostream> #include <functional> int add(int a, int b) { return a + b; } struct Multiplier { int operator()(int a, int b) const { return a * b; } }; int main() { std::function<int(int, int)> func; func = add; // 普通函数 std::cout << func(2, 3) << std::endl; Multiplier mul; func = mul; // 仿函数 std::cout << func(2, 3) << std::endl; func = [](int a, int b) { return a - b; }; // lambda std::cout << func(2, 3) << std::endl; return 0; }

三种完全不同的可调用对象，通过std::function就能统一接收和调用。这在做回调注册、事件分发、命令模式的时候特别有用。比如你写一个回调管理器，注册函数时不想让调用方关心传进来的是lambda还是成员函数，那就统一用std::function作为形参类型，内部保存起来，到了合适的时机就调用。

std::bind则更像一个“参数适配器”。它可以固定某个函数的部分参数，生成一个新的可调用对象。比如一个函数有3个参数，你可以先绑定前两个，生成一个只需要1个参数的新函数。这在传回调给接口固定的第三方库时非常常见。不过在C++14以后，我更推荐优先用lambda，因为可读性更好，这也是面试里值得主动说出来的观点。

4.4 这些点为什么是面试高频考点

C++设计模式面试里，适配器模式和STL结合是出现频率很高的题。面试官喜欢问：“你了解STL里的配接器吗？”如果你能立刻说出容器适配器、迭代器适配器、函数适配器三层，再各举一个例子，这就证明你不是死记硬背，而是真理解了适配器思想。

我整理了一个速查表，面试前可以扫一眼：

把这些答出来，比单纯背“适配器模式有类适配器和对象适配器”要高级得多。我面试过不少候选人，能主动从设计模式聊到STL实现细节的人，代码能力通常都不差。因为这说明他平时写代码时一直在观察标准库的设计，而不只是把STL当成会用的工具箱。

5. 环境准备：用VSCode跑通所有示例代码

5.1 VSCode配置C/C++编译调试环境

前面这些代码，如果只是看，效果有限。强烈建议你亲手敲一遍、跑一遍、打断点看一遍。不少人卡在环境配置上，其实现在用VSCode配C++环境已经很顺了，我这里记录一下我常用的最小配置方案。

我习惯用MinGW-w64（Windows上可以用MSYS2装），因为它的g++和gdb配合VSCode很稳定。装好以后，写三个配置文件。第一个是.vscode/c_cpp_properties.json，用来告诉IntelliSense编译器路径和C++标准：

{ "configurations": [ { "name": "Win32", "includePath": ["${workspaceFolder}/**"], "defines": [], "compilerPath": "C:/msys64/mingw64/bin/g++.exe", "cStandard": "c17", "cppStandard": "cpp17", "intelliSenseMode": "windows-gcc-x64" } ], "version": 4 }

第二个是.vscode/tasks.json，负责编译。我一般直接用g++命令，简单直接：

{ "version": "2.0.0", "tasks": [ { "label": "C++ 编译", "type": "cppbuild", "command": "C:/msys64/mingw64/bin/g++.exe", "args": [ "-g", "-std=c++17", "${fileDirname}/*.cpp", "-o", "${fileDirname}/app.exe" ], "group": "build", "problemMatcher": ["$gcc"] } ] }

第三个是.vscode/launch.json，配置调试器：

{ "version": "0.2.0", "configurations": [ { "name": "C++ 调试", "type": "cppdbg", "request": "launch", "program": "${fileDirname}/app.exe", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}", "environment": [], "externalConsole": false, "MIMode": "gdb", "miDebuggerPath": "C:/msys64/mingw64/bin/gdb.exe", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true } ], "preLaunchTask": "C++ 编译" } ] }

这套配置可以从零跑通前面的任何示例。如果你遇到“无法打开xxx”或者“找不到g++”的报错，先检查环境变量里有没有把MinGW的bin目录加进去。在PowerShell里执行g++ --version，能打印版本号说明编译链没问题。

5.2 用CMake组织多文件示例更省心

示例一多，直接用g++敲命令就难维护了。我建议用一个简单的CMakeLists.txt，把所有示例聚合成一个工程：

cmake_minimum_required(VERSION 3.16) project(AdapterPatternDemo) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(adapter_demo main.cpp LogTarget.h Logger.h SpdlogAdapter.h )

然后在VSCode里装好CMake Tools扩展，选择好编译器套件，按一下状态栏的Build按钮就完事。如果你只是想验证设计模式的思想，不需要接真实的spdlog和log4cplus，那可以先把log()实现里的第三方库调用换成简单的std::cout，避免配第三方库的麻烦。

5.3 用调试器看清适配器的调用链

适配器模式在学习时最大的障碍是抽象。为了克服“代码怎么就从接口转到实现类去了”的困惑，最好的办法就是在调试器里看调用栈。

你在SpdlogAdapter::log那一行打一个断点，然后在main里调用Logger::info(...)，启动调试。观察Call Stack面板，你会看到这样的调用顺序：

1. main
2. Logger::info
3. Logger::write
4. SpdlogAdapter::log

你会在第4层看见，真正干活的其实是适配器类，而main完全不知道底层的存在。如果你再往下看，还有可能看到spdlog内部的真正输出函数。这个调用链就是适配器模式的运行真相。

类似地，在看std::vector<int> v = {1,2,3}; for (auto it = v.rbegin(); ...)时，你在*it那行打断点，也会发现底层调用的是__normal_iterator的转换逻辑。多花十几分钟调试，比看十篇博客都管用。

5.4 关于vscode配C++环境常见的三个坑

这里整理几个我帮同事排查时经常见到的坑。

第一个坑是launch.json里的program写死路径，一旦项目移动位置就报“无法找到”错误。尽量用${fileDirname}或者${workspaceFolder}这种变量，而不是写死成D:/projects/xxx/app.exe。

第二个坑是多文件项目编译时，只编译了当前打开的文件。我在tasks.json里写的${fileDirname}/*.cpp是编译当前目录下所有源文件，如果你把源文件分散在子目录，这个配置就会漏掉。改为使用CMake后，这个问题就基本消失了。

第三个坑是代码里用了C++17的特性，比如std::shared_ptr的make_shared，但是tasks.json里忘记加-std=c++17，编译器报一堆“不支持”的错。检查一下编译参数和c_cpp_properties.json里的cppStandard是否一致，通常能解决。

6. 常见问题与避坑指南

6.1 没有虚析构导致的内存泄漏

适配器模式里，基类接口类一定要声明虚析构函数。否则你用std::unique_ptr<LogTarget>管理SpdlogAdapter对象时，删除指针只会调用基类析构函数，派生类里的资源不会被释放。这个问题在测试环境通常不容易暴露，因为日志库内部资源不多，但如果是适配一个持有文件句柄或者网络连接的对象，就会造成句柄泄漏。

正确写法就是我们在示例里那行：

virtual ~LogTarget() = default;

不用写空实现{}，用= default更符合现代C++风格。这里顺便说一句，如果基类需要多态删除，就该有虚析构；如果这个类根本不打算作为接口使用，就不要随手写virtual，避免vtable开销。

6.2 对象切片：适配器按值传参要小心

对象切片是C++里隐蔽又容易犯的错。假设你定义了一个接口函数：

void setLogger(LogTarget logger); // 按值传递

然后把一个SpdlogAdapter对象传进去：

setLogger(SpdlogAdapter{});

这时函数参数发生了对象切片：SpdlogAdapter中的logger_成员丢失，只有LogTarget部分被拷贝进去了。函数内部拿到的其实是一个残缺的基类对象，多态完全失效。正确做法是传LogTarget&、const LogTarget&或者智能指针。这个教训在写任何涉及多态的接口时都适用，适配器模式尤其容易踩中，因为调用方总倾向于把适配器对象当成普通对象传来传去。

如果是自己设计接口，看到形参类型是一个带虚函数的类的值类型，就要敲响警钟，八成会在不知情时切片。代码评审时我会直接打回这种写法。

6.3 适配器嵌套过深导致的维护噩梦

有一种情况很普遍：项目里先有AAdapter把X库包装成接口I1，然后另一个同事不知道X已经有适配器，又写了BAdapter把I1包装成I2。过了两年，代码里的适配器套适配器，调用链长达六层，每当性能出问题，大家就在讨论该砍掉哪一层。

适配器模式被滥用的根本原因是，大家只图“当下不修改调用方”，却忽略了长期维护成本。我的经验是，适配器最多嵌套一层。如果发现需要第二层，就该停下来审视是不是接口设计本身出了偏差，或者直接用门面类重新梳理依赖关系。与其加更多适配器，不如把中间层合并成一个更完整的门面。

6.4 与业务场景结合的异常排查思路

有段时间我们在用OpenCV做棋盘格标定，同时集成了自己的图像处理模块，有同事在标定循环里偶尔会收到“std::exception”相关的崩溃日志。一开始大家以为是OpenCV标定函数的问题，后面才发现是图像数据源模块抛出的异常被某个适配器吞掉了，导致标定线程状态错乱。

排查这类问题，建议先看异常是从哪个模块边界抛出来的。适配器通常正好处在模块边界上，是最容易掩盖异常的地方。如果适配器内部调用了try/catch后只是记录日志然后继续返回，调用方会以为操作成功了，后续状态就全乱了。处理原则是：适配器可以转换接口，但不要轻易吞掉异常。如果确实需要把第三方异常转换成自定义异常，一定要保证新旧异常语义等价，不能让上层无从判断失败原因。

另外，在涉及图像、CAD这类大型C++项目时，崩溃信息常提示类似“standard C++ exception”而并不显示具体行号，这时候可以先看看是不是适配器传参时生命周期出了问题，或者回调函数是否在对象销毁后被触发。适配器对象被过早释放、回调悬挂，是这类问题的两大来源。

6.5 面试速查：适配器模式高频问题清单

结合最近的C++面试题和八股文风向，我整理了一份适配器模式面试考点清单，你可以把它当成自测表：

1. 适配器模式和代理模式、装饰器模式的区别是什么？
2. 类适配器和对象适配器的优缺点，你偏向哪种，为什么？
3. C++里实现类适配器时，为什么要用私有继承？
4. std::stack<bool>和std::stack<int>在底层容器上有没有隐藏坑？
5. std::function为什么能接收lambda？它背后用到了什么机制？
6. 如果一个适配器内部调用的第三方库接口是阻塞的，会不会拖垮调用线程？
7. 接口适配时，枚举转换、异常转换分别要注意什么？
8. 适配器模式在测试中如何配合依赖注入使用？

第4题其实是一个很刁钻的C++问题。std::vector<bool>是特化的bitset实现，不是常规的bool容器，如果你拿它做std::stack<bool>::container_type，可能会遇到一些代理对象的怪异行为。这在真实工程里不常见，但面试里很能区分一个人对STL实现细节的敏感度。

第8题值得多说一句。适配器模式在单元测试里非常有用。你想测试一个业务类，它的构造函数里需要传入DbTarget接口，你不想连真实数据库，那就写一个MockDbAdapter，它同样实现DbTarget接口，但内部只是往内存vector里写操作记录。测试结束后，你还能验证调用顺序和参数是否符合预期。这其实就是适配器模式在测试驱动开发里的经典用法。

7. 关于适配器模式的最后几点体会

我个人在实际项目中用适配器模式时，90%的场景都选对象适配器，真正用到类适配器的机会屈指可数。组合带来的灵活性、可测试性和生命周期可控性，对工程价值远远超过类适配器那一点性能收益。设计模式本身不是目的，把接口整理得舒服、让代码少几次返工，才是目的。

最后再分享一个小技巧。适配器模式的名字很容易让人以为只能用于类与类之间，其实函数级别的适配同样值得关注。比如你有一个旧的C风格回调函数，签名是void callback(int code)，而新系统期望的是void callback(int code, void* userData)，一个轻量lambda就能完成适配：

void oldCallback(int code) { std::cout << "code: " << code << std::endl; } int main() { auto newCallback = [](int code, void*) { oldCallback(code); }; // 把 newCallback 注册到新框架 }

这种两行代码的适配，不用刻意建一个类，反而更清爽。掌握适配器模式，最重要的是建立“接口不匹配时，可以在中间加一层转换”的思维习惯，而不是死记硬背类图。希望这篇文章能让你在项目里遇到接口对不上的场景时，能更从容地加一层“转换插头”，把问题解决在边界上。