启用并正确使用 Composer 内置缓存机制可离线复用已下载包：确保全局缓存路径有效（如 ~/.composer/cache），首次 install 后 dist 包自动缓存，后续相同版本直接解压；禁用 --no-cache，避免清缓存，CI 中应挂载缓存目录而非 vendor。

composer install 时总卡在下载包，怎么离线复用已下载的包

Composer 默认每次 install 都会检查远程仓库并下载新版本（哪怕本地已有），根本原因在于它默认不复用 vendor/ 外的缓存，也不信任本地已有的 zip 或 dist 包。真正能跳过联网的，是启用并正确使用它的内置缓存机制。

• 确保全局缓存开启：composer config -g cache-dir 查看路径，通常为 ~/.composer/cache；若为空，运行 composer config -g cache-dir ~/.composer/cache 显式设置
• 首次 composer install 后，所有下载的 dist 包（.zip/.tar.gz）和元数据都会自动存进缓存目录，后续相同版本安装会直接解压缓存，不再走网络
• 不要手动删 ~/.composer/cache —— 这是最常见的“为什么又联网”原因；CI 环境里记得挂载该目录为持久卷
• 如果项目用了 packagist.org 以外的源（比如私有 repo），需确认该源支持 dist 类型且返回了正确的 dist.url 字段，否则 Composer 会 fallback 到 source 模式（即 git clone），无法命中缓存

composer update 强制走网络？关掉 --with-dependencies 和 --no-cache 是错的

update 本质是重新解析依赖树+获取最新元数据，所以必然要联网查版本号。但“下载包体”这一步可以避免 —— 关键不是关选项，而是让 Composer 相信缓存里的包就是你要的。

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 别加 --no-cache：它会绕过整个缓存逻辑，强制重下所有 dist 包
• 慎用 --with-dependencies：它会让子依赖也触发更新检查，扩大联网范围；如非必要，先用 composer update vendor/package 精确更新单个包
• 执行前先运行 composer clear-cache 再立刻 update？这是反模式——清缓存后反而必须重下；只在缓存损坏（如校验失败报 Invalid zip file）时才清
• 想彻底跳过元数据检查？可以用 composer install --prefer-dist --no-scripts --no-plugins，前提是 composer.lock 已存在且未变

内网环境没网，但有之前下载好的 vendor，怎么安全复用

直接拷贝 vendor/ 文件夹看似快，但极大概率出问题：autoload 生成逻辑依赖当前 PHP 版本、平台扩展、甚至 composer.json 里的 platform 配置。硬复制等于跳过所有验证。

• 把旧项目的 vendor/ 和 composer.lock 一起拷过来，然后运行 composer install --no-network —— 它会跳过所有网络请求，仅校验 lock 文件与 vendor 是否匹配，不一致就报错，不静默覆盖
• 如果提示 Package foo/bar is not installed，说明 vendor 缺文件或 autoload.php 损坏，此时应删掉整个 vendor/，再跑 composer install --no-network（前提是 lock 文件完整）
• 别碰 vendor/composer/autoload_*.php 手动改：这些文件由 composer dump-autoload 生成，内容含哈希和路径映射，手改极易导致类找不到

CI/CD 流水线里缓存 composer cache 目录比缓存 vendor 更可靠

缓存 vendor/ 看似直观，但不同 PHP 版本、不同扩展开启状态会导致 autoload 结果不同；而缓存 ~/.composer/cache 是纯数据层，无副作用，且能跨项目复用相同包版本。

• GitHub Actions 示例：用 actions/cache@v4 缓存路径 ~/.composer/cache，key 建议包含 composer.lock 的 hash，而非 PHP 版本（因为缓存包体本身不依赖 PHP）
• GitLab CI：在 cache: 下配置 key: "$CI_COMMIT_REF_SLUG-composer-cache"，paths 加上 "$HOME/.composer/cache"
• 注意权限：某些容器里 ~/.composer/cache 属于 root，但运行 composer 的用户是普通用户，导致写入失败；可在 job 开头加 chown -R $USER:$USER ~/.composer

缓存机制本身很稳，但 Composer 对“缓存可用”的判断非常严格：一个包的 sha256 校验不匹配、压缩包解压失败、甚至缓存目录被其他进程锁住，都会默默 fallback 到网络下载。遇到莫名联网，先看日志里有没有 Downloading... 前的 warning，那才是真正的线索。