cache-dir和temp-dir是两个完全不同的目录：前者存储可复用的包归档与元数据，后者仅用于单次命令执行的临时解压与生成，权限问题需分别排查修复。
Composer的cache-dir和temp-dir根本不是同一个目录
很多人看到composer clear-cache就以为它清的是“所有临时文件”，其实它只动cache-dir，完全不碰temp-dir。这两个目录在功能、生命周期和权限要求上完全不同——混淆它们，是Windows下报“Access is denied”却反复删错目录的主因。
cache-dir存的是可复用的包元数据和归档文件
cache-dir里放的是从Packagist下载下来的zip/tar包、解析后的composer.json元数据、以及已安装包的哈希索引。它的核心价值是「避免重复下载」：下次composer install时，如果版本没变，Composer会直接解压缓存里的zip，跳过网络请求。
- 默认路径：
%APPDATA%\Roaming\Composer\Cache（Windows）、~/.composer/cache（Linux/macOS） - 手动查路径：
composer config --global cache-dir - 内容可安全删除，但删完首次
install会变慢；删错权限会导致Cache::get()返回null、autoload.php写入失败 - 不建议用
rm -rf vendor代替清缓存——vendor是运行时产物，cache是下载层中间件
temp-dir存的是单次命令执行中的临时解压和生成物
temp-dir是Composer执行过程中用的“中转站”：比如下载完一个zip包后，先解压到temp-dir里校验完整性，再挪到vendor/；又比如composer dump-autoload -o生成优化类映射时，会先写到temp-dir再原子替换vendor/composer/autoload_classmap.php。
- 默认路径：
%TEMP%\composer（Windows）、/tmp（Linux/macOS） - 查路径：
composer config --global temp-dir - 内容不可复用，每次命令结束自动清理（除非进程崩溃残留）
- 权限出问题时，现象是
Could not extract ... permission denied或Failed to write ... to temp-dir，而非cache相关报错 - Windows下常见陷阱：杀毒软件锁定
%TEMP%子目录，或组策略禁止脚本写%TEMP%
两个目录都出权限问题，修复逻辑完全不同
Windows下最典型的误操作是：看到Access is denied就去删%APPDATA%\Roaming\Composer\Cache，结果发现composer install还是卡住——因为真正被锁的是%TEMP%\composer，而删掉cache后还可能触发Composer重试时反复创建带错误ACL的子目录。
- 确认是哪个目录的问题：
composer clear-cache报错 →cache-dir；composer install中途失败并提示temp或extract→temp-dir - 修
cache-dir：用icacls赋权或composer config -g cache-dir换路径（推荐%USERPROFILE%\composer-cache） - 修
temp-dir：检查%TEMP%环境变量是否指向可写位置；若用Docker或CI，需显式挂载/tmp并设chmod 777 - 两者都别硬删：删
cache-dir后没重设路径，后续全局命令会失效；删temp-dir残留文件可能被锁死，需重启explorer.exe或清空%TEMP%再试
真正要盯住的，从来不是“删不删”，而是“谁在写、往哪写、有没有权限写”。Windows下这两个目录的ACL继承规则不同，cache-dir需要用户级完全控制，temp-dir依赖系统级临时目录策略——混着修，只会让问题从一个坑跳进另一个坑。
