Blazor Server与WASM无法直接共享状态，因运行环境完全隔离；必须通过后端API、浏览器存储或SignalR等显式通信机制实现协同同步，而非依赖静态类、CascadingParameter等单端机制。
Blazor Server 和 WASM 不能直接共享状态
Blazor Server 和 Blazor WebAssembly 是两种完全不同的运行模型：Server 状态驻留在服务器内存中，WASM 状态运行在浏览器沙箱里。二者没有共用的进程、堆或网络通道，static 类、Singleton 服务、本地内存变量全部彼此隔离。试图靠“同一个类库引用”让两者同步状态，一定会失败。
跨模式状态同步必须走显式通信层
真正可行的方案是把状态“外提”，让两端都通过同一套接口读写——本质是放弃“共享”，转为“协同”。常见路径有三种：
- 使用后端 API（如 ASP.NET Core Web API）作为唯一真相源，Server 和 WASM 都通过
HttpClient轮询或订阅（SignalR）更新本地视图状态 - 借助浏览器存储（
localStorage或sessionStorage）做轻量级跨页面/跨会话缓存，适合用户偏好、表单草稿等非强一致性场景 - 在 Blazor Server 中启用 SignalR Hub，并让 WASM 客户端连接该 Hub（需暴露跨域支持），实现双向实时通知（注意：WASM 连接的是同一个 Hub，不是 Server 的内存）
例如，WASM 端调用 hubConnection.InvokeAsync("UpdateCounter", newValue)，Server 端在 Hub 方法里持久化到数据库或 Redis，再广播给其他在线客户端——状态同步靠的是消息，不是引用。
别误用 CascadingParameter 或 StateHasChanged() 跨环境传值
这些机制只在单个 Blazor 组件树内有效：CascadingParameter 无法穿透 HTTP 边界，StateHasChanged() 只触发当前组件重渲染，对另一端毫无影响。常见错误包括：
- 在 Shared 类库中定义
public static class AppState { public static int Count; }，以为 Server 和 WASM 引用它就能同步——实际是两份独立静态字段 - 把
NavigationManager.NavigateTo当作状态传递手段，漏掉 URL 编码/长度限制和敏感信息泄露风险 - 在 Server 端修改
DbContext实例后，期待 WASM 自动感知——必须显式触发数据拉取
复杂状态建议用 MediatR + 事件溯源思路建模
当状态变更逻辑多、涉及校验或副作用（如发邮件、更新审计日志），硬编码 HTTP 调用容易失控。可考虑：
- 定义领域事件（如
UserPreferenceUpdated），由 Server 端发布到消息队列（RabbitMQ / Azure Service Bus） - WASM 端通过长轮询或 WebHook 接收事件，本地更新状态并刷新 UI
- 所有状态变更必须经由“命令→事件→存储”流程，避免直写内存导致两端不一致
这种设计代价是引入基础设施依赖，但换来的是可追溯、可重放、两端解耦——比徒劳地想“共享”更贴近真实需求。
最容易被忽略的一点：WASM 的初始状态加载时机（OnInitializedAsync）和 Server 的首次渲染时机完全不同步，任何依赖“两边同时启动就状态一致”的假设，都会在真实网络延迟下立刻崩塌。
