composer clear-cache 清除的是 Composer 下载的包归档（.zip/.tar.gz）、解压临时文件及 vendor/composer/ 部分元数据，不删除 vendor/、composer.lock 或源码。
composer clear-cache 命令到底清什么
composer clear-cache 清的是 Composer 自己下载并存档的包（.zip/.tar.gz）、安装时解压的临时文件、以及 vendor/composer/ 下的部分元数据缓存。它**不清理**你项目里已安装的 vendor/ 目录，也不动 composer.lock 或源码。
常见误判是以为运行后 vendor/ 会变小——不会。真正占空间的大头是已安装包的源码和依赖树，缓存通常只占几百 MB，但长期不用清理可能累积到 2–5 GB。
执行建议：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 直接在任意目录运行
composer clear-cache即可，无需进入项目根目录 - 如果提示权限错误（尤其 macOS/Linux），说明缓存路径被 root 写入过，加
sudo不推荐；改用composer clear-cache --no-interaction并检查COMPOSER_CACHE_DIR环境变量是否指向了用户无权写入的位置 - Windows 用户注意：PowerShell 可能因执行策略报错，换 CMD 或临时用
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
缓存位置在哪？手动删更彻底吗
Composer 缓存默认在：~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\cache（Windows）。你可以用 composer config --global cache-dir 确认实际路径。
手动删文件夹比命令更“彻底”，但也更危险：
- 删错目录可能导致后续
composer install 失败（比如误删了 repo/ 下的 Packagist 镜像索引）
-
clear-cache 会保留部分用于加速的哈希校验文件，手动全删后首次更新会明显变慢
- 如果你改过全局缓存路径（如通过
COMPOSER_CACHE_DIR），手动删默认路径没用
所以优先走命令；真要手动删，先停掉所有 Composer 进程，再只删 cache/files/ 和 cache/archives/ 子目录。
为什么有时 clear-cache 没反应、卡住或报错
最常见原因是缓存目录里有损坏的归档或锁文件，尤其是断网中断下载后遗留的半成品。
典型现象：
- 命令长时间无输出，CPU 占用低，磁盘 I/O 几乎为 0 → 很可能是某个 .zip 文件 CRC 校验失败，Composer 在反复重试
- 报错
file_put_contents(/path/to/cache/files/xxx.zip): failed to open stream → 权限或磁盘满
- 报错
Could not delete /path/to/cache/repo/https---packagist.org/packages.json → 文件被其他进程占用（比如 IDE 正在扫描该目录）
解决办法：
- 加
--no-interaction 跳过交互式确认，避免卡在提示
- 用
lsof +D ~/.composer/cache（macOS/Linux）或 handle.exe -a cache（Windows Sysinternals）查谁占着文件
- 磁盘空间不足时，先删大文件：
find ~/.composer/cache/files -name "*.zip" -size +50M -delete
定期清理有必要吗？会不会影响 CI/CD 流程
本地开发机上，每月跑一次 composer clear-cache 就够了。缓存本身有 LRU 机制，Composer 会自动淘汰旧包，但镜像索引（repo/）不会自动清理，久而久之会堆积大量过期 JSON。
CI/CD 环境要特别小心：
- GitHub Actions、GitLab CI 默认每次都是干净环境，
clear-cache 完全没必要
- 自建 runner 若复用 workspace，缓存可能跨流水线污染（比如 A 项目 require-dev 的包被 B 项目误用），这时应在 job 开头加
composer clear-cache --no-interaction
- 不要在 Docker 构建层里跑
clear-cache，它不会减少镜像体积——缓存不在最终镜像里，但命令本身会多一层 layer
真正容易被忽略的是：某些私有 Packagist 镜像（如 Satis、Private Packagist）会把整个包归档同步到本地缓存，这种场景下缓存增长极快，且 clear-cache 不清理镜像服务自身的存储，得去对应服务后台删。
composer install 失败（比如误删了 repo/ 下的 Packagist 镜像索引）clear-cache 会保留部分用于加速的哈希校验文件，手动全删后首次更新会明显变慢COMPOSER_CACHE_DIR），手动删默认路径没用clear-cache 没反应、卡住或报错
最常见原因是缓存目录里有损坏的归档或锁文件，尤其是断网中断下载后遗留的半成品。
典型现象：
- 命令长时间无输出，CPU 占用低，磁盘 I/O 几乎为 0 → 很可能是某个 .zip 文件 CRC 校验失败，Composer 在反复重试
- 报错
file_put_contents(/path/to/cache/files/xxx.zip): failed to open stream→ 权限或磁盘满 - 报错
Could not delete /path/to/cache/repo/https---packagist.org/packages.json→ 文件被其他进程占用（比如 IDE 正在扫描该目录）
- 加
--no-interaction跳过交互式确认，避免卡在提示 - 用
lsof +D ~/.composer/cache（macOS/Linux）或handle.exe -a cache（Windows Sysinternals）查谁占着文件 - 磁盘空间不足时，先删大文件：
find ~/.composer/cache/files -name "*.zip" -size +50M -delete
定期清理有必要吗？会不会影响 CI/CD 流程
本地开发机上，每月跑一次 composer clear-cache 就够了。缓存本身有 LRU 机制，Composer 会自动淘汰旧包，但镜像索引（repo/）不会自动清理，久而久之会堆积大量过期 JSON。
CI/CD 环境要特别小心：
- GitHub Actions、GitLab CI 默认每次都是干净环境，
clear-cache 完全没必要
- 自建 runner 若复用 workspace，缓存可能跨流水线污染（比如 A 项目 require-dev 的包被 B 项目误用），这时应在 job 开头加
composer clear-cache --no-interaction
- 不要在 Docker 构建层里跑
clear-cache，它不会减少镜像体积——缓存不在最终镜像里，但命令本身会多一层 layer
真正容易被忽略的是：某些私有 Packagist 镜像（如 Satis、Private Packagist）会把整个包归档同步到本地缓存，这种场景下缓存增长极快，且 clear-cache 不清理镜像服务自身的存储，得去对应服务后台删。
clear-cache 完全没必要composer clear-cache --no-interaction
clear-cache，它不会减少镜像体积——缓存不在最终镜像里，但命令本身会多一层 layer
