你是否曾羡慕过Java或Python开发者那种优雅的注解写法？那种在不修改原有代码逻辑的情况下就Neng给类或方法“附魔”的Neng力，简直就像是编程界的魔法。别担心，TypeScript也为我们带来了这根魔杖——装饰器。今天我们就抛开那些枯燥的教科书式定义，像老朋友聊天一样，深入剖析一下TS装饰器的使用与原理。

说实话，hen多初学者一kan到代码里到处dou是 `@` 符号，心里多少会发怵。这玩意儿到底是个啥？其实当你拨开它神秘的面纱，你会发现它本质上就是一种特殊的函数调用。没错，装饰器本质就是语法糖，在编译阶段，TS编译器会把这些花哨的符号转换成普通的JavaScript函数调用。理解了这一点，你就Yi经成功了一半。

一、 装饰器工厂：定制你的魔法药水

在正式进入各种装饰器类型之前，我们得先聊聊“装饰器工厂”。这听起来hen高大上，其实逻辑hen简单。普通的装饰器就像是一个预设好的技Neng，直接用就行。但有时候，我们希望这个技NengNeng带点参数，比如“给这个方法加个日志，日志级别是Error”。

这时候就需要工厂模式了。它其实就是一个返回函数的函数。你Ke以把它想象成一家生产装饰器的作坊，你给它原材料，它给你生产出对应的装饰器。

// 这就是一个典型的装饰器工厂
function createMagicSpell { 
    // 接收参数，返回真正的装饰器函数
    return function  { 
        console.log;
        // 在这里Ke以操作 target
    }
}
// 使用的时候，我们带上括号，像调用函数一样
@createMagicSpell
class Wizard {
    // ...
}

kan到没？这种写法让我们的装饰器变得极其灵活，不再是死板的代码块，而是Ke以根据配置动态变化的逻辑。

二、 类装饰器：重塑构造函数

类装饰器，顾名思义，它是用来“装饰”类的。它会在类声明之前被调用，紧贴着类定义。这个装饰器的威力非常大，因为它接收的参数是类的构造函数。

这意味着什么？意味着你Ke以替换掉整个类的构造函数，或者修改它的原型链。比如你想把某个类彻底“封印”起来不允许任何人后续添加或删除属性：

function sealed {
    // 封印对象本身
    Object.seal;
    // 封印原型
    Object.seal;
}
@sealed
class Greeter {
    greeting: string;
    constructor {
        this.greeting = message;
    }
    greet {
        return "Hello, " + this.greeting;
    }
}

在这个例子里`@sealed` 就像给 `Greeter` 类加了一个保护罩。Ru果类装饰器有返回值，并且这个返回值是一个新的构造函数，那么原来的类就会被这个新构造函数完全覆盖。这招在Zuo一些库的底层封装时特别好用，但也得小心别把原本的逻辑搞丢了。

三、 方法装饰器：拦截与篡改

Ru果说类装饰器是宏观调控，那方法装饰器就是微观拦截。它应用在方法的属性描述符上，Ke以用来监视、修改甚至彻底替换方法的实现。

想象一下你有一个核心业务方法，你想在不改动它内部一行代码的情况下记录它的执行时间，或者校验参数。方法装饰器就是为此而生的。它接收三个参数：类原型、方法名和属性描述符。

function LogMethod {
    // 先把原始方法存起来
    const originalMethod = descriptor.value;
    // 重写 descriptor.value
    descriptor.value = function  {
        console.log;
        console.log;
        const start = Date.now;
        // 执行原始方法，绑定 this
        const result = originalMethod.apply;
        const end = Date.now;
        console.log;
        console.log;
        return result;
    };
}
class BattleSystem {
    @LogMethod
    attack: string {
        console.log;
        return `造成 ${damage} 点伤害`;
    }
}
const warrior = new BattleSystem;
warrior.attack;

这段代码跑起来你会发现每一次调用 `attack`，dou会被我们的装饰器包裹一层。这就是AOP在JS/TS中的体现，优雅且解耦。

四、 访问器装饰器：守卫Getter与Setter

访问器装饰器用得相对少一点，但它简直是神器。它作用于 getter/setter，参数和方法装饰器一样。

比如我们想监控某个属性被读取或修改的痕迹：

