composer clear-cache有时无效，因其仅清除~/.composer/cache/中的zip包和packages.json快照，无法修复dns/代理异常、zlib缺失、属主错位或repositories配置覆盖等问题，需配合镜像切换、权限修复及--no-cache安装等综合手段。
缓存损坏不是“文件坏了”，而是 Composer 读到了错误的 ZIP、过期的元数据或校验不匹配的 dist 包——直接删缓存目录往往不够，必须配合镜像、网络和权限三重验证。
composer clear-cache 为什么有时没用
该命令只清 ~/.composer/cache/ 下的 ZIP 和 packages.json 快照，但不会：
- 刷新 DNS 缓存或系统代理设置（比如企业内网走 proxy 后超时）
- 修复 PHP 的
zlib扩展缺失导致的解压失败（php -m | grep zlib必须有输出） - 修正被
sudo污染的缓存目录属主（ls -ld $(composer config --global cache-dir)看 owner 是否为当前用户） - 绕过项目级
repositories配置对全局镜像的覆盖（composer config repo.packagist才是当前生效值）
缓存重建必须连带检查的三件事
清完缓存后仍失败？说明问题不在缓存本身：
- 运行
curl -I https://mirrors.aliyun.com/composer/packages.json，确认秒回HTTP/2 200；若卡住或返回 404，镜像源实际不可用 - 检查
php.ini中是否启用了extension=openssl和allow_url_fopen = On - 在 CI/CD 或 Docker 中，
composer clear-cache基本无效——应改用composer install --no-cache，避免依赖本地缓存状态
真正有效的缓存重建组合命令
单条命令容易遗漏环节，以下顺序执行才可控：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先切到稳定镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 再清缓存：
composer clear-cache - 删掉可能残留的损坏包（可选）：
rm -f $(composer config cache-dir)/files/vendor-name/package-name/*.zip - 最后强制跳过缓存安装：
composer install --no-cache --prefer-dist
注意：--prefer-dist 能避开 git clone 触发的 GitHub API 限流，比 --prefer-source 更稳定。
权限问题常被当成缓存损坏
报错含 failed to write 或 Permission denied，90% 是属主错位，不是缓存坏：
- 查缓存路径：
composer config --global cache-dir - 看属主：
ls -ld $(composer config --global cache-dir) - 修权限（非 root 用户）：
sudo chown -R $USER:$USER $(composer config --global cache-dir) - 顺手修整个配置目录：
sudo chown -R $USER:$USER ~/.composer
WSL 用户还要确认 /etc/wsl.conf 是否设置了 metadata,uid=1000,gid=1000，否则 Windows 挂载路径下 chmod 无效。
