Config单例的可靠性关键在稳：需拦截重复__init__、用双重检查加锁防多线程竞争、按优先级顺序加载配置源、热更新时动态取值并加锁保障读写安全。
直接用 Config() 就能拿到全局唯一配置实例，但“能跑”不等于“可靠”——__init__ 被反复调用、多线程下重复加载、热更新时状态不一致，才是真实项目里最常踩的坑。
为什么 __init__ 会执行多次？
Python 的 __new__ 控制实例创建，__init__ 控制初始化。单例只保证 __new__ 返回同一个对象，但每次调用 Config() 都会触发 __init__，除非你主动拦截。
- 错误写法：
if self._data is None:——self._data在首次__init__后就存在了，但后续调用仍会进函数体 - 正确做法：用
hasattr(self, '_initialized')或getattr(self, '_initialized', False)做守门人 - 更稳妥：把初始化逻辑全挪到
_load()中，并在__new__里只调一次_load()，__init__留空或仅做轻量赋值
多线程环境下如何避免重复加载配置？
Web 服务（如 Uvicorn 多 worker）或并发模块初始化时，多个线程可能同时判断 _instance is None，然后都去读文件、解析 YAML，造成资源浪费甚至数据错乱。
- 必须加锁：用
threading.Lock()包裹实例创建 + 加载逻辑 - 双重检查（Double-Checked Locking）不能省：
if cls._instance is None→ 加锁 → 再次if cls._instance is None - 锁对象必须是类级的，比如
_lock = threading.Lock()定义在 class body 里，不是每次 new 都新建一个
配置来源优先级怎么合并才不混乱？
环境变量、.env、YAML 文件、默认值混在一起时，硬编码顺序容易出错，也难测试。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
立即学习“Python免费学习笔记（深入）”；
- 不要手写
os.getenv() or yaml.load() or {...}这种链式 fallback - 用明确的加载器列表：比如
[EnvLoader(), DotenvLoader(), YamlLoader('config.yaml'), DefaultLoader()] - 每个 loader 实现统一接口
load() -> dict，按序调用，后加载的 key 覆盖先加载的（符合“环境变量 > 配置文件 > 默认值”语义） - 合并结果存入
self._data后，建议转为types.MappingProxyType或用@property封装访问，防止外部意外修改
热重载配置时，怎么避免其他模块还在用旧值？
单例本身不解决热更新问题；它只保证“只有一个实例”，但没规定这个实例的内容能不能变、怎么变。
- 提供
reload()方法，内部重新走一遍加载流程，并替换self._data - 关键：所有
@property访问器（如database_url）必须基于当前self._data动态取值，不能缓存结果 - 如果需要通知变更，加个简单回调机制：
self._on_reload_callbacks列表，reload()最后遍历调用 - 注意：热重载和线程安全要一起考虑，
reload()也得加锁，否则读写冲突
真正难的不是写出一个“只生成一次”的类，而是让这个实例在并发、更新、继承、测试各种现实压力下依然行为可预期——配置单例的脆弱点永远不在“单”，而在“稳”。
