应使用AppContext.BaseDirectory作为基准路径加载外部JSON配置文件，配合AddJsonFile(..., optional: true, reloadOnChange: true)，并注入IOptionsMonitor<T>实现热更新，避免使用IOptions<T>或手动缓存。
用 ConfigurationBuilder 加载外部 JSON 文件时路径容易错
动态加载配置文件的核心是绕过默认的 appsettings.json，让程序在运行时读取指定路径的文件。但多数人卡在路径解析上——directory.getcurrentdirectory() 返回的是启动目录（比如 bin/debug），不是项目根目录；如果硬写相对路径，发布后很可能找不到文件。
- 推荐用
AppContext.BaseDirectory作为基准路径，它始终指向当前程序集所在目录，发布前后行为一致 - 配置文件建议放在与
.dll同级的config/子目录下，避免污染主目录 - 加载时必须调用
.AddJsonFile(path, optional: true, reloadOnChange: true)，其中reloadOnChange: true是热更新的前提，但仅对文件系统变化有效（不适用于网络或数据库配置）
示例：
var config = new ConfigurationBuilder()
.SetBasePath(AppContext.BaseDirectory)
.AddJsonFile("config/appsettings.custom.json", optional: true, reloadOnChange: true)
.Build();
IOptionsMonitor<T> 才能真正响应配置变更
很多人用了 reloadOnChange: true 却发现类里注入的 IOptions<T> 值没变——因为 IOptions<T> 只在服务注册时快照一次，而 IOptionsMonitor<T> 才会监听底层 IConfiguration 的变更事件并触发重绑定。
- 注册时无需额外操作，.NET 默认已注册
IOptionsMonitor<T> - 构造函数中直接注入
IOptionsMonitor<MyConfig>，它的CurrentValue会自动更新 - 如果需要在值变化时执行逻辑，可订阅
OnChanged回调：optionsMonitor.OnChanged(config => { /* 处理更新 */ });
热更新不是实时的，有 1 秒左右延迟且依赖文件系统通知
.NET 的 reloadOnChange 底层靠 FileSystemWatcher，它不是轮询，而是监听操作系统文件事件。这意味着：
- 修改保存后，Linux/macOS 下可能因 inotify 限制或编辑器“原子写入”（先写临时文件再替换）导致丢失事件，建议用
vim或echo >>测试，避开 VS Code 的保存策略 - Windows 下一般无问题，但若配置文件被其他进程独占（如记事本未关闭），更新会静默失败
- 延迟通常在 500ms–2s，无法做到毫秒级响应；高频修改（如每秒多次）可能合并为一次通知
错误现象：log.LogInformation("Config updated") 没输出，或 CurrentValue 仍为旧值——先检查文件是否真被写入，再确认没被锁住。
自定义配置热更新要小心对象引用和线程安全
如果你把配置对象缓存在静态字段、单例服务或全局字典里，IOptionsMonitor<T> 的更新不会自动同步到这些地方。更麻烦的是，多个线程同时读取 CurrentValue 时，.NET 保证其线程安全，但你自己的包装逻辑未必。
- 避免手动缓存配置实例；如需高性能访问，直接注入
IOptionsMonitor<T>并读CurrentValue - 不要在
OnChanged回调里做耗时操作（如 HTTP 请求），否则会阻塞后续变更通知 - 如果配置含集合或嵌套对象，确保它们是不可变的（如
IReadOnlyList<string>），否则外部修改可能引发并发问题
热更新真正的复杂点不在加载，而在你如何让业务代码感知并安全地响应变化——这往往比配置本身更难测试和验证。
