ioptions是启动时一次性绑定的单例只读快照，value永不变更；ioptionssnapshot按请求新建实例，支持配置软重载。两者均需正确调用configure()并确保配置路径匹配，否则value为空或为默认值。
IOptions 是单例、只读快照，启动后就固定；IOptionsSnapshot 是每次请求新建的实例，能拿到当前请求时刻的最新配置值。
为什么 IOptions.Value 永远不会变
它在 DI 容器注册时就完成了一次性绑定，后续无论 appsettings.json 怎么改、环境变量怎么覆盖，IOptions<t>.Value</t> 返回的始终是启动那一刻解析出的对象引用。这不是 bug，是设计使然 —— 它面向的是“配置即常量”的场景，比如数据库连接字符串（通常不热更新）、服务名称等。
常见错误现象：IOptions<myoptions>.Value.TimeoutMs</myoptions> 一直是 3000，哪怕你已把 appsettings.json 改成 5000 并保存，也看不到变化。
- 必须确保调用
Configure<t>()</t>注册，否则Value是 null 或默认值 - 不能在构造函数里对
Value做赋值或修改（如options.Value.Name = "x"），这会污染单例状态 - 不适用于需要运行时感知配置变更的逻辑（如动态开关、限流阈值）
IOptionsSnapshot.Value 每次请求都可能不同
它按作用域（Scope）生命周期创建，ASP.NET Core 中默认对应一次 HTTP 请求。每次新请求进来，DI 容器都会 new 一个新实例，并重新从当前 IConfiguration 中读取配置节 —— 所以它天然支持“软重载”：只要配置源启用了 reloadOnChange: true（如 AddJsonFile("appsettings.json", reloadOnChange: true)），下一次请求就能看到文件修改后的值。
使用场景：IOptionsSnapshot 适合中间件、控制器中需要隔离配置视图的逻辑，比如按请求打标、灰度分流策略读取、临时调试开关。
- 注意：它不会主动监听变更，只是“下次请求时才生效”，不是实时响应
- 后台任务（如
HostedService）中若长期持有IOptionsSnapshot实例，该实例不会自动刷新 —— 因为作用域已固定 - 不要把它当成“可变对象”去缓存或跨请求复用，它的生命周期只属于当前 Scope
配置键路径不匹配导致两者都为空
无论选 IOptions 还是 IOptionsSnapshot，如果 Configure<t>()</t> 绑定的 section 路径和实际配置结构对不上，Value 就全是默认值（null、0、false）。
典型坑点：
- JSON 中写
"MyService": { "TimeoutMs": 5000 }，但类里定义为public class MyServiceOptions { public int Timeout { get; set; } }—— 属性名Timeout和键TimeoutMs不一致，绑定失败 - 环境变量注入时用了单下划线
MY_SERVICE_TIMEOUT_MS=5000，但 ASP.NET Core 只认双下划线MY_SERVICE__TIMEOUT_MS - 没调用
builder.Services.AddOptions()，导致 Configure 扩展方法不可用
验证方式：在 Program.cs 启动时加一行 Console.WriteLine(string.Join("\n", builder.Configuration.AsEnumerable().Select(kv => $"{kv.Key} = {kv.Value}")))，确认目标键（如 MyService:TimeoutMs）确实存在且值非空。
别在构造函数里直接用 CurrentValue 做副作用操作
虽然 IOptionsSnapshot<t></t> 没有 CurrentValue 属性（只有 Value），但很多人会混淆它和 IOptionsMonitor<t></t> 的用法。重点提醒：如果你误用了 IOptionsMonitor<t></t> 并在构造函数里直接读 CurrentValue 做非幂等初始化（比如打开数据库连接、加载缓存），首次访问可能触发延迟加载，而此时配置还没 ready，容易报错或初始化错。
更安全的做法：
- 用
IOptionsSnapshot<t>.Value</t>—— 它保证构造时已就绪 - 如果真要用
IOptionsMonitor<t></t>，显式调用Get(string name)或在OnChange回调里做响应式初始化 - 避免在服务构造阶段依赖“热更新值”做关键资源分配
真正容易被忽略的是：三者都不是“魔法容器”，它们的可靠性完全取决于配置源是否加载成功、路径是否拼对、以及你有没有在正确时机访问 —— 尤其是嵌套层级深、带数组或集合的配置，手动校验键路径比猜命名规则靠谱得多。
