为何在Angular中优先使用@Input@Output而非Subject/Services？

核心优势（对比Subject/Service） #

• 组件依赖关系透明化：通过模板中的[inputProp]和(outputEvent)就能直观看到父子组件的数据流向，不用追踪服务中的订阅逻辑，维护时一眼理清组件交互关系，适配团队协作场景。
• 天然的作用域隔离：@Input/@Output的通信严格限定在直接父子组件之间，不会像全局Service那样存在数据被无关组件篡改或监听的风险；即使是局部Service，也需要额外配置注入作用域，不如@Input/@Output直接高效。
• 模板级别的便捷控制：可以直接在@Input装饰器里配置必填项（@Input({ required: true })）、默认值，还能在模板中配合管道对传入数据做预处理，这些逻辑用Subject/Service实现需要额外编写冗余代码。
• 契合Angular组件层级设计：Angular的组件树本身是层级化结构，@Input/@Output是为父子层级通信量身打造的方案，而Subject/Service更适合跨层级、非关联组件的通信，硬套在父子场景会增加不必要的复杂度。

与变更检测机制的关联 #

@Input/@Output确实和Angular的变更检测深度绑定，这也是它的核心优势之一：

• 自动触发变更检测：当父组件更新@Input的值时，Angular会自动在子组件的变更检测周期中识别值的变化并更新视图。而使用Subject的话，订阅回调中的数据更新不会自动触发变更检测，尤其是开启OnPush策略时，需要手动调用ChangeDetectorRef.markForCheck()或detectChanges()，容易遗漏导致视图不更新。
• 完美适配OnPush优化：配合OnPush变更检测策略时，只有当@Input的引用发生变化（或子组件自身事件触发），Angular才会触发子组件的变更检测，大幅提升性能。而用Subject的话，即使开启OnPush，订阅回调的更新无法被Angular自动识别，必须手动处理检测逻辑，增加出错概率。
• 无需手动管理订阅：使用Subject时，必须在组件销毁时手动取消订阅（比如通过takeUntil操作符），否则会造成内存泄漏。而@Input/@Output由Angular完全托管，组件销毁时会自动清理相关绑定，无需额外代码。

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