最常见原因是环境变量未在进程启动前加载，os.getenv()仅读取已存在的变量，不自动加载.env文件或shell配置；需用echo验证、ide中注意环境继承、默认值兜底，生产环境禁用python-dotenv。
用 os.getenv() 读取环境变量时为什么返回 None
最常见原因是变量根本没被系统加载，不是代码写错了。Python 的 os.getenv() 只读取进程启动时已存在的环境变量，不会自动加载 .env 文件或 shell 配置里的内容。
- 检查是否在运行 Python 前已导出：终端执行
echo $DATABASE_URL，有输出才说明环境里真有这个变量 - 如果靠
source .env加载，确保是在同一 shell 中运行python app.py，别在 IDE 里点运行——多数 IDE 不继承 shell 的环境变量 - 用默认值兜底：写成
os.getenv("DEBUG", "false").lower() == "true"，避免None导致类型错误
要不要用 python-dotenv？什么场景下必须用
它只在开发阶段有用，本质是把 .env 文件内容塞进 os.environ。生产环境不该依赖它——配置应由运维通过真实环境变量注入，而不是靠读文件。
- 本地调试 Flask/Django 时可加：
from dotenv import load_dotenv load_dotenv() # 自动找 .env 并加载
- CI/CD 流水线里禁用：GitHub Actions、Docker 容器等环境应显式用
env:或--env注入，不调load_dotenv() - 注意加载顺序：如果
.env和系统变量同名，load_dotenv(override=True)才能覆盖，否则系统变量优先
pydantic-settings 比手写 os.getenv() 强在哪
它把“读环境变量→转类型→校验→设默认值”全包了，且支持嵌套结构和多源合并（比如环境变量 + TOML 配置文件），适合中大型项目。
- 自动类型转换：
PORT: int = Field(default=8000)，不用再写int(os.getenv("PORT", "8000")) - 校验逻辑内建：
EMAIL: EmailStr会直接报错，而不是等发邮件时才发现格式不对 - 敏感字段自动脱敏：日志打印配置对象时，
SECRET_KEY这类字段默认显示为******** - 示例定义：
from pydantic_settings import BaseSettings <p>class Settings(BaseSettings): DEBUG: bool = False DATABASE_URL: str JWT_SECRET: str</p><p>settings = Settings()
立即学习“Python免费学习笔记（深入）”；
Docker 和 Kubernetes 里怎么安全传环境变量
别把密钥写进 Dockerfile 或镜像层，也别硬编码在 docker-compose.yml 的 environment: 下——这些都可能被 docker inspect 看到。
- Docker Compose 用
env_file:+.env（仅限非敏感配置），密钥走secrets:或挂载文件 - Kubernetes 必须用
Secret对象，以 base64 编码存，再通过envFrom:注入：envFrom: - secretRef: name: app-secrets - Python 代码里仍统一用
os.getenv()读，不要区分“这是 Docker 给的还是本地给的”——解耦就体现在这里
环境变量不是万能胶，填错位置、混用开发/生产逻辑、忽略类型校验，三者任一都会让“解耦”变成“更难排查”。真正关键的是：谁负责设置变量、在哪个环节注入、出错时有没有明确反馈路径。
