Angular 4 TypeScript：使用JSON替代类变量存储临时数据是否可行？

先给结论：有合理性，但坑不少 #

首先得说，这种做法在简单场景下是可行的：

• 比如你的组件就是个一次性的表单弹窗，拿后端数据出来改改临时状态（比如标记是否选中、编辑状态），提交完就销毁，那直接用这个类型化对象当容器确实省代码，而且类型校验还能避免回传时的类型错误，比瞎用any靠谱多了。
• 毕竟这个对象本来就是为和服务器交互设计的结构，复用它来存要回传的ID、状态这类数据，逻辑上也通顺。

但如果你的组件逻辑稍微复杂一点，或者项目需要长期维护，那潜在问题就会慢慢冒出来：

潜在问题 #

• 数据边界模糊，容易搞混前后端字段：你把后端返回的业务数据和前端临时状态（比如isEditing、tempFlag）混在同一个对象里，时间长了或者别人接手代码时，根本分不清哪些是后端定义的合法字段，哪些是你临时加的。万一哪天后端接口更新，加了个同名的字段，直接就冲突炸锅了。
• 变更检测失效，视图不更新：Angular的变更检测对对象引用变化更敏感，尤其是用OnPush策略的组件。如果你只是修改对象的某个属性（比如data.isActive = true），而不是替换整个对象的引用，很可能出现模板里的绑定不更新的情况——你改了值，但页面上没变化，排查起来贼头疼。
• 状态污染或内存泄漏：如果这个对象是Service里共享的（比如多个组件用同一个Service实例的同一份数据），那你在A组件里改的临时状态，会直接影响到B组件的状态，导致逻辑混乱。就算不是共享的，要是组件销毁不彻底，这个带临时数据的对象被意外持有，也可能引发内存泄漏。
• 回传数据冗余或报错：当你把这个对象传给服务器时，你临时加的那些字段也会被一起发过去。虽然很多后端会忽略未知字段，但要是后端做了严格的参数校验，直接就会返回参数错误；更糟的是，万一后端不小心把这些临时字段当成合法参数处理，会产生莫名其妙的业务bug。
• 可维护性差：组件的状态分散在外部对象里，而不是组件自己的类变量中，新开发者要理清组件的状态逻辑，得翻Service、翻类型定义，成本极高。要是你哪天忘了自己加过哪些临时字段，排查问题时更是一头雾水。

给你的优化建议 #

• 扩展类型，区分前后端字段：不要直接修改后端返回的类型，而是创建一个扩展类型，比如interface ComponentUser extends User { isEditing: boolean; tempId: number; }，这样既能复用后端的类型定义，又能清晰区分前后端的字段。
• 组件内部状态单独声明：把临时状态（比如布尔标记、临时ID）放在组件类的私有变量里，比如private _isEditing = false;，这样状态归属清晰，也不会污染后端对象。
• 用包装对象分离状态：如果确实需要把业务数据和临时状态绑定在一起，可以搞个包装对象：{ businessData: User, tempState: { isEditing: boolean } }，把两类数据彻底分开管理。
• 适配OnPush变更检测：如果组件用了OnPush策略，修改对象属性后记得调用ChangeDetectorRef.detectChanges()手动触发检测，或者用BehaviorSubject这类可观察对象来管理状态，确保视图能及时响应变化。

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