composer包损坏时应优先清缓存而非重装vendor；报校验错误多因本地缓存损坏，运行composer clear-cache后重试install即可；重装单个扩展用composer reinstall（2.2+）或remove+require；行为异常先刷新autoload、检查配置与缓存。
Composer 包损坏时，直接删 vendor + composer.lock 再全量重装是最低效的做法；真正要修的往往只是单个扩展，而且多数时候根本不用重装。
composer install 或 update 报 corrupted package 或 invalid checksum
这类错误通常不是包本身坏了，而是本地缓存里的 zip/tar 包在下载或解压过程中出错（比如网络中断、磁盘写入失败），导致校验和不匹配。Composer 会拒绝使用它，但不会自动清理坏缓存。
- 先运行
composer clear-cache—— 这能清掉所有已损坏或过期的归档缓存 - 再试
composer install；如果只缺某个包，它会重新下载，跳过其他已验证通过的 - 别急着删
vendor/或composer.lock，否则会触发整棵树重建，浪费时间且可能引入新兼容性问题
想重装某个特定扩展（比如 monolog/monolog）而不动其他依赖
用 composer reinstall 最干净，但它从 Composer 2.2+ 才支持。低于这个版本，就得绕一下：
- 确认当前安装的是哪个版本：
composer show monolog/monolog - 强制卸载再重装：
composer remove monolog/monolog && composer require monolog/monolog - 如果只是想换版本（比如从
^2.8升到^3.0），直接composer require monolog/monolog:^3.0就行，Composer 会自动处理依赖冲突 - 注意：某些扩展带脚本（如
post-install-cmd），remove + require会重新触发，而reinstall默认也会 —— 这是预期行为，不是 bug
执行 composer update 后某个扩展行为异常，怀疑是版本漂移或配置没生效
不是所有“异常”都来自代码损坏，更常见的是 autoload 没刷新、配置没重载、或扩展内部缓存未清除。
- 先跑
composer dump-autoload -o，确保类映射是最新的（尤其改过autoload配置后） - 检查该扩展是否注册了服务提供者（laravel）或启用钩子（symfony），有时
config/app.php或config/bundles.php改了但没重启 CLI 进程 - 有些扩展（如
laravel/scout）会在首次运行时生成缓存文件，手动删掉storage/framework/cache下对应项再试 - 别盲目
composer update vendor/package—— 它实际等价于composer update全局，只是限制了包名范围；真要精准控制，用--with-dependencies或--no-update组合更稳妥
最常被忽略的一点：Composer 的「损坏」提示，90% 以上发生在 ~/.composer/cache 或 vendor/composer/installed.json 文件损坏，而不是源码本身。修之前先看日志里报错路径指向哪里，比直接重装快得多。