企业官网建设流程全解析

设计模式在 C++ 里是个挺特别的话题。很多人学设计模式，拿 Java 那套直接往 C++ 上套，结果项目里不是内存泄漏就是多线程崩溃，然后开始怀疑模式本身有问题。其实不是模式的锅，是 C++ 的“脾气”跟 Java 不一样。值语义、RAII、模板、多继承这些特性，决定了同一个模式在 C++ 里往往有更贴近底层的写法，也踩过更多的坑。

这篇文章既照顾刚学完 C++ 语法、准备做设计模式大作业或者期末复习的同学，也照顾已经写了两三年业务代码、面试前想系统梳理一遍的从业者。我会从模式的分类讲起，把每种模式在 C++ 里最容易出问题的点挑出来说，重点讲“为什么 C++ 不能照抄 Java 写法”，然后给出我认为比较靠谱的实现方案和避坑经验。

1. C++ 里学设计模式，先别急着照搬 Java

1.1 值语义与对象语义：C++ 的第一道分水岭

GoF 那本《设计模式》成书于 1994 年，背景是 Smalltalk 和 C++ 混用的年代。书里的模式描述大量基于“对象引用”“对象创建”“对象析构”这些概念，默认你是通过指针或引用来操作对象的。而 Java 继承了这个取向，所有对象都是引用语义，new 出来一个就是一个堆对象，没有“意外拷贝”这回事。

但 C++ 不一样。你写MyClass a = b;的时候，如果 MyClass 没禁拷贝，这就是一次实实在在的拷贝构造。这个差异直接改变了一批模式的实现路径。比如原型模式，Java 里普遍是clone()方法返回对象副本；C++ 里如果类是值语义的，拷贝构造本身就是一个原型复制器，你甚至不太需要刻意实现一个clone()虚函数。反过来讲，如果类里有裸指针资源，你又不能简单用拷贝构造顶替，必须遵守三五法则好好写拷贝和移动。

很多人在 C++ 里实现抽象工厂，返回值用std::shared_ptr<AbstractProduct>，这没问题。但要注意 C++ 还讲究“返回什么语义”：你是想让调用方共享所有权，还是独占所有权，还是说仅仅借用一下不接管生命周期。这个思考维度在 Java 里几乎不存在，在 C++ 里直接决定你的接口该怎么设计。

1.2 RAII：所有模式都绕不开的底层逻辑

RAII（Resource Acquisition Is Initialization）是 C++ 最核心的惯用法：资源在构造函数里获取，在析构函数里释放。它表面上看只是个“内存管理技巧”，实际上它改变了你实现很多模式的方式。

拿观察者模式举例。Java 里标准做法是subject.addObserver(observer)，程序退出前再removeObserver，做不干净也不至于炸。C++ 里如果你用一个全局主题对象，注册了一堆观察者对象，某些观察者先析构了，主题还保留着指向它的裸指针，下一次事件广播就会发生空悬指针访问，运气好是崩溃，运气差是读到已经释放的堆内存里的残留数据，定位起来极为痛苦。

所以在 C++ 里我习惯把观察者注册做成 RAII 式：订阅对象构造时把自身地址注册到主题，析构时自动取消订阅。这就是把“生命周期管理”塞进了模式的实现细节里，而不是等调用方去“记得”清理。类似的思路也应用在装饰器、代理这些涉及包装关系的模式上。

1.3 虚函数与模板：C++ 有两条路实现同一个模式

最初的设计模式都建立在“继承 + 虚函数”的多态体系上。C++ 除了这套，还有模板这个天然武器。模板偏重编译期绑定，虚函数偏重运行期绑定。这就导致很多模式在 C++ 里有两派写法：经典的多态写法，和模板风格的写法。

比如策略模式，经典写法是定义IStrategy抽象基类，每个策略一个派生类，运行时注入。但在 C++ 里，如果策略在编译期就能确定，直接用模板参数注入，零虚函数开销，代码反而更直白。还有访问者模式，经典实现依赖双分派和继承体系，但现代 C++ 提供std::variant+std::visit，在类型集合固定的场景下直接干掉一坨继承结构。

