先写能跑的代码，再考虑设计模式；模式是问题出现后的止痛药而非启动器，应在功能稳定、需求明确、扩展真实发生时引入，避免过早抽象导致编译开销、性能损耗与维护负担。
先写能跑的代码，再想模式
设计模式不是启动器，而是止痛药。你不会在写第一个 main() 之前就决定用策略模式还是观察者模式。真实项目里，绝大多数“该不该用模式”的纠结，都发生在功能还没跑通、接口还没稳定、甚至需求还在改的时候。
常见错误现象：std::shared_ptr 封装了三层、抽象基类写了五个纯虚函数、工厂类导出七个模板特化——结果发现这个模块只被调用一次，且后续不会再扩展。
- 先实现最直白的版本：比如一个配置加载器，直接写
ConfigLoader::load(const std::string& path)，返回std::map<:string std::string></:string> - 等出现第二个不兼容的配置格式（如 JSON 替代 INI）时，再提取公共接口；等第三个格式出现、或需要运行时切换时，才引入工厂或策略
- 如果最终只有 INI 一种格式，那就保持原样——没有“未来可能”，就没有“模式义务”
警惕“模式驱动开发”陷阱
看到单例就立刻加 getInstance()，看到依赖就急着上依赖注入容器，看到状态变化就想套观察者——这是把模式当 checklist，不是当工具。C++ 的 RAII、移动语义、模板推导这些语言特性本身就在解决很多传统模式试图应对的问题。
使用场景对比：
立即学习“C++免费学习笔记（深入）”；
- 你需要全局唯一资源管理？先检查是否真需要“全局”——
static局部变量 +std::unique_ptr已经线程安全且无锁，比手写双重检查锁定单例更轻量 - 你要解耦算法逻辑？优先用
std::function或 lambda，而不是立刻定义抽象策略类和一堆子类 - 你打算封装子系统？先看能否用命名空间 + 内联函数 +
detail命名约定做到隔离，门面模式（Facade）是最后一步，不是第一步
用编译/链接成本倒逼设计克制
C++ 没有 JIT，头文件污染、模板实例爆炸、符号冗余都会直接拖慢构建速度、增大二进制体积。每个额外的抽象层，都在增加 #include 依赖链长度和 ODR（One Definition Rule）风险。
性能与兼容性影响：
- 每多一层虚函数调用，就多一次间接跳转——在高频路径（如渲染循环、网络包解析）中，这比你想象中更重
- 每个模板类导出接口，都可能触发跨 TU 的隐式实例化，GCC 14 下模块（
module）仍不稳定，头文件仍是主力，滥用泛型工厂会让编译时间指数增长 - 如果你的类要导出为 DLL / SO，虚表布局、ABI 兼容性、异常规范都会因过度抽象而失控——
final类、非虚析构、值语义优先，才是 C++ 级别的“封闭”
真正该花时间的地方：接口契约与生命周期
比起纠结“用不用适配器”，不如花十分钟厘清：这个函数谁 new、谁 delete？参数是传值、传 const ref 还是 std::span？返回值能不能 move？这些决定比选哪个模式影响更大、也更不可逆。
容易踩的坑：
- 为了“符合开闭原则”把所有成员函数设为 virtual，却忘了 C++ 中 virtual 成员函数默认不是
final，导致子类意外重写关键逻辑 - 用
std::shared_ptr包裹一切来“避免裸指针”，结果引发循环引用、延迟析构、原子操作开销——而多数时候，栈对象 + 移动语义就足够 - 在头文件里写
template <typename T> class StrategyImpl，却没意识到它会强迫所有包含该头的 TU 都参与实例化，哪怕只用到了StrategyImpl<int>
复杂点不在模式本身，而在你是否清楚每个 virtual、每个 export、每个 std::shared_ptr 落地时带来的实际成本。模式只是名字，代价才是实感。
