Blazor WebAssembly 和 Blazor Server 混合应用不是官方直接支持的“单项目双托管模式”，但可以通过合理架构设计，在同一解决方案中**共用组件、业务逻辑和 API 层**，让不同页面或功能模块分别运行在 WASM 或 Server 模式下——本质是“共享代码 + 分离宿主”，而非一个页面同时跑两种模型。
核心思路：共享类库 + 独立宿主项目
不要试图在一个项目里切换渲染模式。正确做法是：
创建一个 Shared 类库（.NET Standard 或 .NET 6+），存放所有可复用内容：Razor 组件（.razor）、服务接口与实现（需注意依赖注入差异）、数据模型、工具方法等 新建两个独立的 Blazor 项目：Blazor WebAssembly App（带托管后端） 和 Blazor Server App 两个宿主项目都引用 Shared 类库，并按各自模型适配：WASM 项目调用 HttpClient 访问 API，Server 项目直接注入服务或调用本地逻辑组件复用的关键注意事项
不是所有组件都能无修改共用。需主动处理以下差异：
JS 互操作：WASM 中IJSRuntime.InvokeAsync是异步且网络往返的；Server 中是同步调用（
IJSRuntime.InvokeVoidAsync也走 SignalR）。建议封装抽象层，如定义
IJsHelper接口，在 Shared 中使用，由各宿主项目提供具体实现 状态管理与生命周期：Server 模式下组件实例长期存活，WASM 中可能随页面刷新重置。避免在组件内缓存跨请求状态，改用
localStorage（WASM）或
CascadingParameter+ 父组件管理（Server） 认证与授权：WASM 通常用 JWT 存 localStorage，Server 用 Cookie。Shared 中的
[Authorize]可共用，但登录逻辑、Token 获取/刷新必须分开实现
如何让部分路由走 WASM、部分走 Server？
不能靠路由配置自动切换，但可通过以下方式“模拟混合”：
反向代理方案（推荐）：用 Nginx / YARP / ASP.NET Core 的Proxy中间件，把特定路径（如
/admin/*）转发到 Blazor Server 应用，其余走 WASM 托管的后端。用户感知为同一域名下的不同区域 超链接跳转：在 WASM 页面中用
<a href="https://yoursite.com/admin">后台管理</a>直接跳转到 Server 应用地址（可同域部署降低跨源问题） IFrame 嵌入（慎用）：仅适合隔离强、交互少的模块（如报表页），不推荐用于主流程，因失去路由集成、状态共享和 SEO 友好性
调试与部署要点
两个项目独立发布，但需协调好基础配置：
API 基地址统一：WASM 项目中HttpClient.BaseAddress设为后端 API 地址；Server 项目若也调用外部 API，同样配置一致的客户端 身份验证票据兼容：如果共用 IdentityServer 或 JWT，确保签发方、密钥、有效期等配置完全一致 静态资源路径注意：WASM 需要
wwwroot/_content/{PackageId}/ 加载组件包，Server 则走 _content中间件自动映射，Shared 类库需标记为
StaticWebAssetBasePath（在 .csproj 中加
<staticwebassetbasepath>_content/Your.Shared</staticwebassetbasepath>）
基本上就这些。混合不是为了炫技，而是按场景选型：WASM 适合离线、高并发、低敏感前端；Server 适合实时协作、复杂服务器计算、强会话控制。共享代码能大幅降低维护成本，关键在提前划清边界、封装差异。