这算不算“设计模式”？我认为算。模式的核心是“解决问题的方案”，而不是“必须使用虚函数”。在 C++ 里写模式，你得先想清楚：这个变化点是运行期变化还是编译期变化。运行期变化用虚函数那套，编译期变化用模板那套，两者强行互换只会让代码又慢又绕。

2. 创建型模式：对象从哪来，是个大问题

2.1 单例模式：线程安全只是及格线

单例是 23 种模式里最“简单”也最容易被写崩的一个。初学者版本常是这样：

class Singleton { public: static Singleton* getInstance() { if (m_instance == nullptr) { m_instance = new Singleton(); } return m_instance; } static Singleton* m_instance; };

这个版本的问题大家都熟了：线程不安全，多线程下可能 new 出两个实例，甚至发生内存泄漏。加锁版本能解决线程安全，但锁开销和代码啰嗦程度都上来了。C++11 之后我建议直接用 Meyers Singleton：

class Singleton { public: static Singleton& getInstance() { static Singleton instance; return instance; } Singleton(const Singleton&) = delete; Singleton& operator=(const Singleton&) = delete; private: Singleton() = default; };

这个写法的关键是：函数内的局部静态变量初始化是线程安全的，编译器会帮你生成保护代码，C++11 开始这是标准保证的，不是行为未定义。返回引用而不是指针，也杜绝了调用方误删单例的风险。析构函数在程序退出时自动调用，资源不会泄漏。

不过这还不够。单例最容易翻车的点是：依赖顺序。如果两个单例 A 和 B，A 的构造函数里调用了 B 的实例，而 B 的构造函数又调用了 A 的实例，在静态初始化阶段就会陷入死锁或未定义行为。我的经验是：单例的构造函数里绝对不要调用其他单例，如果有依赖，拆成显式的初始化函数，按业务顺序执行。

2.2 工厂模式：从裸指针到 unique_ptr

工厂模式本身不复杂，复杂的是返回值怎么写。看很多老代码喜欢这么干：

Product* createProduct(const std::string& type) { if (type == "A") return new ProductA(); if (type == "B") return new ProductB(); return nullptr; }

裸指针返回的隐患一眼可见：谁负责 delete？如果调用方忘了删，泄漏；如果中间抛了异常，连删除机会都没有。C++ 里正解是直接用智能指针做返回值：

std::unique_ptr<Product> createProduct(const std::string& type) { if (type == "A") return std::make_unique<ProductA>(); if (type == "B") return std::make_unique<ProductB>(); return nullptr; }

调用方拿到unique_ptr之后，所有权转移清清楚楚。如果你需要多个地方共享产品对象，再转成shared_ptr也不迟。工厂方法一般用一个注册表，避免一长串 if-else 越来越臃肿：

using FactoryFunc = std::function<std::unique_ptr<Product>()>; std::unordered_map<std::string, FactoryFunc> registry; // 注册 registry["A"] = [] { return std::make_unique<ProductA>(); }; // 创建 auto product = registry.at("A")();

这种用 map 保存工厂函数的方式，在游戏开发和服务端代码里都很常见。新增产品类型时，你只需要往注册表里塞一条，不用动已有逻辑，符合开闭原则。要注意的是 map 的键和查找的字符串要统一管理，最好抽成常量，避免魔法字符串混乱。

2.3 建造者模式：链式调用与参数校验

建造者模式在 C++ 里表现力很强，尤其适合那种构造函数参数巨多的类。直接给构造函数塞七八个参数，调用方根本分不清哪个是哪个，还容易传错。用建造者可以做到：

