ng-content与@Input的区别是什么？二者分别适用哪些场景？

二者解决的是完全不同的两类需求，核心差异可以归纳为3点：

• 传递内容类型不同
  @Input的本质是父子组件的数据通信，只能传递TS层面的变量：字符串、数字、布尔值、对象、函数都可以，但不能直接传递DOM结构。
  ng-content的本质是内容投影，传递的是完整的DOM模板内容，支持原生HTML、其他Angular组件、带绑定和事件的自定义模板。
• 上下文归属不同
  通过@Input传入子组件的数据，归属权在子组件，子组件可以直接对数据做校验、修改、监听变更（ngOnChanges）。
  投影到<ng-content>的内容，所有的变量绑定、事件回调都归属父组件上下文，哪怕渲染在子组件内部，用到的变量也是父组件的，子组件默认无法直接操作投影内容的内部逻辑。
• 灵活度特性不同
  @Input适合传递结构化、可枚举的参数，子组件可以设置默认值、必填校验，使用成本低，适合固定规则的参数传递。
  ng-content没有内容限制，子组件只需要预留插槽位置，不需要关心父组件传入的内容类型，灵活度极高，适合非结构化的内容传递。

优先用@Input的场景： #

• 传递的是子组件的配置参数、业务数据，比如卡片的标题文本、开关的状态、列表的数据源
• 子组件需要根据传入的值做内部逻辑处理，比如根据传入的size参数调整组件尺寸、根据传入的list数据做内部分页
• 传递的内容不需要自定义DOM结构，纯数据即可满足需求

优先用ng-content的场景： #

• 子组件的某部分内容结构不固定，需要父组件自定义，比如通用弹窗的内容区域、卡片的操作栏，每个业务场景下的结构都不一样，无法用固定的@Input覆盖所有情况
• 需要传递自定义交互、样式的内容，比如要在子组件插槽中放一个绑定了父组件点击事件的按钮，直接把按钮写在投影内容里即可，不需要额外传事件回调
• 开发通用容器类组件，比如布局组件、弹窗、下拉菜单、折叠面板等容器型组件

你示例里的纯文本标题场景，两种方式都可以实现，但如果后续需要给标题加图标、自定义颜色、甚至加跳转链接，用@Input就需要加大量额外的参数，用ng-content直接改投影内容即可，扩展成本低。实际开发中两者经常搭配使用，比如通用弹窗组件，用@Input传弹窗宽度、是否显示关闭按钮等配置，用ng-content传弹窗的自定义内容。

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