Angular下NGXS选择器数据被修改时无需派发Action就变更原状态的问题

核心问题根因 #

你遇到的“未派发Action就直接改动全局状态”的现象，本质是浅拷贝没有完全切断数据和原状态的引用关联：

• 你写的return [...state]仅新建了一个装载用户的空数组，数组内每个User元素的内存引用，仍然指向原状态中存储的同一对象。通过ngModel绑定修改对象属性时，实际修改的就是原状态里的对象内容，自然会直接改动全局存储。

对应疑问的明确解答 #

1. 「选择器应当只读、不能通过选择器修改状态」的认知是否正确 #

这个认知完全符合NGXS的设计规范。
NGXS遵循单向数据流的状态管理规则，核心要求就是全局状态不可直接修改，所有状态变更必须通过派发Action、在对应State的Reducer逻辑中完成。选择器的定位只是从全局存储中派生出视图可消费的只读数据，本身不具备修改状态的能力。你遇到的问题不是选择器打破了只读规则，是派生返回的数据没有切断和原状态的引用关联，让你的编辑操作意外落到了原状态的对象上。

2. 调整为return state.map(user=>Object.assign({}, user))后仍未解决问题，这种写法是否正确 #

从设计思路上，这种写法是定义选择器的合规方式，不生效通常是两个常见疏漏导致的：

• 选择器默认带记忆缓存机制。如果你修改选择器内部逻辑后，全局状态没有发生新的变更，选择器不会重新执行内部拷贝逻辑，仍然会返回之前缓存的旧引用数据，你可以临时对状态做一次无业务逻辑的触发，或临时关闭选择器缓存验证效果。
• 如果你的User对象存在嵌套属性（比如关联的个人资料、权限列表等），仅对User本身做Object.assign浅拷贝，嵌套属性的引用仍然和原状态共享，修改这类嵌套属性时依然会直接改动原状态。

3. 选择器的使用逻辑是否存在根本性认知偏差 #

存在场景层面的认知错位：
你把组件编辑场景需要的临时数据拷贝逻辑，放到了全局共享的选择器层实现，这不符合NGXS的最佳实践：

• 全局选择器是给所有依赖这个状态的组件共享派生数据的。如果在选择器里每次计算都为每个User生成全新的拷贝对象，会产生大量不必要的内存开销，还会因为引用频繁变化拖慢选择器的变更检测效率。
• 正确的组件内编辑流程边界是：
  • 从选择器拿到只读的全局用户列表数据，仅作为数据源参考
  • 在组件内部对需要编辑的条目做一次完整拷贝，存为组件本地的临时编辑变量
  • 用ngModel绑定这个本地临时变量做编辑交互
  • 用户点击保存时，将编辑完成的对象通过派发Action提交给全局状态，由Reducer完成状态更新
    这种方式既可以完全避免意外修改原状态，也不会给全局选择器增加无意义的拷贝开销。

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