python-decouple 比 os.environ.get 更安全，因其强制处理缺失变量、支持类型转换与明确默认值，并避免静默降级；.env 文件须加入 .gitignore 且不存真实密钥；Docker 中推荐用 Secrets 隔离密钥；SECRET_KEY 与 ENCRYPTION_KEY 必须严格分离且独立管理。
直接在 settings.py 里写 SECRET_KEY 或 DATABASE_URL 是危险操作，必须杜绝。 安全存储环境变量的核心不是“怎么读”，而是“谁能在哪读到、读不到”——重点在于隔离、权限控制和生命周期管理。
用 python-decouple 读取时，为什么 config('KEY') 比 os.environ.get('KEY') 更安全？
因为 python-decouple 强制你面对“缺失”这个事实，而不是静默 fallback。它默认不提供任何默认值，一旦 KEY 在环境变量和 .env 文件中都不存在，就抛出 UndefinedValueError，避免生产环境意外降级为 debug 模式或连错数据库。
-
config('DEBUG', cast=bool, default=False)：类型强制转换 + 明确 fallback，比手动bool(os.environ.get('DEBUG'))少踩空字符串、'0'等坑 -
config('ALLOWED_HOSTS', cast=lambda v: [s.strip() for s in v.split(',')])：把逗号分隔字符串转成列表，避免因格式错误导致 500 错误 -
.env文件必须加进.gitignore，且不能包含任何真实密钥的模板（如.env.example只写变量名，不写示例值）
在 Docker 中，.env 文件和 env_file 配置容易混淆的点
Docker Compose 的 env_file 只是把文件内容注入容器环境变量，它本身不加密、不校验、不隔离——如果 .env.prod 被误提交，密钥就泄露了。真正起作用的是你如何加载这些变量。
-
env_file: .env.dev加载的是开发配置，但容器内仍需用python-decouple或django-environ读取，不能依赖os.environ直接使用 - 生产环境推荐用 Docker Secrets：把
SECRET_KEY_FILE挂载为文件路径，再由FileAwareEnv读取，避免密钥出现在进程环境块中（ps aux可见） -
docker-compose.yml中的environment:字段会覆盖env_file，慎用——尤其不要在这里写明文密钥
ENCRYPTION_KEY 和 SECRET_KEY 绝对不能复用
这是最容易被忽略的耦合风险。SECRET_KEY 用于 Django 内部机制（session 签名、CSRF token、密码重置链接），而 ENCRYPTION_KEY 是给 django-fernet-encrypted-fields 专用的对称密钥。两者生命周期、暴露面、轮换策略完全不同。
- 共用会导致：轮换
SECRET_KEY后，所有已加密的用户 API 密钥无法解密；或一次密钥泄露，同时废掉整个认证体系和用户数据 -
ENCRYPTION_KEY必须从独立环境变量（如DJANGO_ENCRYPTION_KEY）读取，不能用SECRET_KEY衍生（比如hashlib.sha256(SECRET_KEY.encode()).digest()[:32]） - 首次部署后，
ENCRYPTION_KEY必须备份到离线介质——丢失即永久丢数据，django-fernet-encrypted-fields不提供密钥恢复机制
真正难的不是选哪个库，而是确保密钥不落地、不跨域、不共享。哪怕用了最标准的 python-decouple，只要 .env 进了 Git 或 SECRET_KEY 和数据库加密密钥混用，整套防护就形同虚设。
