Angular服务中以只读方式暴露信号数组的最佳实践

在Angular服务中使用Signals管理数组数据时，我们常需要以只读方式将数据暴露给组件，避免外部篡改内部状态。先看基础代码：

@Injectable()
export class MyService {
  private _myObjects = signal<MyObject[]>([]);
}

目前有两种主流实现方案，各有优劣，以下是分析和最佳实践建议：

两种方案对比 #

方案一：使用asReadonly()标记只读 #

myObjects = this._myObjects.asReadonly();

• 优点：性能最优，信号更新时无额外拷贝开销；通过asReadonly()明确传递「只读」语义，给开发者清晰的使用提示。
• 缺点：无法强制约束——组件仍可通过push、splice等方法修改数组本身，或直接修改数组元素的属性，导致服务内部状态被意外篡改。

方案二：通过computed返回深拷贝 #

myObjects = computed(() => myDeepCopy(this._myObjects()));
// myDeepCopy 为任意深拷贝实现，比如structuredClone

• 优点：彻底阻断外部对内部状态的修改，每次信号更新都会返回全新的拷贝对象，外部修改不会影响服务内的原始数据。
• 缺点：性能损耗明显，尤其是数组元素多、结构复杂时，深拷贝会增加运行时开销；同时代码可读性下降，开发者可能困惑为何每次获取的都是新对象。

最佳实践选择 #

优先采用方案一（语义约束+信任开发者） #

如果团队有明确的代码规范，或组件开发者清楚「服务返回的只读数据不应修改」的约定，方案一是最优解：

• 配合TypeScript类型强化约束，将暴露的信号声明为ReadonlySignal<readonly MyObject[]>，让类型系统进一步提示不可修改：

  myObjects: ReadonlySignal<readonly MyObject[]> = this._myObjects.asReadonly();
  

• 这类约定性的约束在大部分团队场景下足够可靠，即使出现个别违规修改，也能通过代码审查或快速调试定位问题，属于可控风险。

仅在高敏感场景使用方案二 #

如果数组是核心业务状态（如支付数据、权限配置），绝对不允许外部篡改，或组件开发者不可控（如第三方组件、跨团队协作），才考虑方案二：

• 可优化性能：不在computed中实时拷贝，而是在服务内部更新信号时提前完成深拷贝，再暴露只读信号：

  updateMyObjects(newObjects: MyObject[]) {
    // 更新时提前拷贝，避免每次computed重复操作
    this._myObjects.set(structuredClone(newObjects));
  }
  
  myObjects = this._myObjects.asReadonly();
  

  这种方式既保证了状态安全，又避免了computed触发时的重复拷贝开销。

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