Composer缓存目录默认为Linux/macOS的~/.composer/cache、Windows的%APPDATA%\Composer\Cache；运行composer config --global cache-dir可确认当前路径，终端出现“Writing ... into cache”或跳过下载即表示命中缓存。
composer 的缓存目录在哪，怎么确认它真在用？
Composer 默认会把下载的包（zip/tar、dist 包、元数据）缓存在本地，但很多人改了配置或换了系统后根本不知道缓存是否生效，甚至误以为没缓存——其实只是路径变了或者被清空了。
运行 composer config --global cache-dir 能直接看到当前全局缓存路径；如果是项目级配置，去掉 --global 查项目 composer.json 里的 cache-dir 配置项。Linux/macOS 下默认是 ~/.composer/cache，Windows 是 %APPDATA%\Composer\Cache。
- 缓存不生效常见原因：权限不足（比如用
sudo composer install写入了 root 权限的缓存，后续普通用户就无法读取） - 如果用了
COMPOSER_CACHE_DIR环境变量，它会覆盖所有配置，优先级最高 - 执行
composer clear-cache后，下次 install/update 才会重新下载并写入缓存，不是“立刻生效”，而是“下次触发”
composer install/update 时到底用没用缓存？
看终端输出最直接：成功命中缓存时，你会看到类似 Downloading https://repo.packagist.org/p2/monolog/monolog.json 这类请求，但如果后面紧跟着 Writing /path/to/cache/files/xxx.zip into cache 或 Using version ^2.10 for monolog/monolog 并跳过下载行，说明 dist 包是从缓存读的。
- 只对
dist类型包（zip/tar）做文件级缓存；source类型（git clone）默认不缓存，除非你显式加了"preferred-install": "dist" -
composer update比install更容易绕过缓存——因为要重新解析依赖树、拉新元数据（p2/JSON），这些也走缓存，但一旦元数据过期（默认 15 分钟），就会重拉 - 想强制走缓存不发网络请求？加
--no-plugins --no-scripts --prefer-dist --offline，但注意：--offline会直接报错如果缓存里没有所需包，不是静默降级
怎么安全清理部分缓存，而不是全删？
composer clear-cache 是最粗暴的，它清整个缓存目录。但实际中你可能只想删某个包的旧版本、或清理损坏的 zip 文件，又不想影响其他包。
- 缓存结构是按 vendor/name + hash 分层的，例如
cache/files/monolog/monolog/7a8b9c1.../monolog-monolog-7a8b9c1-zip，可手动进目录按包名删子目录 - 更稳妥的做法：先用
composer show monolog/monolog确认当前装的是哪个版本，再进缓存目录找对应 hash 文件夹删掉 - 别直接
rm -rf ~/.composer/cache后还顺手删了~/.composer/auth.json——那个是凭据文件，不属于缓存，删了会导致私有库认证失败 - CI 场景下建议用
composer install --no-interaction --prefer-dist --optimize-autoloader，它会自动复用已有缓存，且不会生成 dev-only 的文件（如 tests/），减少缓存体积
自建私有仓库时，缓存行为有什么不同？
私有 repo（比如 Satis、Private Packagist、GitLab Composer Registry）的元数据和 dist 包一样走缓存，但有几个关键差异点容易翻车。
- 如果你用
type: "package"手动定义某个包，它的 dist URL 不经过 Composer 的标准缓存逻辑——每次都会重新下载，哪怕 URL 没变 - 私有仓库返回的
packages.json如果没带cache-control: public, max-age=3600，Composer 可能频繁重拉，导致缓存形同虚设 - 用
composer config repositories.myrepo composer https://my-repo.example.com添加源后，记得检查composer config --list | grep cache，确保没意外启用cache-ttl过短（默认 15 秒太激进） - 私有包的 dist ZIP 如果签名不一致（比如构建脚本每次生成不同 hash 的压缩包），Composer 会认为是新版本，反复下载——这不是缓存问题，是发布流程缺陷
cache-dir 输出、看终端那几行下载日志、删缓存前先 ls -la 看一眼结构，比查文档更快定位问题。 
