Composer执行install/update时的临时文件主要藏在PHP的sys_get_temp_dir()返回路径（如/tmp或%APPDATA%LocalTemp），而非vendor或缓存目录；需用df -i检查inode是否耗尽，并清理该目录下composer_*.zip等残留文件。
Composer install/update 时临时文件藏在哪
Composer 在执行 install 或 update 时，会把下载的包缓存到 ~/.composer/cache/（Linux/macOS）或 %APPDATA%ComposerCache（Windows），同时在项目根目录生成 vendor/composer/installed.json、vendor/autoload.php 等中间产物——但真正“需要清理的临时文件”通常不是这些，而是你自定义构建步骤中产生的（比如 php artisan package:discover 生成的 bootstrap/cache/packages.php，或前端构建留下的 public/build/、node_modules/.cache/）。Composer 自身不产生可被脚本安全清理的“构建临时文件”，这点必须先厘清。
用 composer-scripts 声明 post-install-cmd 清理逻辑
Composer 支持在 composer.json 的 scripts 字段里定义钩子，其中 post-install-cmd 和 post-update-cmd 是最常用的清理入口。关键在于：这些钩子运行在 Composer 主流程结束后，此时 vendor 已就位，你的清理命令能安全访问项目结构。
- 在
composer.json的scripts下添加："scripts": { "post-install-cmd": [ "rm -rf public/build/*", "rm -f bootstrap/cache/*.php", "php artisan view:clear" ], "post-update-cmd": "@post-install-cmd" } - Linux/macOS 用
rm，Windows 需改用del /q或跨平台工具（如robocopy+rd），或统一用 PHP 脚本避免系统差异 - 不要在钩子里调用
composer dump-autoload后立刻删vendor/composer/autoload_*.php——这些是 Composer 运行必需的，删了会导致后续命令失败
用独立 shell 脚本封装并规避权限/路径问题
直接写在 composer.json 里的命令易受 shell 解析限制（比如含空格路径、特殊字符），也难调试。更稳妥的方式是把清理逻辑抽成外部脚本，再由 Composer 调用：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 新建
scripts/clean-build.sh（Linux/macOS）或scripts/clean-build.bat（Windows），内容为具体清理命令 - 在
composer.json中引用："post-install-cmd": ["bash scripts/clean-build.sh"],
（Windows 可用cmd /c scripts\clean-build.bat） - 脚本开头加
cd "$(dirname "$0")/.."确保工作目录正确；Windows 批处理需用%~dp0..替代 - 清理前加判断：
[ -d "bootstrap/cache" ] && rm -f bootstrap/cache/*.php，避免因目录不存在导致整个钩子中断
CI/CD 场景下注意缓存与并发冲突
在 GitHub Actions、GitLab CI 等环境里，composer install 往往配合缓存使用（如缓存 ~/.composer/cache），这时要注意：
- 清理脚本不能删掉 Composer 缓存目录本身（
~/.composer/cache），否则下次运行会重新下载所有包，拖慢构建 - 如果多个 job 并发运行同一项目，且共用缓存卷，
rm -rf vendor类操作可能被其他 job 干扰——应只清理当前 job 生成的产物（如public/build、storage/framework/cache） - 某些框架（Laravel）的
artisan config:clear会删bootstrap/cache/config.php，但它依赖vendor/autoload.php，所以必须确保清理命令排在composer install完成之后、且不能删 vendor
真正容易被忽略的是：清理动作是否和框架生命周期耦合。比如 Laravel 的 view:clear 必须等 vendor/autoload.php 加载成功后才能运行，而这个文件恰恰由 Composer 生成——所以钩子顺序不能颠倒，也不能在 pre-install-cmd 里清理。