function AccessLog {
    const getter = descriptor.get;
    const setter = descriptor.set;
    if  {
        descriptor.get = function  {
            console.log;
            return getter.call;
        };
    }
    if  {
        descriptor.set = function  {
            console.log;
            setter.call;
        };
    }
}
class UserAccount {
    private _secret: string = "123456";
    @AccessLog
    get secret: string {
        return this._secret;
    }
    set secret {
        this._secret = val;
    }
}
const user = new UserAccount;
user.secret = "abcdef"; // 触发监控日志
console.log; // 触发监控日志

五、 属性装饰器：标记的艺术

属性装饰器比较特殊，它只有两个参数：原型对象和属性名。注意到了吗？它没有属性描述符！这是因为在TS中，属性描述符是在实例创建时才确定的，而装饰器是在编译阶段运行的。

所以属性装饰器通常不直接用来修改属性本身，而是用来“打标签”。比如我们Ke以标记某个字段是“只读”的，或者标记某个字段需要参与ORM映射。

// 这是一个简单的只读标记实现
function ReadOnly {
    // 这里我们利用 Object.defineProperty 来强行定义
    // 注意：这通常需要配合元数据使用会geng强大
    Object.defineProperty(target, propertyKey, {
        writable: false
    });
}
class Hero {
    @ReadOnly
    id: number = 9527; // 一旦定义，后续不可修改
}

六、 参数装饰器：精准定位

参数装饰器是所有装饰器里Zui“内向”的一个。它声明在参数前面接收的参数包括：原型、方法名和参数索引。

单独使用参数装饰器其实Zuo不了太多事，它主要是用来配合元数据的。比如在依赖注入框架中，我们经常kan到 `@Inject private serviceA: ServiceA` 这样的写法。这里的参数装饰器就是告诉框架：“嘿，构造函数的第0个参数，请帮我注入名为 ServiceA 的东西。”

function Required {
    console.log} 的第 ${parameterIndex} 个参数是必填的`);
}
class Validator {
    validate {
        // ...
    }
}

七、 装饰器的执行顺序：洋葱模型的秘密

这是Zui让人头秃的地方，也是面试官Zui爱问的考点。当你把类装饰器、方法装饰器、参数装饰器混在一起用的时候，它们到底是谁先跑？

记住一个核心原则：由内向外由下至上。但这还不够准确，因为不同类型的装饰器执行时机略有不同。

我们Ke以出以下规律：

参数装饰器Zui先执行，而且是从Zui后一个参数往前执行。

紧接着是方法装饰器。

Ru果有多个方法装饰器，它们会像俄罗斯套娃一样，先执行后面的，再执行前面的。

然后是属性装饰器。

Zui后才是类装饰器。

别被这些文字绕晕了我们来kan一段非常直观的代码，把顺序打印出来你就全明白了：

function ClassDec {
    console.log;
}
function PropDec {
    console.log;
}
function MethodDec {
    console.log;
}
function ParamDec {
    console.log`);
}
@ClassDec
class OrderTest {
    @PropDec
    name: string;
    constructor {
        console.log;
    }
    @MethodDec
    run {
        console.log;
    }
}
// 实例化类，触发所有逻辑
const test = new OrderTest;
test.run;

运行这段代码，你会发现控制台的输出顺序非常有趣。参数装饰器总是Zui先被处理，就像是在准备食材；然后是方法和属性装饰器，它们在搭建舞台；Zui后类装饰器才登场，像是大幕拉开。而到了实际方法调用时方法装饰器的逻辑又会反过来执行。

八、 ：何时使用这把双刃剑？

TypeScript的装饰器确实强大，它让我们Neng以一种声明式的方式编写代码，极大地提升了代码的可读性和复用性。特别是在写框架、中间件、自动化日志、权限校验以及依赖注入时它简直是不可或缺的神器。

但是凡事dou有两面性。过度使用装饰器会让代码逻辑变得隐晦，新手kan代码时可Neng完全不知道发生了什么因为逻辑dou被隐藏在那些 `@` 符号背后了。而且，由于装饰器目前还处于实验性阶段，配置起来有时候也挺麻烦的。

所以我的建议是：在业务逻辑中慎用，在基础架构中多用。当你发现有一堆重复的样板代码在各个类里复制粘贴时那就是装饰器该出场的时刻了。希望这篇文章Neng帮你真正理解TS装饰器的魅力，下次写代码时不妨试着挥舞一下这根魔杖！

---