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 上下文未激活
基本上就这些。不复杂，但容易忽略注册和生命周期的对应关系。
