Blazor依赖注入是框架级基础设施，服务需在Program.cs中按生命周期注册（Singleton/Scoped/Transient），组件用@inject或构造函数注入，自定义服务须接口+实现+注册闭环，Scoped在WebAssembly中按标签页隔离。
Blazor 依赖注入（DI）不是可选项，而是框架级基础设施——所有服务都通过统一容器管理，组件不手动 new 实例，也不硬编码依赖，解耦、可测、易维护。
服务注册：在 Program.cs 里集中配置
Blazor WebAssembly 和 Blazor Server 都使用 Program.cs（而非旧版 Startup.cs）注册服务。注册时需明确生命周期，这是关键细节：
- Singleton：整个应用生命周期只创建一次实例，适合无状态工具类、全局配置、缓存管理器
- Scoped：Blazor WebAssembly 中按浏览器标签页隔离；Blazor Server 中按 SignalR 连接（即用户会话）隔离；适合带上下文状态的服务，如购物车、表单状态管理器
- Transient：每次请求服务时都新建实例，适合轻量、无共享状态的工具类（如日志记录器、随机数生成器）
示例（Program.cs）：
builder.Services.AddSingletonbuilder.Services.AddScoped
builder.Services.AddTransient
服务注入：两种方式，按场景选
组件中用 @inject 最直接；普通 C# 类（如服务内部依赖其他服务）必须用构造函数注入。
- @inject 指令：写在 .razor 文件顶部，语法简洁，适用于 Razor 组件
- 构造函数注入：用于服务类、处理器类等非组件类，Blazor 自动解析依赖链
示例（Index.razor）：
@page "/"
@inject ICartService Cart
@inject ICounterService Counter
购物车数量：@Cart.ItemCount
自定义服务：接口 + 实现 + 注册三步走
写一个真正可用的服务，要闭环：
- 先定义接口（如
ICartService），明确契约 - 再实现类（如
CartService），处理具体逻辑（注意线程安全和状态隔离） - 最后在 Program.cs 中注册，并指定生命周期（通常购物车用 Scoped）
特别提醒：Scoped 服务在 WebAssembly 中不会跨标签页共享，同一标签页内多个组件注入的是同一个实例——这点常被误认为“不生效”，其实是设计如此。
常见问题快速排查
注入失败？多半是这几种情况：
- 服务未注册（检查 Program.cs 是否漏掉
AddScoped等调用） - 注入类型与注册类型不匹配（比如注册了
CartService，却@inject ICartService，但接口没被注册） - 在生命周期不兼容的上下文中使用（例如把 Transient 服务存到 Singleton 类里，导致状态污染）
- 组件未继承 ComponentBase 或未正确标记为 @page，导致 DI 上下文未激活
基本上就这些。不复杂，但容易忽略注册和生命周期的对应关系。
