Composer update显示“nothing to install or update”是因元数据缓存未更新：packages.json默认15分钟不过期，且clear-cache不清理它；项目级repositories字段会覆盖全局镜像；≥2.5用--refresh强制刷新，≤2.4需手动删除repo/https---packagist.org目录并同步清理composer.lock和vendor/composer/installed.json。
元数据缓存没更新，composer update 显示 “nothing to install or update”
这不是网络卡了，是 Composer 复用了本地缓存的 packages.json——它默认 15 分钟不过期，且 composer clear-cache 完全不碰这个文件。更隐蔽的是：只要 composer.json 里有 repositories 字段，全局镜像配置（比如阿里云源）就直接失效。
验证当前生效源：composer config repo.packagist；确认下载地址：composer require monolog/monolog --no-install -vvv，滚动日志里找 Downloading https:// 那行。
- Composer ≥2.5：直接运行
composer update --refresh，它会丢弃所有元数据缓存并重拉packages.json和 provider 映射 - Composer ≤2.4：必须手动删掉整个元数据目录：
Linux/macOS：rm -rf $(composer config --global cache-dir)/repo/https---packagist.org
Windows PowerShell：Remove-Item "$env:APPDATA\Composer\Cache\Repo\https---packagist.org" -Recurse -Force - 删完后务必同步清理
composer.lock和vendor/composer/installed.json，否则新旧哈希对不上，install会静默失败
备份元数据时 hash verification failed
报这个错不是 ZIP 包坏了，而是 composer.lock 里硬编码的 dist.sha256 和镜像源实际提供的包元数据不一致——常见于国内镜像同步延迟或精简字段（比如删了 autoload、没随新 tag 更新哈希）。
- 别只清缓存：
composer clear-cache只清 ZIP 包，不改composer.lock里的旧哈希 - 别只删
vendor/：没重生成composer.lock，下次install还拿旧哈希去比新包 - 先禁用镜像：
composer config -g --unset repos.packagist，再设回官方源：composer config -g repo.packagist composer https://packagist.org - 然后彻底清理：
rm -rf vendor composer.lock（Windows 用rd /s /q vendor & del composer.lock） - 最后强制重装：
composer install --no-cache --force-checksums
离线环境执行 composer install 报校验失败
即使 vendor/ 和 composer.lock 都完整，离线时也会卡在远程元数据校验上——Composer 默认要确认包是否存在、URL 是否可访问。所有 --no-xxx 参数在没关网络开关时都无效。
- 必须设环境变量：
COMPOSER_DISABLE_NETWORK=1（Linux/macOS）或set COMPOSER_DISABLE_NETWORK=1（Windows cmd） - 同时加参数：
--no-plugins --no-scripts --no-autoloader，防止插件或脚本隐式联网 - 检查全局配置残留：
composer config --global repo.packagist，若有值且非false，需运行composer config --global repo.packagist false彻底禁用 - 装完立刻补一记：
composer dump-autoload -o，否则运行时报Class not found
PHP 版本不一致导致“校验失败”其实是假象
看到 This package requires php ^8.3 but your PHP version (8.1.25) does not satisfy that requirement，不是哈希真错了，而是 Composer 用 CLI 的 PHP 版本（php -v）去解析依赖，而 Web 环境跑的是 PHP-FPM 8.3。两者版本不统一，autoload 文件生成逻辑不同，后续运行必崩。
- 临时方案：用完整路径调用目标版本，例如
/usr/bin/php8.3 composer install - 伪装方案：在
composer.json加"platform": {"php": "8.3.0"}，仅影响依赖解析，不改变实际运行环境 - 注意：这个字段不会让 PHP CLI 自动切版本，只是告诉 Composer “假装我有 8.3”，适合 CI 或多版本共存场景
真正麻烦的不是报错本身，而是三处状态不同步：缓存里的元数据、lock 文件里的哈希、vendor 目录里的已安装快照。任一滞后都会让其他两处“以为自己还对得上”，结果就是静默失败或半途崩溃。
