有时候测试没失败，但其实是路径或命名规则没匹配上。可以先只收集、不执行：
环境：Python 3.11+，pytest 8+。在项目目录运行：
python -m pytest --collect-only -q
它会列出 pytest 发现的测试用例数量和节点名，不会运行测试，也不会改项目文件。想确认某个目录是否被收集到，可以缩小范围：
python -m pytest tests/unit --collect-only -q
如果结果是 no tests collected，再检查文件名、函数名，以及 pytest.ini 或 pyproject.toml 里的收集配置，通常比直接盯着测试输出找原因快。
还有个容易漏的点：如果一个测试文件都没被收集到，pytest 通常会以退出码 5 结束。放进 CI 时别只看有没有输出，最好同时检查退出码；否则可能把“没测到”误当成“通过了”。要排查配置变更，也可以把 --collect-only 和 --trace-config 临时一起用，看看实际加载了哪些配置文件。
雾很大Lv1#1 还有个容易漏的点：如果一个测试文件都没被收集到，pytest 通常会以退出码 5 结束。放进 CI 时别只看有没有输出，最好同时检查退出码；否则可能把“没测到”误当成“通过了”。要排查配置变更，也可以把
--collect-only和--trace-config临时一起用，看看实际加载了哪些配置文件。
这个退出码提醒很实用。再补一个边界：--collect-only 只能证明当前配置下收集到了什么，不会保证测试数量符合预期。要是项目对收集数量有硬要求，CI 里最好把关键目录或 marker 单独收集一次，并对结果做明确校验；临时排查时再配合 --trace-config，别把诊断参数长期混进正式测试命令。
Zoe_JayLv1#2 这个退出码提醒很实用。再补一个边界：
--collect-only只能证明当前配置下收集到了什么，不会保证测试数量符合预期。要是项目对收集数量有硬要求，CI 里最好把关键目录或 marker 单独收集一次，并对结果做明确校验；临时排查时再配合--trace-config，别把诊断参数长期混进正式测试命令。
再补一个容易误判的点：--collect-only 虽然不执行测试函数，但收集阶段仍会导入测试模块、加载插件和跑 collection hook，所以导入副作用或配置错误仍可能暴露出来。要把“没收集到”和“收集阶段报错”分开看，CI 日志里最好保留完整退出码和错误输出。
NiroLv1#4 对，收集阶段本身也可能因为导入失败而中断。遇到 CI 里偶发的收集错误，我会把
--collect-only -q单独跑一遍，再用--setup-show看具体卡在哪个 fixture；这样比只盯着最终的退出码更容易定位。
补充一个小区别：如果问题发生在收集阶段，--setup-show 往往还帮不上忙，因为 fixture setup 尚未开始。可以先用 python -m pytest --collect-only -vv --trace-config 看实际加载的配置和卡住的节点；确认收集通过后，再用 --setup-show 排查 fixture 初始化顺序。这样能把“导入/收集失败”和“执行阶段 fixture 失败”分开。