不能只写 os.getenv("DB_PASSWORD")，因为它未设置时返回 None，直接拼接或传参会引发 TypeError 或认证失败；必须配合默认值兜底与显式类型转换，确保启动时即校验可用性。
直接用 os.getenv() 读取，但必须配合默认值兜底和类型转换，否则运行时崩得悄无声息。
为什么不能只写 os.getenv("DB_PASSWORD")
它返回 None 而不是空字符串，一旦你把它拼进数据库连接串或传给 requests.post(json=...)，大概率触发 TypeError: expected str, bytes or os.PathLike object 或更隐蔽的认证失败。生产环境里这类错误常被误判为服务端问题。
- 没设环境变量时，
os.getenv("KEY")返回None，不是"" -
None和字符串拼接会直接报错："host=" + None - 数字类配置（如端口、超时）必须手动转
int或float，环境变量全是字符串
os.getenv() 的安全用法：带默认值 + 显式类型转换
关键不是“读出来”，而是“读出来后立刻验证是否可用”。下面这段是实际项目中反复验证过的写法：
import os
<p>DB_HOST = os.getenv("DB_HOST", "localhost") # 字符串，有明确默认
DB_PORT = int(os.getenv("DB_PORT", "5432")) # 强制转 int，避免运行时隐式转换失败
DB_PASSWORD = os.getenv("DB_PASSWORD")
if not DB_PASSWORD:
raise ValueError("DB_PASSWORD is required but not set in environment")
API_TIMEOUT = float(os.getenv("API_TIMEOUT", "30.0"))注意：int("5432") 没问题，但 int("") 或 int(None) 会炸 —— 所以先兜底成字符串再转，比裸调 int(os.getenv("PORT")) 安全得多。
立即学习“Python免费学习笔记（深入）”；
用 python-decouple 或 dynaconf 的真实价值在哪？
它们不是为了“多一层封装”，而是解决两个硬伤：类型自动推导 和 缺失必填项的早期报错。比如：
from decouple import config
<h1>自动识别数字、布尔、列表（用逗号分隔）</h1><p>DEBUG = config('DEBUG', default=False, cast=bool)
REDIS_URL = config('REDIS_URL', default='redis://localhost:6379')
MAX_RETRY = config('MAX_RETRY', default=3, cast=int)</p><h1>缺失 SECRET_KEY 时立即抛出 ImproperlyConfigured，而不是等到 JWT 签名时失败</h1><p>SECRET_KEY = config('SECRET_KEY')这类库在启动时就校验所有 config(...) 调用，把配置错误拦在应用初始化阶段。自己手写 os.getenv 链式判断容易漏掉某个字段，尤其当配置项超过 10 个之后。
本地开发时最容易踩的坑：.env 文件加载时机
python-decouple 默认读 .env，但如果你在 settings.py 顶部 import 了其他模块，而那些模块又提前调用了 os.getenv，那 .env 还没加载，就会读到空值。
- 确保
from decouple import config是文件第一行 import（或至少在任何os.getenv前） - 不要在
__init__.py或工具函数里提前读环境变量 —— 它们可能被任意模块触发 - Docker 中别把
.env当作构建参数传，它只在容器运行时生效；CI/CD 里要用 secret 注入机制（如 GitHub Actions 的secrets）
环境变量不是“写完就跑”，它是一条依赖链：shell 加载 → Python 进程继承 → 应用代码读取 → 类型转换 → 校验逻辑触发。漏掉其中一环，问题就会滑到最下游才暴露。
