Decorator 模式在 C# 中需通过接口+组合+手动委托实现，不可继承被装饰类；装饰器须实现相同接口并持有内层实例，支持链式叠加与顺序控制，需正确处理 Dispose/async/生命周期。
Decorator 模式在 C# 里不是靠语法糖，得靠接口 + 组合 + 手动委托
它没有像 Python 的 @decorator 那种语言级支持，也不是靠特性（[Decorator]）自动注入——C# 里你得自己写接口、实现类、把原对象包进去，再一层层转发调用。
常见错误是直接继承被装饰类（比如让 LoggingFileReader 继承 FileReader），结果破坏了“开闭原则”：新增日志逻辑就得改所有子类；更糟的是，一旦被装饰类是 sealed 或来自第三方库，继承就彻底走不通。
正确做法是让装饰器和被装饰对象实现同一个接口，装饰器内部持有一个该接口的实例：
public interface IDataReader
{
string Read();
}
<p>public class FileDataReader : IDataReader
{
public string Read() => "raw content";
}</p><p>public class LoggingDecorator : IDataReader
{
private readonly IDataReader _inner;
public LoggingDecorator(IDataReader inner) => _inner = inner;</p><pre class="brush:php;toolbar:false;">public string Read()
{
Console.WriteLine("Before read...");
var result = _inner.Read();
Console.WriteLine("After read.");
return result;
}}
多个装饰器叠加时，顺序决定行为执行流
装饰器本质是链式调用，谁包在最外层，谁的逻辑就最先触发。比如 new CompressionDecorator(new LoggingDecorator(new FileDataReader()))，调用 Read() 会先进 CompressionDecorator.Read()，再进 LoggingDecorator.Read()，最后才到真实读取。
容易踩的坑是把顺序写反，或者误以为装饰器之间能互相感知——它们彼此完全隔离，只认自己持有的 _inner 实例。
- 想加缓存？写一个
CacheDecorator，它必须自己管理Dictionary<string string></string>或类似结构 - 想做权限检查？
AuthDecorator要在调用_inner.Read()前 throwUnauthorizedAccessException - 别在装饰器里 new 具体实现类，否则耦合死；用构造函数注入或工厂方法
泛型装饰器能复用，但要注意约束和协变/逆变
如果你有一堆 ITransformer<t></t>、IValidator<t></t> 接口，可以写一个通用基类：
public abstract class Decorator<T> : ITransformer<T>
{
protected readonly ITransformer<T> Inner;
protected Decorator(ITransformer<T> inner) => Inner = inner;
<pre class="brush:php;toolbar:false;">public virtual T Transform(T input) => Inner.Transform(input);}
但注意：T 默认是非协变的，不能把 Decorator<string></string> 当作 Decorator<object></object> 用；如果接口本身声明为 ITransformer<out t></out>，且你只在返回值用 T，那才能安全协变。
性能上没明显损耗，就是多一次虚方法调用+对象引用跳转；但若装饰器层级过深（比如 10 层以上），栈深度和对象分配量会上升，生产环境要留意。
别忘了 Dispose 和 async 场景下的装饰器适配
如果被装饰对象实现了 IDisposable 或 IAsyncDisposable，装饰器也得实现——而且必须确保 Dispose() 会传递给 _inner，否则资源泄漏。
async 方法更易出错：有人直接在 async Task<string> ReadAsync()</string> 里 await 两次，却忘了把 await 后的异常重新 throw 出去，导致上层捕获不到原始错误。
- 装饰器的
Dispose()必须调用_inner.Dispose()，建议用try/finally包裹 - async 装饰器里不要用
.Result或.Wait()，否则可能死锁 - 如果
_inner是IAsyncDisposable，装饰器也要实现它，并在DisposeAsync()里 await_inner.DisposeAsync()
最常被忽略的是：装饰器本身是否该参与生命周期管理。比如你用 DI 容器注册了 LoggingDecorator，它的生命周期（Scoped/Transient）必须和 _inner 匹配，否则可能拿到已释放的对象引用。
