log_cli=True未生效的主因是pytest未识别到配置文件，常见于工作目录与pytest.ini路径不匹配；需确保其位于当前或上层目录，并配合log_cli_level=INFO及以上级别使用。
log_cli=True 为什么没生效
很多用户在 pytest.ini 里写了 log_cli = True 却发现控制台依然不显示日志，最常见原因是配置文件没被 pytest 识别到——它只认当前执行目录或其父目录下的 pytest.ini、pyproject.toml 或 tox.ini。如果你在子目录下运行 pytest tests/，但 pytest.ini 在项目根目录，而当前 shell 的工作目录是 tests/，pytest 就会跳过它。
验证方式：运行 pytest --help，往下翻看 “logging” 部分，如果看到 --log-cli-level 说明日志相关配置已加载；如果完全没这一节，说明配置文件未被读取。
- 确保
pytest.ini位于 pytest 执行时的当前工作目录（pwd输出路径）或其任意上层目录 - 避免用
python -m pytest切换工作目录却不注意路径变化 - 临时测试是否生效：加命令行参数
--log-cli-level=INFO，若此时有日志输出，就坐实是配置文件位置问题
log_cli 和 log_cli_level 的区别与配合
log_cli 是开关，log_cli_level 才决定输出哪些级别。只开 log_cli = True 但没设 level，默认只输出 WARNING 及以上——所以你写的 logging.info("xxx") 依然看不到。
典型错误是以为开了 log_cli 就万事大吉，结果 debug 日志全被过滤掉。
-
log_cli = True启用控制台日志输出（等价于命令行加--log-cli） -
log_cli_level = INFO设置最低输出级别（等价于--log-cli-level=INFO） - 推荐组合：
log_cli = True+log_cli_level = DEBUG，再在测试中用logging.debug("step 1")验证 - 注意：level 值不区分大小写，但必须是标准级别名（
DEBUG、INFO、WARNING等）
为什么测试函数里 print() 和 logging 混在一起还是乱
log_cli 只管 logging 模块输出，不管 print()。pytest 默认捕获 print() 并延迟到测试失败时才显示，导致和实时日志时间线错位、顺序混乱。
想让 print() 和 logging 同步刷到终端，必须额外开启输出捕获的“实时模式”。
- 在
pytest.ini中加capture = sys（默认值，不用改） - 关键是要加
log_cli_format = %(asctime)s [%(levelname)8s] %(name)s: %(message)s提升可读性 - 更彻底的解法：用
--capture=no或配置capture = no，让所有print()立即输出（适合调试阶段） - 注意：
capture = no会导致失败时无法显示print()输出内容，慎用于 CI
多进程（pytest-xdist）下 log_cli 失效怎么办
一旦启用 -n auto 或其他 pytest-xdist 参数，并发 worker 进程不会共享主进程的日志配置，log_cli 在子进程中默认关闭，日志全丢。
这不是 bug，是 xdist 的设计限制：每个 worker 是独立 Python 进程，需显式传递日志参数。
- 必须用命令行指定：
pytest -n auto --log-cli-level=DEBUG（仅靠pytest.ini不够） -
pytest-xdist≥ 3.0 支持--log-file-level，但--log-cli*系列仍需显式传参 - CI 场景建议统一用命令行参数控制，而不是依赖配置文件
- 若坚持用配置，可在
pyproject.toml中写addopts = ["--log-cli-level=DEBUG", "-n", "auto"]，但要注意 TOML 数组语法
pytest.ini 能覆盖一切。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
