C++可通过继承统一抽象基类、智能指针链式包裹和RAII转发实现等效Python装饰器的功能；关键在于多态接口、运行时叠加、异常安全及所有权清晰。
C++ 没有原生装饰器语法，但用组合 + 接口抽象 + 指针/引用转发，完全能实现和 Python @decorator 等效的运行时功能增强 —— 关键不在语法糖，而在是否让被装饰对象和装饰器共用同一接口、能否链式叠加、是否避免修改原类。
为什么必须继承统一抽象基类
装饰器要“伪装成”被装饰对象，调用方才无需感知差异。若不强制 Decorator 和 Component 继承同一虚基类，就无法用多态指针统一管理，更没法嵌套（比如 LoggingDecorator 包裹 TimingDecorator 再包裹 RealService）。
常见错误是只用模板或 typedef 模拟，结果编译期类型爆炸，无法 runtime 切换装饰逻辑。
- 基类必须定义纯虚函数（如
virtual void execute() = 0;），所有具体类（含装饰器）都重写它 - 装饰器构造函数必须接收
std::unique_ptr<component></component>或Component&，不能只存原始指针（易悬空） - 基类析构函数必须为
virtual ~Component() = default;，否则delete装饰器时不会调用子类析构
Decorator 类如何正确转发调用
转发不是简单调 component->execute() 就完事。真正有用的装饰器总在前后插入逻辑：比如记录耗时、检查权限、缓存结果。关键在于「前置增强」和「后置增强」的时机控制。
立即学习“C++免费学习笔记（深入）”；
典型陷阱是忘记异常安全：如果前置逻辑成功，但被装饰对象抛异常，后置逻辑（如资源释放）就没机会执行。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 用 RAII 封装前置动作（例如
Timer t;构造即开始计时，析构自动打点） - 若需捕获异常并处理，必须显式
try/catch，且注意不要吞掉原异常（除非明确要转换） - 避免在转发中修改
component的状态（如调reset()），这会破坏装饰器的无侵入性原则
示例：LoggingDecorator 的 execute() 实现：
void execute() override {
std::cout << "[LOG] Entering\n";
component->execute(); // 转发给下一层
std::cout << "[LOG] Exiting\n";
}
如何支持运行时动态叠加多个装饰器
靠构造顺序实现链式包裹：最外层装饰器持有内层装饰器的智能指针，内层再持更内层，最终指向真实对象。C++ 里这不是魔法，就是裸指针链表的 RAII 封装版。
容易踩的坑是内存管理混乱。有人用裸指针手动 new/delete，结果装饰器析构顺序错乱，或者某层提前释放了底层对象。
- 全部用
std::unique_ptr<Component>，确保所有权清晰、析构自动按包裹顺序逆向触发 - 创建链时从内到外构造：先
auto core = std::make_unique<realservice>();</realservice>，再auto timed = std::make_unique<timingdecorator>(std::move(core));</timingdecorator>，最后auto logged = std::make_unique<loggingdecorator>(std::move(timed));</loggingdecorator> - 别用
shared_ptr—— 它会隐式延长生命周期，导致装饰器退出后真实对象还活着，违背“装饰即临时增强”的语义
性能与 ABI 兼容性必须考虑的细节
每次调用都要经过虚函数表跳转，且装饰器层级越深，栈帧越多。对高频调用路径（如游戏循环里的 update），虚函数开销可能显著。
另一个隐形成本是 ABI 稳定性：一旦基类虚函数签名变动（比如加默认参数），所有派生类二进制都会失效。
- 高频场景可用模板策略替代虚函数（如
template<typename T> class TimingDecorator : public Component），但失去运行时组合能力 - 基类虚函数参数尽量用 const 引用或值传递，避免装饰器内部拷贝大对象
- 若需跨 DLL 使用，基类必须用
__declspec(dllexport)（Windows）或隐藏符号（Linux），否则虚表地址不一致
装饰器模式的价值从来不在“炫技”，而在于把横切关注点（日志、监控、重试）从核心业务里剥离开 —— 但剥离的前提，是你真的控制得了那条虚函数调用链的起点和终点。
