环境变量是进程启动时的默认值来源，非Python管理，仅提供最外层覆盖入口；需手动类型转换，.env需python-dotenv显式加载，遵循命令行>显式load>默认.env的优先级，不适用复杂结构与敏感信息。
环境变量不是配置的终点，而是启动时的默认值来源
Python 本身不管理环境变量，os.environ 只是读取操作系统传进来的键值对。它在配置体系里干的活很明确：提供最外层、最早可用的覆盖入口，比如 DATABASE_URL 或 DEBUG。但一旦你调用 os.environ.get("DEBUG")，拿到的就是字符串，不会自动转成布尔值或整数——这是最常见的类型陷阱。
- 别指望
os.environ["DEBUG"] == True成立；实际是"True"或"1"，得手动转换 -
.env文件内容不会自动加载进os.environ，需要python-dotenv显式调用load_dotenv() - 如果多个地方都改
os.environ（比如测试里os.environ["TESTING"] = "1"），记得用os.environ.pop("TESTING", None)清理，否则污染后续测试
用 os.getenv() 而不是直接查 os.environ 字典
直接写 os.environ["PORT"] 会在键不存在时抛 KeyError，而生产环境里缺失关键变量应该失败得更可控。用 os.getenv() 能设默认值、避免崩溃，也方便单元测试 mock。
-
os.getenv("PORT", "8000")返回字符串，不是整数，后续要int(os.getenv("PORT", "8000")) - 如果默认值是空字符串（
""），注意它和None行为不同；os.getenv("HOST") or "localhost"这种写法在HOST=""时会 fallback，但可能不是你想要的 - 某些库（如
pydantic-settings）内部就用os.getenv封装，所以自定义逻辑最好保持一致
python-dotenv 加载顺序和覆盖规则容易被误读
load_dotenv() 不是“覆盖全局”，它只把文件里的键值对塞进 os.environ，且仅当该键还不存在时才写入。也就是说，命令行传的变量（DEBUG=1 python app.py）永远优先于 .env 文件。
- 默认加载
.env，但你可以指定路径：load_dotenv(".env.production")，注意路径是相对当前工作目录，不是脚本所在目录 - 多次调用
load_dotenv()不会清空已有变量，也不会重复加载同一文件；想强制重载得加override=True参数 -
.env.local不会被自动识别，必须显式调用load_dotenv(".env.local")，且建议放在主.env之后，让它覆盖前者
环境变量不适合存复杂结构或敏感凭据明文
环境变量本质是进程级字符串键值对，没有嵌套、数组、注释或类型支持。硬塞 JSON 字符串（如 FEATURES='{"auth": true}'）会导致解析脆弱；而把数据库密码直接写进 .env 文件提交到 Git，是典型的安全疏忽。
立即学习“Python免费学习笔记（深入）”；
- 复杂配置（如日志级别列表、中间件顺序）更适合用 YAML/JSON 配置文件 + 环境变量做顶层切换
- 密钥类变量（
AWS_SECRET_ACCESS_KEY）应通过 secrets manager 或 runtime 注入，而非本地.env -
os.environ内容会出现在ps aux或容器inspect输出里，攻击者可轻易获取——别信“本地开发无所谓”
环境变量真正的价值不在“存多少”，而在“谁能在进程启动前改它”。越早介入（shell 层、容器 run 命令、CI job env block），越能解耦配置与代码。但一旦进了 Python 进程，它就只是个普通字典，别给它加戏。