class HttpRequestBuilder { public: HttpRequestBuilder& setUrl(const std::string& url) { m_url = url; return *this; } HttpRequestBuilder& setMethod(const std::string& method) { m_method = method; return *this; } HttpRequestBuilder& setHeader(const std::string& k, const std::string& v) { m_headers[k] = v; return *this; } HttpRequest build() { // 这里可以做参数校验 if (m_url.empty()) throw std::invalid_argument("url is required"); return HttpRequest(m_url, m_method, m_headers); } private: std::string m_url; std::string m_method = "GET"; std::map<std::string, std::string> m_headers; };

注意 setter 返回自身引用，实现链式调用，最终调用 build()。关键点是把“参数合法性校验”集中在 build() 里，这样业务代码构造请求时不会被一堆校验逻辑打乱。实际项目里，我还会在 build() 里区分哪些参数是必填、哪些有默认值，必要的时候用状态标志记录“是否调用某个 setter”。

建造者模式额外的优势是支持不可变对象：HttpRequest的字段都是 const 或只读，所有可变化的部分都发生在 builder 内部。这在并发环境里非常省心，对象一旦构造出来就不会被改坏。

3. 结构型模式：接口之间怎么粘

3.1 适配器模式：包装外部代码的常规操作

适配器模式是日常开发中出现频率最高的模式之一，只是你不一定意识到自己在用它。最常见的场景是：老系统里有一个类提供了一组接口，新模块要求另一种接口，你又不能直接改老类，因为改一处可能影响几十处调用。怎么办？写一个适配器，把新接口的请求翻译成老接口的调用。

C++ 里实现适配器，我建议优先考虑组合而不是继承。适配器内部持有一个旧接口的对象（或者引用、指针），对外暴露新接口：

class NewInterface { public: virtual ~NewInterface() = default; virtual void execute(const std::string& cmd) = 0; }; class LegacyAdapter : public NewInterface { public: LegacyAdapter(LegacyService* svc) : m_svc(svc) {} void execute(const std::string& cmd) override { // 转换为旧接口的参数 m_svc->runLegacy(cmd, 0); } private: LegacyService* m_svc; };

继承适配器接口是为了满足多态，内部组合老对象是为了复用其实现。组合优于继承这条原则在适配器场景下非常适用，因为继承旧类会把旧类的实现细节也带进来，破坏封装。

常见问题：适配器的生命周期。如果LegacyAdapter持有一个裸指针指向LegacyService，但LegacyService先被销毁了，execute就是空悬调用。工程上要么用shared_ptr共享所有权，要么让适配器和被适配对象生命周期严格对齐，用代码注释或者 RAII 机制约束。不要觉得这是小事，我见过一个项目跑一两个月才偶发崩溃，最后定位到就是适配器里的裸指针空悬。

3.2 装饰器模式：运行时叠加功能

装饰器模式的本质是“组合一套接口相同、实现层层包装的对象”，让调用方感觉是在用一个对象，实际上每个方法都被各层装饰器处理过一遍。C++ 里最典型的场景是流类：std::ifstream加boost::iostreams的各种过滤器，一层套一层，读数据的时候自动完成压缩、加密、编码转换。

我实现装饰器时的习惯是：抽象基类定义接口，并保存一个“被装饰对象”的引用或指针；每个装饰器只做自己的事，然后调用被装饰对象的方法。代码结构大概是：

class DataSource { public: virtual ~DataSource() = default; virtual void write(const std::string& data) = 0; }; class FileSource : public DataSource { /* 真正写文件 */ }; class EncryptionDecorator : public DataSource { public: EncryptionDecorator(DataSource* wrapped) : m_wrapped(wrapped) {} void write(const std::string& data) override { auto encrypted = encrypt(data); m_wrapped->write(encrypted); } private: DataSource* m_wrapped; };

需要谨慎的是对象的生命周期：装饰器析构时是否负责析构m_wrapped？这又是一个所有权问题。推荐的做法是：装饰器只组合不拥有，析构时不动底层对象；让创建者统一管理整条对象链。或者干脆用shared_ptr，所有装饰器都持有一份所有权，谁最后释放由引用计数决定。两种方案都可以，但必须写清楚接口注释，别让人猜。

3.3 代理模式与所有权：别把代理做成裸指针裸奔

代理模式常被跟装饰器混淆。区别在于意图：代理控制访问方式，装饰器增强功能。C++ 里常见的代理有：远程代理、虚拟代理（延迟加载大对象）、智能指针本身也算一种代理。

实现代理最需要注意的还是生命周期。比如虚拟代理，内部持有真实对象的裸指针：

class ImageProxy : public Image { public: void draw() override { if (!m_real) { m_real = new RealImage(loadFromDisk()); } m_real->draw(); } private: RealImage* m_real = nullptr; };

如果ImageProxy析构时不 deletem_real，内存就泄漏了；如果调用方同时持有了RealImage，又可能双重释放。我通常会写成内部用std::unique_ptr<RealImage>持有真实对象，这样析构自动释放，又避免了共享所有权。如果你是希望调用方和代理共享同一个真实对象，那用shared_ptr更合理，两者目的完全不同，动手前先想清楚。

现代 C++ 里std::shared_ptr的别名构造函数shared_ptr<Base>(shared_ptr<Derived>)本质上就是一种代理：它把 Base 的接口暴露出去，但底层对象是 Derived，同时正确维护引用计数。这种利用标准库完成代理语义的思路，比手写代理类要稳得多。

4. 行为型模式：把变化封装成一等对象

4.1 策略模式：从虚函数基类到 std::function

策略模式的核心是“用组合代替继承，把算法抽出来独立变化”。教科书做法是这样：

class IStrategy { public: virtual ~IStrategy() = default; virtual int calculate(int a, int b) = 0; }; class AddStrategy : public IStrategy { int calculate(int a, int b) override { return a + b; } }; class Context { public: void setStrategy(IStrategy* strategy) { m_strategy = strategy; } int doCalc(int a, int b) { return m_strategy->calculate(a, b); } private: IStrategy* m_strategy; };

这个写法完全正确，但 C++ 实操里，策略往往不是“一整类对象”，而只是一个函数或一个 lambda。你为了一个 lambda 去写一个派生类，实在是杀鸡用牛刀。C++11 之后我更推荐：

class Context { public: using Strategy = std::function<int(int, int)>; void setStrategy(Strategy strategy) { m_strategy = std::move(strategy); } int doCalc(int a, int b) { return m_strategy(a, b); } private: Strategy m_strategy; };

调用时直接塞 lambda：context.setStrategy([](int a, int b) { return a * b; });。这本质上仍然是策略模式，只是策略载体从“对象”变成了“可调用物”。好处是轻量，坏处是如果策略内部需要复杂状态，还是老老实实用对象。

我个人的取舍标准：策略超过三个成员变量或者有内部缓存，就用传统策略接口；策略只是一个算法片段，就用std::function。不要为了“模式正统性”牺牲代码简洁度。

4.2 观察者模式：生命周期的血泪教训

观察者模式是 GUI、事件系统、消息总线的老熟人。C++ 实现它，最头疼的不是“如何通知”，而是“通知给谁”。主题对象里存观察者，存裸指针有悬空风险，存shared_ptr又有两个问题：一是主题会延长观察者生命周期，违背预期；二是观察者回调里可能操作主题本身，形成死锁或重入。

我的建议分两种场景：如果观察者生命周期明确比主题短，而且必然在线程安全的节点上被销毁，可以用裸指针加“标记销毁”机制；如果项目里对象生命周期非常混乱，最好用弱指针方案：

class Subject { public: void attach(const std::weak_ptr<Observer>& obs) { m_observers.push_back(obs); } void notify() { for (auto it = m_observers.begin(); it != m_observers.end();) { if (auto obs = it->lock()) { obs->update(); ++it; } else { it = m_observers.erase(it); // 清理已失效的观察者 } } } private: std::vector<std::weak_ptr<Observer>> m_observers; };

weak_ptr方案的好处是：观察者析构后，通知时自动跳过，不会空悬。代价是每次通知都要 lock 一次，性能有一点损耗，但绝大多数业务场景毫秒级都无所谓。真正需要注意多线程下notify被并发调用的问题，怎么加锁、怎么避免回调中再次调用 attach 导致迭代器失效，这些是观察者模式在 C++ 里的深水区，面试时能聊到这个层面会很加分。

还有一个小 Tip：回调里如果执行了耗时操作，比如网络请求或磁盘 IO，最好把通知改成“投递事件到队列，异步处理”，否则一个慢观察者会卡住整个主题的广播。

4.3 访问者模式：双分派与 std::variant

访问者模式是 23 种模式里最难懂的几个之一。它解决的核心问题是“在类型稳定的结构上，增加新操作”。经典实现有两个关键：accept 方法里调用访问者的 visit，访问者里再根据具体类型调用对应重载，形成双分派。

C++ 经典写法代码量很大，但结构还算清晰：

class Visitor; class Element { public: virtual ~Element() = default; virtual void accept(Visitor& v) = 0; }; class ElementA : public Element { public: void accept(Visitor& v) override { v.visit(*this); } }; class Visitor { public: virtual ~Visitor() = default; virtual void visit(ElementA& e) = 0; // 每个具体元素一个重载 };

这个模式真正的问题是：每新增一个 Element 子类，所有 Visitor 都要加一个 visit 重载，对扩展并不友好。所以现代 C++ 里，如果元素类型是有限集，我更喜欢用std::variant：

using Element = std::variant<Circle, Square, Triangle>; void draw(const Element& e) { std::visit([](const auto& shape) { shape.draw(); }, e); } double area(const Element& e) { return std::visit([](const auto& shape) -> double { return shape.area(); }, e); }

这里std::visit做的就是“类型分派”，而variant本身就是类型安全的联合体。新增一种形状，只需要扩展 variant 的模板参数，函数内部用autolambda 自动适配。这种风格在编译期就完成了类型的穷举检查，少了很多运行期虚函数分发。不过也要注意：如果类型集合经常变，variant会让所有visit的使用点都参与编译，编译时间会上升；类型集稳定时，这个方案性价比很高。

5. 23种模式的记忆框架与C++实现要点

5.1 一张表理清三大类模式

面试和期末考试都是围绕 GoF 23 种模式出题。我建议先把分类框架背进脑子里，再来补细节。这张表就是我的速查底稿：

记忆方法上，可以按口诀走：创建型“工抽单建原”，结构型“适装代外组桥享”，行为型“策观模状命责迭，中备访解”。先念熟，再做题，比硬记英文名效率高很多。

5.2 面试和考试里躲不开的坑

面试题里那些“说说单例模式”“什么是工厂模式”都是开胃菜，真正刷人的是这几个：

第一，让手写一个线程安全的单例。很多人上来就写双检锁，却忽略了内存序。C++11 以后正确答案应当是 magic static 或带std::call_once的版本。双检锁也可以用但必须配合std::atomic的 acquire/release 语义，写错就是未定义行为。第二，让比较“装饰器”和“代理”模式的区别。很多人只背定义，一举例就露馅。核心区分是意图：装饰器增强功能，代理控制访问。第三，让设计一个“支持撤销的命令模式实现”。这时候得把命令对象保存栈、每次执行压栈，撤销时弹栈调用unexecute()，这属于业务设计能力，比较拉开差距。

还有一类高频题：C++ 里实现观察者模式要注意什么？如果你只答“用列表存观察者”，面试官大概率会追问“观察者对象被释放了怎么办”“多线程广播怎么保证安全”。所以前面写的那套 weak_ptr + 异步队列方案，建议好好消化，面试时能画个结构图说明就非常加分。

5.3 我的学习与复现顺序建议

如果现在让你自己从零学完 23 种模式，我不建议按目录顺序一个个来，那样学到后面容易泄气。我给一个按“上手难度 + 实用频率”排列的顺序：

• 第一批：单例、工厂方法、策略、观察者、模板方法。这几个日常写业务代码几乎天天碰，代码量小，适合建立信心。
• 第二批：抽象工厂、建造者、适配器、外观、装饰器、状态、命令。这些需要理解对象之间的关系，能帮你建立“模式组合使用”的意识。
• 第三批：桥接、组合、代理、责任链、中介者、解释器、迭代器、备忘录、享元、访问者、原型。低频但面试会问，特别是代理、访问者、享元。

实操方法上，我建议每个模式至少写一个“脱离业务的小例子”，比如单例写日志管理器，观察者写事件总线，命令写撤销栈。用 VSCode 配好 C++ 环境，建一个简单的 CMake 工程，把每个模式单独放一个文件夹，编译跑通、加断点看调用链。真实调试一遍，比你对着书看十遍都管用。我当年就是这样，花两周把 23 个例子全过了一遍，之后面试聊设计模式基本不带怕的。

6. 避开这些 C++ 特定的大坑

6.1 容器存基类对象导致切片

实现组合模式或者观察者列表时，有人图省事直接std::vector<Base>。这是个大坑，基类对象存进容器后，派生类部分会被“切掉”，只剩基类子对象，多态直接失效。C++ 容器存对象是值语义，要么存指针、要么存智能指针。标准做法是std::vector<std::shared_ptr<Base>>或std::vector<std::unique_ptr<Base>>，前者用于共享，后者用于独占。

切片的坑不只在容器，函数参数传值时也一样。所以设计模式的接口方法里，凡是涉及多态对象的参数，记得用指针或引用传递，别按值传。刚开始写 C++ 模式代码很容易忽略这一点，等调试的时候发现调用的总是基类方法，再回来改就要动不少代码了。

6.2 回调里的 Access Violation

很多 C++ 程序运行一段时间后偶发崩溃，报错类似0xC0000005 access violation，排查到最后往往发生在回调函数里。这正是观察者模式或者命令模式最容易踩的地雷：回调触发的时候，回调对象已经析构了，或者回调内部访问的资源已经被释放。

我处理这类问题的经验是：所有回调注册的入口，都要求调用方明确传递对象的生命周期保证。做不到就用weak_ptr方式注册，执行回调前先 lock 检测有效性。另外，在一个对象内部注册回调时，析构函数里务必要有取消注册的动作。如果你实现了 RAII 风格订阅，这一步就自动覆盖了。线上环境里“偶发崩溃”往往就是这么来的，查起来极其消耗时间，所以在一开始写模式代码时就该把生命周期当成接口约定的一部分。

6.3 多线程下的模式失效

很多单例、观察者、命令模式在多线程下会出现诡异问题。单例除了初始化要线程安全，还面临“实例不再使用但业务线程还在访问”的问题，这时析构时机很难把控。观察者广播和订阅线程不一致时，容易产生数据竞争。命令模式的撤销栈如果被多个线程操作，必须加锁或者改成无锁队列。

我一般不推荐在设计模式代码里到处加锁，更建议从顶层设计规避：单例在程序启动阶段就创建，不要中途销毁；观察者广播在单独的事件线程投递，订阅和退订都通过队列；命令执行串行化。这些手段比给每个方法加锁要清晰得多。

7. 学习设计模式的进阶心得

模式这东西，知道多少不重要，用对地方才重要。我见过一些人，学了模式以后把所有类都套上抽象基类，接口满天飞，getter/setter 绕三层，实际上业务逻辑就两三行。过度设计比没有设计更折磨人，因为代码可读性严重下降，后维护的人骂娘。

反而是那些看起来“不够模式”的代码，如果能做到单一职责清晰、依赖方向明确、生命周期可控，就已经解决了大部分工程问题。设计模式是工具箱，不是装修模板。每个类都要套模式，那叫仪式感，不叫工程能力。

我的体会是，真正掌握一个模式要经历三个阶段。第一阶段能照着例子写出来；第二阶段能在自己的项目里识别出“这里适合用这个模式”；第三阶段能根据形势调整模式的经典结构，让它更好地贴合具体场景。比如策略模式在 C++ 里用std::function改造，就是这个道理。别为了“保持模式原型”而拒绝改进，模式是起点，不是终点。

如果这篇文章能帮你在设计模式大作业里少走点弯路，或者在面试前把 C++ 版模式的关键点理顺，那就值了。写代码这么多年，回头看那些调了一整天才发现的 bug，基本都是生命周期和所有权的问题，这也正是 C++ 设计模式实现里最值得花心思琢磨的地方。