Angular核心机制01，深入理解Angular服务：@Injectable装饰器与核心作用-深圳市維司達科技有限公司

在Angular开发中，“服务”是一个高频出现的概念，也是实现组件间通信、共享业务逻辑的核心载体。而提到服务，就不得不提@Injectable装饰器——它是服务能够被依赖注入系统识别和使用的关键。很多初学者在使用服务时，常会疑惑：@Injectable到底有什么用？服务的核心价值是什么？什么时候需要配置providedIn属性？本文就带你逐一解开这些疑问，彻底搞懂Angular服务的本质。

一、先明确：Angular服务是什么？

从本质上讲，Angular服务就是一个普通的TypeScript类，它没有特殊的语法限制，主要用于封装“可复用的业务逻辑、数据处理、外部API调用”等代码。比如：用户登录逻辑、数据请求工具、全局状态管理等，都适合放在服务中。

举个最简单的服务示例：

// user.service.tsexportclassUserService{// 封装获取用户信息的逻辑getUserInfo(){return{id:1,name:'张三',age:25};}}

看到这里你可能会问：“这就是服务？和普通类有什么区别？” 没错，单看这个类，它和普通TS类毫无二致。但Angular服务的核心价值，不在于“类本身”，而在于Angular的依赖注入（Dependency Injection，简称DI）系统——服务通过依赖注入机制，实现了“跨组件共享”和“松耦合”，这才是服务的灵魂。

二、@Injectable装饰器：服务的“准入证”

刚才的UserService类，虽然能直接在组件中new出来使用（比如const userService = new UserService()），但这违背了Angular的设计理念，也无法享受依赖注入的优势。要让服务被DI系统管理，就必须给它加上@Injectable装饰器——这相当于给服务颁发了一张“准入证”，告诉Angular：“这个类是一个可注入的服务，你可以把它注入到其他组件或服务中”。

1. @Injectable的基本用法

给UserService添加@Injectable装饰器后，才是一个标准的Angular服务：

// user.service.tsimport{Injectable}from'@angular/core';@Injectable()// 核心：添加@Injectable装饰器exportclassUserService{getUserInfo(){return{id:1,name:'张三',age:25};}}

2. 关键配置：providedIn属性

@Injectable装饰器有一个核心配置项providedIn，用于指定服务的“注入范围”（即服务实例的生命周期）。它的取值主要有以下几种：

providedIn: ‘root’：最常用的配置。表示服务在整个应用中是单例的，由根注入器管理。无论哪个组件或服务注入它，得到的都是同一个实例。
providedIn: 某个模块（如providedIn: HomeModule）：服务仅在指定的模块中可用，实例由该模块的注入器管理。适合模块内部共享的服务。
不指定providedIn：需要在模块的providers数组中注册服务（如@NgModule({ providers: [UserService] })），否则会报错。这种方式是Angular早期的用法，现在更推荐使用providedIn。

推荐用法（root范围）：

@Injectable({providedIn:'root'// 服务在整个应用中单例})exportclassUserService{...}

3. 为什么必须加@Injectable？

可能有初学者尝试过：不加@Injectable，直接在组件的构造函数中注入服务，结果会报错。这是因为：

Angular的DI系统在注入服务时，需要先“识别”这个类是不是可注入的。@Injectable装饰器的核心作用，就是标记类为“可注入”，并告知DI系统如何创建和管理它的实例。如果没有这个装饰器，DI系统就无法识别该类，从而拒绝注入。

补充：在Angular 6之前，服务可以不加@Injectable，只要在模块的providers中注册即可。但从Angular 6开始，官方强制要求服务必须添加@Injectable装饰器，这是为了统一注入规范，也让服务的复用性更强。

三、服务的核心作用：解耦与共享

了解了@Injectable的作用后，我们再回到核心问题：为什么需要用服务？服务的核心价值体现在哪里？

一句话总结：服务是为了实现“业务逻辑复用”和“组件与逻辑解耦”。具体来说，有以下3个核心作用：

1. 组件间共享数据和逻辑

在Angular中，组件之间的直接通信（如父子组件、兄弟组件）往往比较繁琐（需要@Input、@Output、服务中转等）。而服务作为“全局单例”（当providedIn: 'root’时），可以轻松实现跨组件的数据共享。

示例：用服务共享用户状态

// user.service.ts@Injectable({providedIn:'root'})exportclassUserService{privatecurrentUser:any;// 共享的用户状态// 设置用户信息setUser(user:any){this.currentUser=user;}// 获取用户信息getUser(){returnthis.currentUser;}}

在组件A中设置用户信息：

// component-a.component.tsimport{Component}from'@angular/core';import{UserService}from'./user.service';@Component({...})exportclassComponentA{constructor(privateuserService:UserService){}login(){constuser={id:1,name:'张三'};this.userService.setUser(user);// 调用服务设置状态}}

在组件B中获取用户信息：

// component-b.component.tsimport{Component}from'@angular/core';import{UserService}from'./user.service';@Component({...})exportclassComponentB{currentUser:any;constructor(privateuserService:UserService){}ngOnInit(){this.currentUser=this.userService.getUser();// 调用服务获取状态}}

通过这种方式，无论多少个组件，只要注入UserService，就能共享同一个currentUser状态，实现了组件间的“无感通信”。

2. 封装重复的业务逻辑，减少冗余代码

如果多个组件都需要调用同一个API（比如获取用户列表），或者执行同一个逻辑（比如格式化时间），如果每个组件都写一遍代码，会导致大量冗余，后续维护也很麻烦。

此时，将这些重复逻辑封装到服务中，组件只需调用服务的方法即可，大大减少了代码冗余。

示例：封装API请求服务

// api.service.tsimport{Injectable}from'@angular/core';import{HttpClient}from'@angular/common/http';@Injectable({providedIn:'root'})exportclassApiService{constructor(privatehttp:HttpClient){}// 封装获取用户列表的APIgetUserList(){returnthis.http.get('/api/users');}// 封装添加用户的APIaddUser(user:any){returnthis.http.post('/api/users',user);}}

这样，所有需要获取用户列表的组件，只需注入ApiService，调用getUserList()方法即可，无需重复写HttpClient相关代码。

3. 实现组件与业务逻辑的解耦，便于测试

一个好的组件，应该只负责“视图渲染”和“用户交互”（比如点击事件、表单输入），而不应该包含复杂的业务逻辑（比如数据处理、API调用）。如果组件中混杂了大量业务逻辑，不仅代码臃肿，而且难以测试。

通过服务将业务逻辑抽离出去，组件只需要依赖服务，就能实现“视图”与“业务逻辑”的解耦。后续测试时，我们可以轻松地用“模拟服务”替换真实服务，而无需修改组件代码。

四、常见误区：服务一定要是单例吗？

很多人误以为Angular服务默认就是单例的，但其实不然——服务的实例数量，取决于它的“注入范围”（即providedIn的配置或providers的注册位置）。

单例服务：当providedIn: ‘root’，或在根模块（AppModule）的providers中注册时，服务是单例的，整个应用只有一个实例。
非单例服务：当服务在“特性模块”（如HomeModule）的providers中注册时，每个特性模块会创建一个独立的服务实例；如果特性模块被多次懒加载，还可能创建多个实例。

所以，服务是否是单例，完全由我们的配置决定。如果需要共享全局状态，就用单例；如果需要模块内部独立的状态，就用非单例。