Angular类装饰器重写ngOnInit时自定义逻辑未执行的问题排查与修复方案咨询

我来帮你排查这个问题，看起来你的装饰器确实修改了组件的ngOnInit方法，但自定义逻辑没执行，这确实有点奇怪。从你的控制台输出能看到：组件自身的ngOnInit逻辑先跑了，之后打印的this.ngOnInit却是装饰后的函数——这说明装饰器确实修改了原型上的方法，但Angular调用的是未被修改前的ngOnInit版本。

下面是可能的原因和对应的修复方案：

• 调整装饰器执行顺序
  Angular的@Component装饰器会处理组件元数据，当前你把@VisibilityTracked放在@Component下方，按照TypeScript装饰器从下到上的执行顺序，自定义装饰器会先于@Component执行。虽然理论上类定义完成后原型方法就存在，但保险起见可以调换顺序试试：

  @VisibilityTracked(availableComponents.ROOM_MENU)
  @Component({
    // ...组件配置项
  })
  export class MenuComponent implements OnInit, OnDestroy {
    // ...组件代码
  }
  

• 改用Object.defineProperty修改原型方法
  直接给target.prototype.ngOnInit赋值可能会被Angular内部机制覆盖，用Object.defineProperty可以更可靠地修改原型方法，同时明确属性描述符：

  export function VisibilityTracked(component: availableComponents): ClassDecorator {
    return function (target: any) {
      const originalNgOnInit = target.prototype.ngOnInit;
      
      Object.defineProperty(target.prototype, 'ngOnInit', {
        value: function(...args) {
          console.log('custom_logic');
          // 确保原始方法存在再调用，避免报错
          if (originalNgOnInit) {
            originalNgOnInit.apply(this, args);
          }
        },
        writable: true,
        configurable: true
      });
    };
  }
  

• 排查其他装饰器的干扰
  如果你的组件还应用了其他装饰器，它们可能也修改了ngOnInit方法，导致你的自定义逻辑被覆盖。可以暂时移除其他装饰器，单独测试你的自定义装饰器是否正常工作。

• 验证装饰器的执行时机
  你可以在装饰器里加日志，确认它是否在组件类定义时就执行了：

  export function VisibilityTracked(component: availableComponents): ClassDecorator {
    console.log('VisibilityTracked装饰器已执行');
    return function (target: any) {
      console.log('开始修改ngOnInit原型方法');
      const originalNgOnInit = target.prototype.ngOnInit;
      
      target.prototype.ngOnInit = function(...args) {
        console.log('custom_logic');
        originalNgOnInit.apply(this, args);
      };
    };
  }
  

  如果这些日志没在应用启动时出现，说明装饰器没有被正确加载或应用。

另外提个小建议：组件类名最好遵循大驼峰命名法（比如MenuComponent而非menuComponent），虽然不影响功能，但符合Angular的编码规范。

备注：内容来源于stack exchange，提问作者Kirill