Blazor Server中全局可用值的存储及运行时动态修改最佳方案

方案1：单例强类型配置服务（单实例部署首选） #

这是最贴近传统Application变量的实现方式，全程走内存读写，无额外IO开销，完全满足需求：

• 第一步：定义全局配置强类型类

public class AppGlobalSettings
{
    // 可根据需求扩展更多全局配置项
    public bool IsMaintenanceMode { get; set; }
}

• 第二步：在Program.cs中注册为单例服务，支持从appsettings.json读取初始值

// 直接注册，初始值默认false
builder.Services.AddSingleton<AppGlobalSettings>();

// 如果需要从appsettings读取初始预设值，用以下写法（appsettings中要对应配置AppSettings节点）
// builder.Services.AddSingleton(sp => 
//     builder.Configuration.GetSection("AppSettings").Get<AppGlobalSettings>() ?? new AppGlobalSettings()
// );

• 第三步：中间件直接读取单例值，无任何额外查询开销
  中间件构造函数直接注入AppGlobalSettings，每次请求直接读取内存中的IsMaintenanceMode属性即可执行跳转逻辑。
• 第四步：运行时修改配置
  在管理员操作的页面/接口中注入AppGlobalSettings，直接对IsMaintenanceMode赋值即可，全应用所有请求会立即读取到最新值，无需重启服务。

方案2：内存缓存包装（适合需要同步持久化/多逻辑关联的场景） #

如果修改配置后需要同步写入数据库/配置文件，可以搭配IMemoryCache使用：

• 定义固定缓存键：const string GlobalMaintenanceModeKey = "Global:IsMaintenanceMode";
• 首次读取时先查缓存，缓存不存在则查一次数据库，将结果写入缓存并设置为永不过期
• 运行时修改时，先更新持久化数据源，再更新/删除对应缓存键，后续请求直接读取缓存
• 优点是可以灵活设置过期策略、关联其他配置项，性能和单例方案基本持平

注意事项 #

• 上述两种方案默认适用于单服务器部署场景，如果是多实例负载均衡部署，需要搭配分布式缓存（如Redis）或者统一配置中心实现多实例配置同步
• 单例服务本身是线程安全的读操作，如果有高频并发写入需求，可以给属性加锁避免竞争

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