composer本地缓存目录默认为linux/macos的~/.composer/cache、windows的%appdata%\composer\cache，但实际路径须用composer config --global cache-dir确认，且受composer_cache_dir环境变量最高优先级覆盖。
Composer本地缓存目录在哪？怎么确认它真实路径
Composer的缓存默认存放在用户主目录下的 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows），但实际路径可能被 COMPOSER_CACHE_DIR 环境变量覆盖。直接硬编码路径会出错，务必用命令查实：
- 运行
composer config --global cache-dir获取当前生效路径 - 该路径下通常含
archive/（下载的zip/tar包）、repo/（packagist元数据）、files/（解压后的源码）等子目录 - 注意：不同Composer版本（如 2.x vs 1.x）缓存结构一致，但某些插件可能额外写入子目录，备份前建议
ls -la或dir扫一眼
如何打包整个缓存目录且保留权限与时间戳
用 tar（Linux/macOS）或 7z（Windows）打包，核心是不丢元数据——尤其是 repo/ 下的JSON文件时间戳影响后续 composer update 的缓存命中逻辑：
- Linux/macOS：执行
tar -czf composer-cache-$(date +%Y%m%d).tar.gz -C $(composer config --global cache-dir) . - Windows（PowerShell）：先
$cache = composer config --global cache-dir，再7z a -t7z composer-cache-$(Get-Date -Format 'yyyyMMdd').7z $cache\* - 避免用
zip：Windows原生命令和部分GUI工具默认丢弃文件权限及符号链接，tar或7z更可靠 - 打包前建议停掉所有正在运行的
composer进程，防止缓存文件被写入中导致损坏
还原缓存时为什么不能直接解压到空目录
还原不是“解压完就完事”，关键在于让Composer识别新路径为合法缓存——否则下次 install 仍会重新下载：
- 必须清空原缓存目录：
rm -rf $(composer config --global cache-dir)/*（Linux/macOS）或Remove-Item -Recurse -Force $cache\*（PowerShell） - 解压时需保持目录结构完整：例如
tar -xzf composer-cache-20260716.tar.gz -C $(composer config --global cache-dir)，目标路径必须是缓存根目录，不是其父目录 - 检查权限：若还原后
composer install报Permission denied，大概率是解压用户与当前运行用户不一致，用chown -R $USER:$(id -gn) $(composer config --global cache-dir)修复 - 验证是否生效：执行
composer show monolog/monolog --no-plugins，观察是否显示 “Loading from cache” 而非 “Downloading…”
哪些场景下备份/还原会失效
缓存不是万能镜像，以下情况备份包无法跳过网络操作：
- Composer版本升级（如从 2.2.x 升到 2.5.x）：缓存格式可能变更，旧备份还原后会被自动清理并重建
- 启用了
composer config --global cache-files-ttl 0：强制禁用文件缓存，备份的archive/无效 - 项目使用了私有仓库（如
git@或自建Satis）：这些仓库的元数据不在默认缓存中，需单独导出repo/github.com/类似路径（如果存在） - 还原后首次运行
composer update：即使缓存存在，Packagist索引仍会发起HTTP请求校验更新，这是设计使然，无法绕过
真正省时间的点在于：重复 install 同一 lock 文件、离线重装依赖、CI 构建中复用缓存——其他场景别强求“完全离线”。
