应优先修复缓存目录所有权而非盲目赋权：Linux/macOS用sudo chown -R $USER:$USER ~/.composer/cache，Windows用管理员PowerShell执行icacls命令；或改用天然可写路径如/tmp/composer-cache并确保创建及权限正确。
确认当前缓存路径是否可写
执行 composer config --global cache-dir 查看路径，再运行 composer clear-cache ——如果报 Access is denied 或 Permission denied，说明该目录当前用户无写权限。Linux/macOS 下常见路径如 ~/.composer/cache，Windows 下多为 %APPDATA%\Roaming\Composer\Cache。别只看输出值，要实际测试写入能力。
修复所有权，不是 chmod 777
权限冲突绝大多数是属主错配，不是权限数字太小。用 ls -ld $(composer config --global cache-dir) 检查输出第一列：若不是当前用户名（$(whoami)），就确认问题根源。正确做法是：
-
sudo chown -R $USER:$USER ~/.composer/cache（Linux/macOS） - Windows 下用
icacls "$env:APPDATA\Roaming\Composer\Cache" /grant "$env:USERNAME:(OI)(CI)F" /t（管理员 PowerShell） - 绝对不要
chmod -R 777 ~/.composer/cache：这会触发 CI 安全扫描失败、Git 报告 ownership changed、且无法解决根本的所有权错位
换一个天然可写的缓存路径
绕过默认路径是最稳妥的长期方案，尤其适合 Docker、CI 或受限策略环境：
- 执行
composer config -g cache-dir "/tmp/composer-cache"（Linux/macOS）或composer config -g cache-dir "%USERPROFILE%\composer-cache"（Windows） - 手动创建并确保可写：
mkdir -p /tmp/composer-cache，然后chown $USER:$USER /tmp/composer-cache - 注意：环境变量
COMPOSER_CACHE_DIR优先级更高，但只对单次进程有效；设了它就得保证路径存在且可写，否则 Composer 会静默 fallback 到默认路径，不报错也不提示
CI/CD 中必须显式声明缓存路径
GitHub Actions、GitLab CI 等默认不会继承本地 cache-dir 配置。GitLab 尤其典型：即使你 cache: 声明了路径，Composer 仍往 ~/.composer/cache 写，导致缓存未命中。必须显式覆盖：
- GitHub Actions：在
cachestep 后加run: composer config -g cache-dir ~/.composer/cache - GitLab CI：在
before_script中加export COMPOSER_CACHE_DIR="$CI_PROJECT_DIR/.composer-cache"，并提前mkdir -p $CI_PROJECT_DIR/.composer-cache - 验证是否生效：在 install 步骤后加
composer diag | grep "Cache directory"，确认输出路径与你设定的一致
最常被忽略的是：改完 cache-dir 后，旧缓存不会自动迁移，composer clear-cache 也只清新路径。若要复用历史包，得手动 rsync -a ~/.composer/cache/ /new/path/，否则首次 install 仍会重下全部包。
