应将 load_dotenv(override=True) 放在项目入口文件最顶部，显式用 os.getenv 读取敏感变量并掩码日志输出，.env 必须被 .gitignore 排除且 CI/CD 中禁用。
直接用 .env 文件存数据库密码是常见做法，但不加约束极易泄露——比如误提交到 Git、被日志打印、或在容器中未正确加载。关键不是“能不能用”，而是“怎么确保它真被隔离且只在需要时生效”。
dotenv 加载时机必须早于任何依赖配置的模块
很多问题源于 load_dotenv() 被放在业务代码深处，而 sqlalchemy.create_engine() 或 django.settings 初始化时已开始读环境变量。此时 .env 根本没生效，程序退而使用空值或默认值，报错却指向数据库连接失败，掩盖了真正原因。
- 最佳位置：项目入口文件（如
main.py、manage.py或wsgi.py）最顶部，紧挨着import语句之前 - 务必加
override=True参数（尤其开发/测试环境），否则系统环境变量会覆盖.env中的值，导致本地调试失效 - 避免在模块内部多次调用
load_dotenv()，重复加载无意义，还可能因路径不同导致加载错文件
敏感字段必须显式从 os.environ 读取，不能靠 dotenv 自动注入
python-dotenv 默认只是把 .env 键值对写入 os.environ，但它不会阻止你直接写 DB_PASSWORD = "hardcoded" 这类硬编码。更危险的是，有人误以为只要用了 .env，所有变量就“自动安全”了，结果在日志里打出了 os.environ["DB_PASSWORD"]。
macOS UI 自动化技能包 —— 用 Python 控制你的 Mac
下载
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 永远用
os.getenv("DB_PASSWORD")，而非os.environ["DB_PASSWORD"]—— 前者可设默认值（如None），后者键不存在直接抛KeyError - 禁止在日志、异常消息、API 响应中直接包含敏感变量值；哪怕调试时也先做掩码处理，例如
f"DB_HOST={host}, DB_USER={user}, DB_PASSWORD=***" - 检查所有配置加载逻辑（如 Pydantic
BaseSettings、Django 的os.environ.get链式调用），确认没有漏掉某一个敏感字段的读取方式
Git 必须忽略 .env 并用 .env.example 提供结构样板
误提交 .env 是生产事故高频原因。仅靠团队自觉不够，必须靠机制卡死。
立即学习“Python免费学习笔记（深入）”；
- 在
.gitignore中明确添加.env（注意不要写成*.env，否则会误忽略.envrc等合法文件） - 维护一个
.env.example，内容只含变量名和注释，例如：DB_HOST=localhost<br>DB_PORT=5432<br>DB_NAME=app_dev<br># DB_PASSWORD=your_actual_password_here ← 此行注释掉，不填值
- CI/CD 流水线禁止读取任何
.env文件，改用平台提供的密钥管理（如 GitHub Secrets、AWS Parameter Store），并在部署时注入环境变量
最常被忽略的一点：dotenv 不提供加密、权限校验或运行时保护。它只是一个文本解析器。真正的安全边界在于你是否阻断了敏感值的传播路径——从文件读取、内存驻留、日志输出到进程间通信，每个环节都得单独设防。
