composer 默认不自动检查更新，仅在运行 composer update 时拉取远程元数据；加速方法包括用 composer install 或 composer update –locked 跳过元数据刷新；缓存过期由 cache-files-ttl（默认6个月）和 cache-repo-ttl 控制，可配置调整。
Composer 默认不检查更新频率，靠的是本地锁文件和缓存机制
Composer 本身没有“每 X 小时检查一次更新”这种内置定时策略。它只在 composer update 时才去远程仓库查版本，平时完全依赖 composer.lock 和本地包缓存。所谓“更新频率”，其实是你手动触发的节奏，以及缓存是否让下次 update 变快或变慢。
怎么让 composer update 跳过远程元数据刷新（省时间）
默认情况下，composer update 每次都会拉取 packagist.org 的 packages.json 元数据（约 10–20MB），这是最耗时环节。如果你确定没新版本、或只想装 lock 文件里已记录的包，就该跳过它：
- 加
--no-update不适用——那是跳过安装，不是跳过元数据刷新 - 正确做法是：
composer install（不是 update）：它完全忽略远程，只按composer.lock下载包，且走本地缓存 - 如果非要用
update但不想刷新元数据：加--prefer-dist --no-scripts没用；真正有效的是composer update --locked—— 它强制只重装 lock 文件里的精确版本，连版本比对都跳过 - 注意：
--locked要求 lock 文件存在且完整，否则报错Root package requires a lock file to be present
怎么控制 Composer 包缓存的过期时间（影响 update/install 速度）
Composer 缓存默认永不过期，但你可以通过环境变量或配置干预它的行为：
- 缓存位置由
COMPOSER_CACHE_DIR决定，默认是~/.composer/cache；改它不影响过期逻辑，只影响存放路径 - 真正控制“是否复用旧缓存”的是
cache-files-ttl配置项：它定义 dist 包（zip/tar）缓存的有效秒数，默认是15552000（6 个月） - 修改方式（任选其一）：
- 全局设为 1 天：
composer config -g cache-files-ttl 86400 - 项目级覆盖（写入
composer.json）："config": {"cache-files-ttl": 3600} - 临时生效（仅本次命令）：
COMPOSER_CACHE_FILES_TTL=3600 composer install
- 全局设为 1 天：
- 注意：
cache-files-ttl只管 dist 包缓存，不管元数据（packages.json）；后者由cache-repo-ttl控制，默认也是 6 个月，同样可配 - 清缓存别乱跑
composer clear-cache：它清的是整个缓存目录，包括你刚下了一半的 zip。真要刷 ttl，改配置 + 等它自然过期更稳妥
为什么有时 composer update 明明没改依赖却还去拉新包
这不是缓存失效，而是 Composer 在校验完整性时发现本地 dist 包缺失或哈希不匹配，就会重新下载。常见原因有：
- 你手动删过
vendor/或缓存目录里的某个包子目录，但没清 lock 文件或没运行install - 不同 PHP 版本下生成的 lock 文件用了
platform-check，导致同一份 lock 在 PHP 8.2 下认为某些包不可用，转而去找兼容版本 - 私有仓库返回的包信息变了（比如 maintainer 修改了
dist.url），Composer 发现哈希对不上，就会重下 -
composer update foo/bar单独更新一个包时，即使 lock 里有记录，它也会重新解析依赖图并可能升其他间接依赖——这不是缓存问题，是设计使然
缓存和锁文件不是保险柜，它们只保证“按声明安装”，不保证“绝对不联网”。真正想零网络操作，唯一可靠方式是：确保 composer.lock 存在、用 composer install、且所有 dist 包都在缓存里未过期。