Blazor中不同渲染模式组件的状态共享实现问题

完全可行，你的问题核心出在服务注册的生命周期配置上，导致每次API请求都会生成新的CounterStateService实例，状态无法持久化。

问题根源 #

你当前的CounterStateService大概率是默认注册为Scoped或Transient模式：

• Scoped服务在Blazor Server中按单个SignalR连接实例化，而通过HTTP API调用时，每个请求都会创建新的Scoped实例；
• Transient服务则是每次注入都会生成新实例。
  两种模式都会导致CurrentCount随请求重置为初始值。

解决方案 #

1. 将状态服务注册为Singleton

在服务端Program.cs中，把CounterStateService注册为单例模式，确保整个应用生命周期内只有一个实例：

builder.Services.AddSingleton<CounterStateService>();

2. 修正API接口实现

注入单例服务后，直接操作实例状态即可，无需担心请求重置问题：

[ApiController]
[Route("api/[controller]")]
public class CounterStateController : ControllerBase
{
    private readonly CounterStateService _counterStateService;

    public CounterStateController(CounterStateService counterStateService)
    {
        _counterStateService = counterStateService;
    }

    [HttpGet]
    public IActionResult GetCurrentCount()
    {
        return Ok(_counterStateService.CurrentCount);
    }

    [HttpPost("increment")]
    public IActionResult Increment()
    {
        _counterStateService.CurrentCount++;
        return Ok(_counterStateService.CurrentCount);
    }
}

3. 保证WebAssembly组件状态同步

WebAssembly端的<Counter />组件无法直接访问后端服务实例，需通过以下方式同步状态：

• 每次操作后调用API拉取最新CurrentCount；
• 引入SignalR Hub，当服务端状态变更时主动推送给所有连接的客户端（包括Server模式的<CounterPresenter />和Wasm模式的<Counter />）。

4. 线程安全处理（可选）

Singleton服务会被多个请求同时访问，需保证状态操作的线程安全，可使用Interlocked类：

public class CounterStateService
{
    private int _currentCount;
    public int CurrentCount
    {
        get => _currentCount;
        set => Interlocked.Exchange(ref _currentCount, value);
    }

    public void Increment()
    {
        Interlocked.Increment(ref _currentCount);
    }
}

特殊场景说明 #

如果需要实现用户级别的私有状态（而非全局共享状态），则不能使用Singleton，需改用分布式缓存（如Redis）或数据库存储状态，让两种渲染模式的组件通过统一数据源访问状态。

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