必须显式创建虚拟环境并单独缓存 pip，不能缓存整个 venv 目录——否则因绑定 Python minor 版本及系统路径差异导致 ImportError；应缓存 ~/.cache/pip（非 .cache/pip），并用 key: "$CI_COMMIT_REF_SLUG" 确保生效。
必须显式创建虚拟环境并单独缓存 pip，不能缓存整个 venv 目录——否则跨 Python 版本或 Runner 环境时会直接 ImportError。
为什么缓存 .venv/ 会导致 CI 失败？
GitLab Runner 每次 job 启动都是全新容器，.venv/ 是二进制产物，绑定具体 Python minor 版本（如 python:3.11 构建的 .venv/ 在 python:3.12 下无法复用），还会因系统库路径差异报 ImportError: cannot import name '...' from partially initialized module。
- 缓存
.venv/看似省事，实则让缓存 key 失效逻辑失控，反而增加调试成本 - 真正可安全复用的是
~/.cache/pip：里面是 wheel 包和源码缓存，pip 会按当前 Python ABI 自动筛选兼容版本 - 若用了
python -m venv .venv，就别在cache: paths里写.venv—— 这是高频翻车点
怎样配才让 pip 缓存真正生效？
缓存不生效，90% 是因为路径写错或 pip 版本太旧。GitLab Runner 的 home 路径是动态挂载的，.cache/pip 是相对路径，根本找不到；而旧版 pip（
- 缓存路径必须写成
~/.cache/pip，不是.cache/pip或cache/pip - 在
before_script中加python -m pip install --upgrade pip，确保 pip ≥ 22.2 - 安装依赖时加
--prefer-binary：强制 pip 优先用缓存 wheel，避免退化到 sdist 编译 - cache key 建议用
"$CI_JOB_NAME-$CI_COMMIT_REF_SLUG-pip"，避免 test/deploy job 互相污染
测试阶段还要再激活一次虚拟环境吗？
要。GitLab CI 的每个 script 步骤都运行在独立 shell 进程中，source .venv/bin/activate 的效果不会跨步骤保留。只在 before_script 里激活一次，script 里执行 pytest 时实际走的还是系统 Python。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
立即学习“Python免费学习笔记（深入）”；
- 正确做法：每个
script块开头都加source .venv/bin/activate - 或者统一用绝对路径调用：
.venv/bin/python -m pytest tests/，绕过 shell 激活状态问题 - 别信 “激活一次就够了” 的经验——这是 GitLab CI 和 Bash 进程模型决定的硬约束，不是配置疏漏
最易被忽略的点：缓存能省时间，但救不了错误的环境隔离逻辑。先保证 python -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt 在每一步都稳定执行，再谈缓存优化。否则缓存越快，失败越隐蔽。
