Hey there! Let's break this down clearly since you're navigating Angular 5 and feeling stuck on custom event binding with @Input and @Output.

能不能跳过@Input/@Output先学服务？ #

短期来看，你确实可以先上手服务实现组件通信——毕竟服务的跨组件能力很强，能解决不少场景的问题。但长期来看，跳过这部分会埋下隐患，因为@Input和@Output是Angular组件架构的基础核心，它们的设计是为了解决特定场景的通信需求，而服务无法完全替代它们。

为什么服务不能完全替代@Input/@Output？ #

两者的适用场景完全不同，举几个实际例子你就懂了：

• @Input/@Output是为直接父子组件通信设计的：比如你有一个父组件，里面嵌套了一个展示用户头像的子组件，父组件需要把用户的头像URL传给子组件——用@Input直接绑定数据，代码清晰又直观，完全不需要服务介入。如果硬用服务，你得在父组件里把URL存入服务，子组件再从服务里取，反而多了不必要的复杂度。
• @Output是子组件向父组件传递事件的标准方式：比如子组件是一个"删除"按钮，点击后需要通知父组件删除对应数据。用@Output触发一个自定义事件，父组件直接监听这个事件就行，逻辑一目了然。要是用服务，你得在子组件里调用服务的方法，父组件还要订阅服务的事件，这对于简单的父子交互来说纯粹是过度设计。
• 服务更适合跨层级/全局通信：比如两个没有直接父子关系的兄弟组件，或者分散在应用不同角落的组件需要共享用户登录状态，这时候用服务（结合RxJS的Subject）才是更合理的选择。

给你的学习建议 #

1. 别完全跳过@Input/@Output：花1-2天写几个极简示例，比如：
   • 父组件通过@Input给子组件传递一个字符串，子组件显示出来
   • 子组件通过@Output触发一个点击事件，父组件接收后更新自己的内容
     这些小例子能帮你快速理解Angular的组件数据流逻辑，这是后续学习更复杂功能的基础。
2. 学完基础的@Input/@Output再上手服务：当你搞清楚父子组件的直接通信后，再去学习服务的依赖注入、状态共享，就能清晰区分两者的适用场景，不会在实际项目里乱用。

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