composer缓存占满磁盘主因是默认缓存路径位于小容量分区（如windows的c盘%appdata%\composer\cache），应先用composer config --global cache-dir查真实路径，再用du -sh或右键属性确认大小，最后通过composer config --global cache-dir指定大空间分区路径并验证权限与写入生效。
Composer 缓存占满磁盘，不是删得不够狠，而是它默认死守小容量分区（比如 C 盘的 %APPDATA%\Composer\Cache）——换位置比清缓存更治本。
怎么查当前缓存路径和大小
别猜，先确认 Composer 实际在往哪写：运行 composer config --global cache-dir，输出的就是真实路径。Linux/macOS 下直接用 du -sh $(composer config --global cache-dir) 看占用；Windows 用户打开资源管理器，粘贴路径（如 %APPDATA%\Composer\Cache），右键“属性”看大小。
常见误判点：
- 你以为缓存很小，但
du -sh显示 2.1GB —— 这就是主因，别急着查 Docker 或日志 - 路径显示
C:\Users\xxx\AppData\Roaming\Composer\Cache，而你 D 盘空着 80GB —— 典型的分区错配 - 宝塔面板下执行
which composer返回空，说明你根本没调到正确的 Composer，config --global可能压根没生效
换缓存目录：一行命令 + 一个权限检查
目标是把缓存挪到空间充裕、inode 充足的分区（比如 D 盘、/mnt/data 或 /tmp）。命令很简单：
composer config --global cache-dir "D:\composer-cache"
Linux/macOS 替换为：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer config --global cache-dir "/mnt/data/composer-cache"
但执行后必须立刻验证两件事：
- 目标目录存在且可写：
mkdir -p /mnt/data/composer-cache && chmod 755 /mnt/data/composer-cache - 不是 NFS 或某些网络挂载点——Composer 解压 ZIP 时会失败，报
failed to open stream: Permission denied或ziparchive::extractto(): failed to open stream - 如果用了宝塔或 CI 环境，确认运行用户（如
www）对该路径有读写权限，否则后续composer install会卡在 cache 写入阶段
为什么换位置比反复 clear-cache 更可靠
clear-cache 只清当前配置指向的路径，但 Composer 还重度依赖系统临时目录（sys_get_temp_dir()），比如解压 ZIP、生成 autoloader、跑脚本时都会往那儿塞文件。这个目录默认是系统级的（Windows 是 %TEMP%，Linux 是 /tmp），你清了缓存，它可能又在 /tmp 积累几万个小文件，最终触发 inode 耗尽（df -i 显示 Use% = 99%），报 disk full 却 df -h 显示还有 20GB 剩余。
所以真正稳的方案是：
- 把
cache-dir指向大分区 - 必要时顺手改下临时目录（通过环境变量
COMPOSER_CACHE_DIR或COMPOSER_HOME控制，但优先走config --global） - 避免让缓存和系统临时目录挤在同一块小容量、低 inode 配额的分区上
换完之后还要注意的三个细节
新路径生效后，并不意味着万事大吉：
-
clear-cache仍需手动跑一次，否则旧缓存还在原地占空间 - 某些项目在
composer.json里硬编码了"config": {"cache-dir": "..."}，会覆盖全局设置——用grep -r "cache-dir" .扫一遍，删掉或注释掉 - ECS 或内网环境建议搭配阿里云内网镜像：
composer config -g repo.packagist composer http://mirrors.cloud.aliyuncs.com/composer/（注意是http://，无 s，且末尾带/），避免 HTTPS 握手拖慢重建缓存速度
最常被跳过的动作：换完路径不验证 composer config --global cache-dir 是否真输出新路径，也不检查新目录是否真的被写入文件——结果缓存还是往老地方跑，磁盘继续告警。
