github actions 临时文件管理核心是机制协同而非手动删除：runner 每次 job 启动前自动清理 _tempdirectory，但 /tmp、工作目录根等需显式处理，ai 工具依赖的文件须通过 upload-artifact 显式持久化。
GitHub Actions 管理构建过程中的临时文件，核心不是“手动删”，而是靠机制协同 + 明确归属 + 适时释放。临时文件一旦失控，轻则磁盘告警、job 失败，重则污染后续构建、误导 AI 编程工具判断。
临时文件的默认清理行为
Runner 在每次 job 启动前，会自动清空自己的临时目录（_tempDirectory），这是硬编码在 Runner.Worker/TempDirectoryManager.cs 中的逻辑：
- 清理范围：仅限
_tempDirectory下内容（非整个/home/runner/work） - 方式：
IOUtil.DeleteDirectory(..., contentsOnly: true) - 触发时机：job 执行前，不依赖你写任何命令
这意味着：
- 你在
run:步骤里用mktemp或echo > /tmp/foo.txt生成的文件，不会被自动清理（因为不在_tempDirectory） - 但所有
actions/checkout、actions/setup-node等官方 action 创建的中间产物，基本都走这个 temp 路径，会被安全回收
显式控制临时文件生命周期
别等它“可能被清”，主动声明归属：
- 用
actions/upload-artifact上传的文件，属于 workflow 级产物，不随 job 结束消失，但默认只存 90 天 - 用
actions/cache缓存的依赖（如node_modules），按 key 命中复用，不自动清理旧缓存，需靠actions/cache@v4的cache-hit输出或定时 workflow 主动 purge - 用
rm -rf或find ... -mmin +60 -delete手动清理，适合清理/tmp或自定义 build 目录（如dist/,build/），建议放在finally类型的 step 里（配合if: always()）
避免临时文件“隐形堆积”
常见陷阱：
- 在
run:里执行docker build却没加--no-cache或没清理 dangling image，镜像层持续占用/var/lib/docker - 使用
pip install --user把包装进/home/runner/.local，下次 job 仍可见，且不触发 cache key 变更 - 把生成文件写到工作目录根（如
./output.zip），既没上传也没删，下次actions/checkout不会覆盖，越积越多
稳妥做法：
- 所有构建产出统一放
./dist或./artifacts，job 结尾用rm -rf ./dist（除非你要 upload） - Docker 构建后加一步
docker system prune -f --filter "until=24h" - Python 项目结尾加
pip list --user --format=freeze | grep -v "pkg-resources" | xargs pip uninstall -y（慎用，仅当确认无共享依赖时）
和 AI 编程工具协同的关键提醒
AI 工具（如 Cursor、Claude Code）常需读取上一轮的 coverage.json、sourcemap 或 dist 文件做比对。这些不能靠“临时文件”存活：
- 它们必须通过
upload-artifact显式上传，并带上 commit SHA 或 PR number 作为 artifact name - 下游 job 用
download-artifact指定commit: ${{ github.event.pull_request.head.sha }}精准获取，而非默认下载 latest - 别把它们混在
/tmp或./下——AI 工具调用时找不到，就直接报“baseline missing”
不复杂但容易忽略。
