Angular表单初始化永久不更新的值是否属于不良实践？

你当前采用全量初始化表单、直接提交表单值的写法在给定约束下是可运行的，不属于反模式，但存在优化空间，并非最稳妥的实现。

首先明确已知前提：

export interface Person {
  name: string;
  surname: string;
  dateOfBirth: Date;
}

• dateOfBirth 为不可编辑字段，仅name、surname开放给用户修改
• 后端接口固定按Person完整结构收发数据，接口规则不可调整

你当前的写法要正常跑通，首先要避开一个Angular响应式表单的常见坑：
如果你给dateOfBirth对应的表单控件设置了disabled: true，默认情况下this.form.value不会返回禁用控件的值，提交时会缺失dateOfBirth字段，不符合后端要求。这种场景下要么给控件加readonly属性而非disabled，要么提交时用this.form.getRawValue()获取包含禁用控件在内的全量值。

现有写法的弊端主要有三点：

• 表单会对永远不会变动的字段做无意义的值变更检测、状态校验，虽然性能影响微乎其微，但属于冗余逻辑
• 没有做字段层面的防篡改隔离，如果后续开发中误给dateOfBirth绑定了可编辑输入控件、或者被其他逻辑改了控件值，提交时会把篡改后的值传给后端
• 后续接口新增不可编辑字段时，必须同步给表单添加对应控件，否则会出现提交字段缺失的问题，维护成本更高

根据项目的实际场景，可以二选一：

方案1：保留不可编辑字段的表单控件（适合字段少、后续可能放开字段编辑权限的场景） #

如果不想改动现有逻辑，只需要补两个防护点即可：

• 不可编辑字段如果用disabled标记，提交时统一用getRawValue()取值；如果用readonly标记，直接取form.value即可
• 给不可编辑字段加自定义校验，强制校验控件值和接口返回的初始值完全一致，从代码层拦截非预期的字段篡改
  示例代码：

// 拉取到接口数据后存一份原始值快照
this.originalPerson = person;
// 初始化全量表单
this.form = this.fb.group({
  name: [person.name, Validators.required],
  surname: [person.surname, Validators.required],
  dateOfBirth: [{value: person.dateOfBirth, disabled: true}, (control) => {
    // 校验不可编辑字段值和原始值一致
    return control.value.getTime() === this.originalPerson.dateOfBirth.getTime()
      ? null
      : { immutableFieldChanged: true }
  }]
})

// 提交逻辑
const submitData = this.form.getRawValue();
this.api.post("mockApi/persons", submitData, httpOptions)

方案2：表单仅保留可编辑字段，提交时合并原始值（推荐） #

这种方案完全符合Angular表单的设计逻辑，从根源避免不可编辑字段被篡改的风险，长期维护成本更低：

1. 接口拉取到person数据后，单独存一份原始对象的引用，专门保存所有不可编辑字段
2. 初始化表单时，只把需要用户编辑的name、surname字段加入表单模型，不需要给dateOfBirth创建表单控件
3. 提交时，先展开原始对象的全量字段，再用表单里的可编辑值覆盖对应属性，组装成符合后端要求的结构再提交
   示例代码：

// 存接口返回的原始数据
this.originalPerson = person;
// 仅初始化可编辑字段
this.form = this.fb.group({
  name: [person.name, Validators.required],
  surname: [person.surname, Validators.required]
})

// 提交时组装数据
const submitData: Person = {
  ...this.originalPerson, // 带入所有不可编辑字段
  ...this.form.value // 覆盖为用户编辑后的最新值
}
this.api.post("mockApi/persons", submitData, httpOptions)

注意：合并对象时必须把原始对象放在前面、表单值放在后面，避免原始值覆盖用户修改后的内容。

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