根本原因是缓存目录属主为root而非当前用户，需用sudo chown -R $USER:$USER修复~/.composer/cache归属，Windows需手动授予权限，删缓存后必须重建并chmod 755，否则仍复用损坏ZIP或卡在Extracting。
缓存目录属主错误导致 install 卡住或复用旧包
根本原因不是权限位（rwx）不够，而是 ~/.composer/cache 或其子目录（如 files/、repo/）的属主是 root 或其他用户，导致当前用户无法写入。Composer 不报错，但后续 install 会静默跳过下载、复用损坏 ZIP、或卡在 Extracting archive。
立刻确认归属：ls -ld $(composer config --global cache-dir)
如果第三列不是你当前用户名（$(whoami)），就是它了。
- Linux/macOS：执行
sudo chown -R $USER:$USER $(composer config --global cache-dir) - Windows：右键
%APPDATA%\Roaming\Composer\Cache→ 属性 → 安全 → 编辑 → 添加当前用户 → 勾选“完全控制” - WSL 用户额外检查：
cat /etc/wsl.conf是否含metadata=true，否则chown无效
手动清理缓存后必须重设目录权限，不能只删不建
composer clear-cache 只清内容，不重建目录结构，也不修复权限。删完不设权，下次 install 仍失败——尤其 files/ 下残留的损坏 ZIP 文件会被跳过校验直接复用。
- 删干净：
rm -rf $(composer config --global cache-dir) - 重建并授权：
mkdir -p $(composer config --global cache-dir) && chmod 755 $(composer config --global cache-dir) - 别碰
repo/和vcs/单独删——它们不参与解压，但删除整个repo/是刷新 metadata 的必要动作
临时路径不可写时，用 COMPOSER_CACHE_DIR 覆盖比硬改配置更安全
环境变量 COMPOSER_CACHE_DIR 优先级高于全局配置，适合 CI/Docker 等场景，且避免手改 ~/.composer/config.json 导致 JSON 错误或波浪号 ~ 未展开等静默失效问题。
- 必须用绝对路径：
export COMPOSER_CACHE_DIR="/tmp/composer-cache" - 必须提前创建并授权：
mkdir -p /tmp/composer-cache && chmod 700 /tmp/composer-cache - 验证是否生效：
composer diag | grep "Cache directory"，再ls -lh看该路径下是否有新生成的文件
损坏 ZIP 文件残留引发 Extracting 失败，要精准定位再删
报错含 Failed to extract 或 Corrupted zip file，不是网络问题，而是 ~/.composer/cache/files/ 下某个 ZIP 文件结构损坏（如下载中断）。Composer 只比对哈希，不校验 ZIP 完整性。
- 盯住
composer install -v输出末尾，找类似Extracting vendor/symfony/console的行，提取包名（如symfony/console） - 进
files/目录模糊搜索：ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Recurse -Filter "*console*.zip" - 仅删除匹配的 ZIP 文件；保留
repo/和vcs/；删后若仍报错，说明composer.lock中的dist.sha256与新包不匹配，需同步删vendor/和composer.lock
实际操作中最容易被忽略的是：缓存目录权限修复后，repo/ 子目录里的索引文件可能仍滞后，导致 update 拉不到新版——这时必须连带清理整个 repo/https---packagist.org/。
