Angular中对@Input()字段使用readonly是否为良好实践？

先说核心判断：在遵守Angular单向数据流原则的前提下，给@Input()装饰的字段加readonly是性价比很高的编码约束，算值得推广的小实践，但它有非常明确的局限性，不是所有场景都适合硬加。

为什么说它是值得用的实践？ #

Angular的单向数据流规则本身就要求：组件内部不应该主动修改父组件通过@Input传入的值，否则很容易出现父子组件状态不同步、变更检测乱序的难排查bug。
readonly是TypeScript提供的编译期约束，加了之后，如果你在组件类内部不小心给输入属性重新赋值，TS会直接在编码阶段飘红报错，根本不用等代码跑起来出问题才溯源，相当于零成本加了一道自动检查。
举个最常见的手滑场景：

@Component({
  selector: 'app-product-card',
  template: `<div>{{ productInfo.name }}</div>`
})
export class ProductCardComponent {
  @Input() readonly productInfo: Product;

  resetProduct() {
    // 手滑直接给输入属性整体重新赋值
    // 加了readonly之后这行直接编译报错，当场拦住低级错误
    this.productInfo = { id: 0, name: 'test' }; 
  }
}

对于多人协作的项目来说，这种小约束能减少很多没必要的低级失误。

它的弊端和局限性非常明显 #

别觉得加个readonly就给输入属性上了安全锁，它的问题一点不少：

• 它只是编译阶段的类型约束，运行时没有任何实际效力。Angular本身做变更检测、父组件传值更新的时候，给这个字段赋值完全不受影响；真要想绕过限制，加个as any类型强转就能随便改，本质是防君子不防小人。
• 会给部分合理场景添堵。比如动态创建组件时给实例传输入值、单元测试里直接覆写组件输入属性模拟场景、用ViewChild拿到组件实例临时调整输入值的场景，TS都会因为readonly标记报类型错误，你每次都得写类型断言绕，平白加冗余代码。
• 对引用类型的防护非常有限。如果输入值是对象、数组这类引用类型，readonly只会拦住你给整个字段重新赋值的操作，你修改对象内部属性、调用数组的push/splice等修改方法，TS根本不会报错。很多人误以为加了readonly就能彻底防止输入值被篡改，实际上完全做不到。
• 对规范不统一的团队反而起反效果。如果团队本身对单向数据流的要求不严格，很多人习惯拿到输入值直接在本地改，加了readonly之后，大家为了过TS检查会到处写as any强转，反而把代码搞的更乱。

实际落地建议 #

团队如果已经严格执行“组件内部不修改@Input传入值”的规范，完全可以给所有普通@Input字段加readonly，零成本加一层编译检查；如果项目里动态创建组件、测试覆写输入的场景很多，或者团队对TS特性的熟悉度参差不齐，不加也完全不是问题，没必要为了凑“最佳实践”的名头硬加。

内容的提问来源于stack exchange，提问作者Matthieu Riegler