ConfigParser 默认大小写敏感，section 和 option 名均区分大小写；需统一小写命名或校验合法 section 列表。
用 configparser 加载 INI 文件时，section 名大小写敏感吗？
默认敏感。Python 的 ConfigParser 在 3.2+ 版本中默认使用 configparser.RawConfigParser 行为，section 和 option 名都区分大小写。
常见错误现象：写配置时用了 [Database]，代码里却写 config.get("database", "host")，直接抛 NoSectionError。
- 若需忽略大小写，初始化时传入
converters或继承并重写_get_section_name（不推荐） - 更稳妥的做法是统一约定全小写 section 名，比如始终用
[database]、[logging] - 生产环境建议加一层校验：启动时遍历
config.sections()，比对预设的合法 section 列表，缺失则报错退出
JSON/YAML 配置文件怎么支持环境变量替换？
标准 json.load() 和 yaml.safe_load() 不解析环境变量，得自己处理。常见做法是在加载后递归扫描字符串值，用 os.environ.get() 替换 ${DB_HOST} 这类占位符。
注意点：
立即学习“Python免费学习笔记（深入）”；
- 别用
eval()或exec()解析带变量的 JSON 字符串——太危险 - 推荐用
string.Template或正则 +os.getenv()手动替换，例如：import re import os def expand_env_vars(data): if isinstance(data, str): return re.sub(r'\$\{([^}]+)\}', lambda m: os.getenv(m.group(1), m.group(0)), data) elif isinstance(data, dict): return {k: expand_env_vars(v) for k, v in data.items()} elif isinstance(data, list): return [expand_env_vars(v) for v in data] else: return data - YAML 用户可考虑
pyaml-env库，但要注意它只处理顶层字符串，嵌套结构仍需手动递归
多个配置源（本地文件 + 环境变量 + 命令行参数）怎么合并优先级？
典型优先级顺序是：命令行参数 > 环境变量 > 配置文件 > 默认值。关键不是“怎么读”，而是“怎么覆盖”——必须明确哪一层能覆盖哪一层。
实操建议：
- 不要用
dict.update()简单合并嵌套字典，它不会递归覆盖，比如配置文件里{"db": {"host": "localhost"}}，环境变量设DB_PORT=5432，结果会变成{"db": {"host": "localhost"}, "db_port": 5432} - 用
deepmerge库或手写递归合并函数，确保DB_PORT能落到db.port下 - 环境变量转 key 时统一用下划线转驼峰/点号，例如
LOG_LEVEL→log.level，避免硬编码映射表 - 调试时打印最终生效的配置（脱敏后），尤其注意布尔值：环境变量传
"false"是字符串，不是False
配置热加载是否值得做？
绝大多数服务不需要。热加载带来复杂度远高于收益：文件监听有延迟、reload 时配置不一致、并发修改导致竞态、无法保证模块内已缓存的配置被更新。
真需要热加载的场景其实很窄：
- 长周期批处理任务中动态调参（如模型推理的阈值）
- 网关类服务需实时更新路由规则
- 内部工具型脚本，开发者频繁试错
如果决定做，别自己轮询 os.stat().st_mtime。用 watchdog 监听文件变化，且 reload 必须加锁 + 原子替换（如用 threading.local 或全局 weakref 缓存实例），否则容易出现一半代码读旧值、一半读新值。
最常被忽略的一点：热加载后，日志级别、采样率等运行时行为变更，可能依赖第三方库的状态，这些库未必支持运行时重配置——得查文档，不能假设它能跟上。
