Angular 16中EventEmitter与signal对比：切换至signal有何优势？

• 更简洁的状态管理
  用Signal管理标记用户位置的布尔值，代码比EventEmitter清爽太多。原来你可能要写发射事件、订阅事件的一堆样板代码，现在直接定义const userLocation = signal<boolean>(false)，修改时调用userLocation.set(true)或者userLocation.update(prev => !prev)，组件里直接用userLocation()就读取到最新值，完全不用处理订阅那套流程。

• 自动处理订阅与更新
  Signal是Angular原生的反应式工具，值一变，依赖它的模板、计算信号（computed）或者副作用（effect）会自动更新，还不用手动取消订阅——这在服务里跨组件共享状态时特别有用，再也不用担心因为漏销毁订阅导致内存泄漏的问题，比EventEmitter省心太多。

• 数据流更清晰
  EventEmitter本质是RxJS Subject的封装，天生适合父子组件之间的单向通信（这也是官方指南还在用它的原因），但放到服务里做全局状态共享时，数据流绕来绕去的，不好追踪。而Signal的读写逻辑非常明确：定义、修改、读取三步一目了然，维护起来成本低很多。

• 更精准的性能优化
  Angular对Signal做了专门的优化，模板里用Signal的时候，只会更新依赖它的那部分DOM，不是整个组件树。相比之下，用EventEmitter加订阅的方式，要么用async管道，要么手动写订阅，更新粒度没那么精准，性能上略逊一筹。

官方“子与父指令及组件间的数据共享”指南还在用EventEmitter，是因为它专门对应父子组件单向通信的场景——子组件通过@Output()抛事件，父组件监听，完全符合组件间的边界规则，是组件通信的经典模式。而Signal更适合跨组件/服务的全局状态共享，或是组件内部的状态管理，两者是互补关系，不是谁替代谁。

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