根本原因是pytest-dotenv仅在pytest启动时读取当前工作目录下的.env文件，而CI/CD环境不提交本地.env、不自动复制，且加载时机与路径依赖严格；需显式提供.env.test、配置addopts参数或在conftest.py中手动load_dotenv确保三者同时成立。
为什么 pytest-dotenv 在 CI/CD 中经常不生效
根本原因不是 pytest-dotenv 本身有问题，而是它只在 pytest 启动时读取 .env 文件，且默认只加载当前工作目录下的 .env —— 而 CI/CD 环境（如 GitHub Actions、GitLab CI）通常不会把本地 .env 提交进仓库，也不会在测试执行前自动复制或生成它。
常见错误现象包括：
-
os.getenv("DB_URL")返回None，导致连接失败 - 本地
pytest运行正常，CI 报KeyError或配置缺失异常 - 即使安装了
pytest-dotenv，--dotenv=.env参数被忽略（比如 pytest 命令没传参、或插件未启用）
如何让 pytest-dotenv 在 CI 中真正加载变量
关键不是“装上插件”，而是确保三件事同时成立：插件启用、.env 文件存在、路径可被识别。CI 环境里必须显式提供环境变量源。
Claw Code Suite (Python-Only Edition)
下载
仅使用 Python 将 Claw Code 虚拟化框架与 OpenClaw 集成，提供 184 种工具和 200 多条命令，用于安全分析和代码质量...
- 不要依赖本地
.env文件：把它从.gitignore中移除（仅限非敏感字段），或拆分出.env.test并提交（例如只含TEST_DATABASE_URL=sqlite:///test.db） - 在
pytest.ini或pyproject.toml中显式启用并指定路径：[tool:pytest]<br>addopts = "--dotenv=.env.test"
- 如果使用 GitHub Actions，确保
.env.test已检入，并在 job 步骤中确认当前工作目录正确：pwd输出应为项目根目录（即.env.test所在位置） - 验证是否生效：在某个测试里加一句
print(os.getenv("TEST_DATABASE_URL"))，CI 日志里看到值才说明真加载了
比 pytest-dotenv 更稳的替代方案：直接用 os.environ.update()
当环境差异大、CI 配置灵活（如多环境并行测试）时，硬编码路径反而容易出错。pytest-dotenv 是便利工具，但不是基础设施。更可控的做法是绕过它，由测试代码主动加载。
立即学习“Python免费学习笔记（深入）”；
- 在
conftest.py开头手动加载：import os<br>from pathlib import Path<br>from dotenv import load_dotenv<br><br>env_file = Path(__file__).parent / ".env.test"<br>if env_file.exists():<br> load_dotenv(env_file)
- 这样能精确控制加载时机（早于任何 fixture）、路径（支持相对/绝对）、甚至 fallback 逻辑（比如找不到就用默认值）
- 注意：必须确保
python-dotenv已安装（pytest-dotenv会带它，但单独用时需显式声明依赖） - 敏感变量（如 API keys）仍应通过 CI 的 secrets 注入，再由
os.environ.setdefault("API_KEY", os.getenv("CI_API_KEY"))衔接
容易被忽略的兼容性坑：pytest 版本与插件冲突
pytest-dotenv 对 pytest 主版本敏感。v0.4.x 只支持 pytest
- 检查 CI 中实际运行的 pytest 版本：
pytest --version - 查看
pytest-dotenv的 PyPI 页面支持列表，或直接查其setup.py中的install_requires - 临时降级不是长久之计；推荐改用上一节的手动
load_dotenv()方式，完全脱离插件生命周期约束 - 另一个隐形陷阱：
pytest-xdist并行执行时，多个 worker 可能竞争读取同一个.env文件（虽不常出问题，但文件被外部修改时行为不可控）
