python-dotenv不是万能解药，但它是当前最轻量、最易落地的安全起点；硬编码或使用os.getenv()带默认值会导致生产环境漏配时静默回退、故障难定位，且.env文件若未被.gitignore排除或权限设置不当，将导致敏感信息泄露。
python-dotenv 不是万能解药，但它是当前最轻量、最易落地的安全起点。硬编码 DATABASE_URL 或在 settings.py 里写 os.environ.get('DB_PASSWORD', 'dev123')，等于把钥匙挂在门把手上。
为什么不能直接用 os.getenv() 加默认值？
因为 os.getenv('DB_PASSWORD', 'fallback') 会在环境变量缺失时悄悄回退到默认值——生产环境一旦漏配，服务照常启动，但连的是测试库或空密码库，故障难定位，且审计日志里查不到配置缺失告警。
更危险的是：如果 .env 文件被误提交到 Git，而你又没在 .gitignore 里加 .env*，那 DB_PASSWORD 就裸奔在 GitHub 上。
用 python-decouple 强制校验环境变量存在性
它比 python-dotenv 多一层运行时契约约束，适合中大型项目：
- 安装：
pip install python-decouple - 创建
.env.local（不叫.env，避免被通用工具误加载） - 代码里必须显式指定来源：
Config(RepositoryEnv('.env.local'))，禁止 fallback 到os.environ - 缺失变量时抛
UndefinedValueError，而不是静默返回None或默认值
示例：
from decouple import Config, RepositoryEnv
config = Config(RepositoryEnv('.env.local'))
DATABASE_URL = config('DATABASE_URL') # 缺失即崩，不妥协
.env 文件本身的安全边界在哪？
它只是文本文件，不加密、不权限控制。它的安全完全依赖三件事：
-
.gitignore必须包含：.env*和*.env（防止.env.production漏网） - 文件权限设为
600（chmod 600 .env.local），避免同服务器其他用户读取 - 绝不在 CI/CD 流水线里用
cat .env.local打印调试——日志会留存凭证
别信“只放开发环境”的说法。哪怕本地开发，.env.local 也该和生产环境一样对待：密码不复用、不共享、不截图。
生产环境该用什么替代 .env 文件？
.env 是开发便利性妥协，不是生产方案。Kubernetes 场景下，必须用 Secret 挂载为文件或环境变量；云平台（AWS/Azure/GCP）应走密钥管理服务（KMS/SSM Parameter Store/Azure Key Vault），通过 IAM 角色动态拉取。
这时候 python-decouple 或 os.getenv() 只是读取入口，真正的凭证生命周期由基础设施管控——你代码里甚至不该知道密码长什么样。
最容易被忽略的点：很多人以为把 .env 放进 .gitignore 就万事大吉，却忘了 IDE 临时文件、shell 历史记录、容器镜像层缓存都可能残留明文凭证。真正的安全不是“没写进 Git”，而是“从没以明文形态存在于任何可持久化介质上”。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
