“Could not delete”主因是文件被进程占用而非权限问题，需用lsof（Linux/macOS）或handle.exe（Windows）定位并终止相关进程；Windows下“Access is denied”则多为ACL权限缺失，应修复目录写入权限或重设cache-dir路径。
clear-cache 报“Could not delete”不是权限问题，而是文件被锁住
绝大多数 Could not delete 错误，根本不是目录没权限，而是某个进程正占用着缓存文件。PHP 自身、IDE（如 PhpStorm/VS Code）、杀毒软件、Web 服务器（Apache/Nginx）甚至 Git 进程都可能持有句柄。
Linux/macOS 下快速确认：运行 lsof +D $(composer config --global cache-dir)，它会列出所有正在访问该目录的进程；Windows 需用 Sysinternals 的 handle.exe -p php.exe，查出 PID 后用任务管理器或 taskkill /f /pid {PID} 结束。
临时解法比硬删更安全：关闭 IDE、停掉 php -S 或 artisan serve、重启终端——这些操作往往比反复重试 clear-cache 更快见效。
报“Access is denied”且路径含 cache 或 repo/https---，大概率是 Windows ACL 权限错
在 Windows 上，composer clear-cache 报 Access is denied，同时错误里出现 cache 或 repo/https--- 字样，基本可断定是 %APPDATA%\Roaming\Composer\Cache 目录对当前用户缺少写入权限，而非缓存损坏。
修复方式有三种：
- 图形界面：右键该目录 → “属性” → “安全” → “编辑” → “添加”当前用户名 → 勾选“完全控制”
- 命令行（管理员 PowerShell）：
icacls "$env:APPDATA\Roaming\Composer\Cache" /grant "$env:USERNAME:(OI)(CI)F" /t - 彻底规避：
composer config -g cache-dir "%USERPROFILE%\composer-cache"，再手动创建该目录
注意：不要跳过确认步骤直接删目录，否则重设路径前所有全局命令都会失效。
执行后提示“Cache directory does not exist”或大小没变，先查路径和归属
clear-cache 没反应，常见原因是它清的压根不是你认为的那个目录。必须先确认两点：
- 真实缓存路径：
composer config --global cache-dir输出的才是 Composer 当前认的路径 - 目录属主是否匹配当前用户：
ls -ld $(composer config --global cache-dir)（Linux/macOS）或icacls "%APPDATA%\Roaming\Composer\Cache"（Windows）
如果属主是 root 或其他用户，说明之前用 sudo composer install 污染过，此时 clear-cache 会静默跳过——修复命令是：sudo chown -R $USER:$USER $(composer config --global cache-dir)。
CI/CD 中 clear-cache 反复失败，本质是多 Job 共享缓存路径引发竞态
Jenkins 或 GitHub Actions 多个 Job 并发执行时，若共用默认缓存路径（如 ~/.composer/cache），就可能出现 A Job 正在删 vcs/，B Job 同时往里写 Git 裸仓库，结果报 Directory not empty 或 Access is denied。
这不是命令问题，而是架构问题。唯一可靠解法是隔离缓存路径：
- Linux/macOS Pipeline：
export COMPOSER_CACHE_DIR="${WORKSPACE}/.composer-cache" - Windows：
set COMPOSER_CACHE_DIR="%WORKSPACE%\.composer-cache"
每个 Job 独占缓存，clear-cache 和 install 就不会互相干扰。手动删目录虽快，但 CI 场景下极易触发 Corrupted cache file 报错，务必确保无后台进程在写入。
