应将职责模糊的类按渲染、序列化、校验拆分，模板参数爆炸时提取非模板基类并用策略模式解耦，多后端支持采用桥接模式，头文件依赖失控则分离枚举定义与使用。
类职责模糊，改一个功能要动三处代码
当你发现每次修改某个功能，都得同时打开 ShapeRenderer、ShapeSerializer 和 ShapeValidator 三个文件去同步更新逻辑，那说明这个类已经承担了渲染、序列化、校验三种不相关的职责。C++里没有“单一职责”的编译检查，但运行时行为会暴露问题：比如加个新格式导出，结果单元测试里一堆渲染失败的用例突然报错——因为序列化逻辑改错了内存布局，间接破坏了绘图管线。
这种耦合的典型信号是：public 接口里混着 saveToFile()、draw(QPainter*)、isValid() const 这类语义完全无关的函数；或者私有成员里既有 QImage m_cache 又有 std::string m_jsonData 又有 bool m_dirtyFlags[8]。
- 拆分前：所有操作共享同一套生命周期管理（比如构造时加载资源，析构时释放缓存）
- 拆分后：渲染器只管 GPU 资源，序列化器只管字节流，校验器纯计算无副作用
- 关键收益：单元测试可以独立覆盖每个维度，新增 SVG 导出不用碰 OpenGL 绘制代码
模板参数爆炸，template<typename t bool usegpu int version></typename> 开始失控
当类模板声明变成一行写不完、IDE 提示 “template instantiation depth exceeds 256”、或者编译耗时从 2 秒涨到 47 秒时，说明泛型封装已经过载。常见于图像处理库中把像素类型（uint8_t/float）、存储方式（std::vector/cudaMalloc）、算法变体（fast/accurate）全塞进一个模板参数列表。
这时应该把不变的部分（如坐标变换、ROI 计算）抽成非模板基类，把变化剧烈的部分（如像素访存、SIMD 指令选择）拆成独立策略类，用 std::unique_ptr<ipixelprocessor></ipixelprocessor> 组合进去。
- 别硬扛：
ImageProcessor<float true></float>和ImageProcessor<uint8_t false></uint8_t>实际生成的代码几乎没有复用 - 拆分后可显式特化：针对
uint8_t + CPU场景写一个轻量级实现，避免为 GPU 特化代码引入 CUDA 头文件依赖 - 注意虚函数开销：如果性能敏感，用
std::variant<cpuprocessor gpuprocessor></cpuprocessor>替代虚基类
继承树里出现 “又…又…” 描述，比如 “又支持矢量又支持光栅又支持 WebGPU”
当你听到同事说“这个 Renderer 类既要画 SVG 又要渲染 PNG 又要对接 Vulkan”，基本就是桥接模式该上场的时候了。强行在一个类里实现所有组合，会导致 renderVector()、renderRaster()、renderWebGPU() 三个函数内部共享大量条件判断和状态变量，新增一种后端就得在每个函数里加 if (backend == WEBGPU) { ... }。
正确做法是拆成抽象层（Renderer）和实现层（VectorImpl、RasterImpl、WebGPUImpl），通过指针或引用关联。这样新增 Vulkan 后端只需写 VulkanImpl，完全不碰 Renderer 的接口定义。
- 典型错误：用多重继承模拟多后端支持，结果
class VulkanSVGRenderer : public SVGRenderer, public VulkanRenderer引发菱形继承和虚函数调用歧义 - 桥接拆分后，
Renderer的构造函数参数从 7 个减少到 1 个（std::unique_ptr<irenderimpl></irenderimpl>） - 调试时能清晰看到：崩溃发生在
VulkanImpl::draw()而不是 “不知道哪个后端的Renderer::doRender()”
头文件依赖失控，改一个枚举就要重编译整个 GUI 模块
如果 ColorScheme.h 里定义了一个 enum class Theme { Light, Dark, Auto }，而它被 MainWindow、SettingsDialog、ChartWidget、LogViewer 全部直接包含，那么只要改个枚举值名字，整个 UI 层所有 .cpp 都得重新编译。更糟的是，有人在 LogViewer 里偷偷加了 #include "opencv2/opencv.hpp"，导致 ColorScheme.h 间接污染了所有依赖它的模块。
这时候要把“定义”和“使用”彻底分离：把枚举移到 core/enums.h（仅含 POD 类型），把主题切换逻辑封装进 ThemeManager 类，让 UI 控件只依赖 ThemeManager::currentTheme() 这个轻量接口。
- 头文件瘦身关键：确保
enums.h不 include 任何第三方库，不声明任何类，不定义任何函数 - 拆分后，
LogViewer的编译时间从 12 秒降到 0.8 秒，因为它不再需要解析 OpenCV 的 200+ 个头文件 - 容易忽略的点：C++ 中
constexpr枚举值如果出现在模板参数里（如static_assert(theme == Theme::Dark)），仍需头文件可见，此时必须保留 enum 声明，不能只留函数返回值
git blame 看到的 17 个文件修改里。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
