---
title: "Signal状态和Form"
date: "2026-04"
category: "Angular"
tags: ["Angular"]
description: "Angular有一个地方和React不太一样，这里的属性变动本身就会触发重新渲染，在React那边就必须要状态。而另一个方面则是这里的服务函数，这个是全局单例，所有组件共享状态..."
source: "https://enriquemark.com/zh-hans/posts/Signal%E7%8B%80%E6%85%8B%E5%92%8CForm"
---

Angular有一个地方和React不太一样，这里的属性变动本身就会触发重新渲染，在React那边就必须要状态。而另一个方面则是这里的服务函数，这个是全局单例，所有组件共享状态。不过官方的推荐写法还是写到Signal里，不然直接属性更新会遍历检查，有性能开支，未来可能会删掉这种因为属性更改而触发的渲染更新了。但即便如此，Signal和State也还是不同的，我在[MVC和MVVM](/zh-hans/posts/MVC和MVVM)那里说到过这点，那就是DOM全局检查这方面，React的性能开支还是比Signal大的，后者是直接定位。

而除此之外这里还有一个点，那就是作为状态的Signal，和作为资料储存结构的form——这两者是有自身单独的使用场景的。如果不涉及到数据，而只是单纯的UI状态识别，那就应该用Signal，这是字面意义上的「渲染的信号」。而数据则不然，虽然数据也可以塞到Signal里，但如果要对其进行核验那就得自己写一系列检查方法，这里反倒不如用官方封装好的form。况且，如果我要把数据绑定到html，那form天然双向绑定和良好的支持都是更合适的选择。

也就是需要验证，需要送api，需要提交的「数据」，使用form是最佳的。上述之外，单纯的绑定到表单的渲染状态，或者是某种暂存的数据——最终要同步到form——去的，就用Signal会比较没问题。

滥用Signal和滥用form没什么本质区别，比如把数据往Signal里塞（从React转过来，把这个直接当state用）；或者是反过来把比渲染状态都塞到form里。最终造成职责和边界都不清晰，混在一起，简直是地狱绘图。会造成很大的维护负担，长久成为技术债。
