composer install失败而update能过，是因为install严格校验当前PHP版本和扩展是否匹配lock文件中记录的环境契约，而update会重新解析依赖并生成新lock；必须确保php -v和php -m满足lock要求，且lock文件已提交。
composer install 会失败，而 composer update 却能过——这不是工具问题，是环境和命令语义没对齐。真正优雅的依赖管理，不靠“重装”或“删锁文件”，而是让 composer.json 表达意图、composer.lock 兑现承诺、install 和 update 各守其责。
为什么 composer install 突然报错？先看 PHP 版本和扩展是否匹配锁文件
错误现象：Your requirements could not be resolved 或 ext-gd is missing，但本地明明装了 GD 扩展。
原因很直接：composer.lock 里记录了当时解析出的精确 PHP 版本（比如 "php": "^8.1"）和必须启用的扩展（如 ext-gd、ext-mbstring）。install 不做任何推导，只校验当前环境是否满足这些硬性条件。
- 运行
php -v确认版本不低于锁文件声明的最低版本 - 运行
php -m | grep -E "gd|mbstring|xml"检查扩展是否已加载 - 若用 Docker，检查
Dockerfile中是否漏写了docker-php-ext-install gd mbstring - 别急着删
composer.lock—— 它不是缓存，是环境契约
composer require 加版本号，到底该写 ^3.0 还是 3.0.*？
写法差异直接影响后续谁能升、升到哪，也决定你未来会不会被次版本里的破坏性变更打个措手不及。
-
^3.0：允许升到3.x任意次版本（如3.5.2），但禁止跨大版本（不进4.0）；这是现代项目推荐写法，贴合语义化版本主流节奏 -
3.0.*是旧式写法，等价于~3.0.0，只允许补丁级更新（如3.0.1），连3.1.0都不放行——过于保守，常导致安全补丁都拉不下来 - 遇到不守 semver 的老包（比如把 BC break 塞进
2.7.0），就用固定版本：composer require vendor/pkg:2.6.5 - 团队协作时，在
composer.json顶部加"prefer-stable": true，避免意外装上dev-main
CI/CD 流水线里该跑 composer install 还是 composer update？
答案唯一：composer install，且必须确保 composer.lock 已提交到 Git。
立即学习“PHP免费学习笔记（深入）”；
因为 update 会重新解析整个依赖树，哪怕 composer.json 没变，也可能因 Packagist 上某包新发了个兼容版本，导致构建产出不同——这直接破坏可重现性。
- CI 脚本中只允许出现
composer install --no-interaction --optimize-autoloader - 严禁在 CI 中执行
composer update，哪怕加了--dry-run - 如果真要升级依赖，应在开发机上跑
composer update --with-all-dependencies，再git commit composer.lock - 上线前用
composer show --outdated快速扫一遍哪些包有安全更新可选
纯 PHP 项目怎么确保 vendor/autoload.php 总能被正确加载？
没有框架兜底时，路径错一个字符就会 Fatal error: Class not found。
- 入口脚本第一行就该是：
require __DIR__ . '/vendor/autoload.php';（用__DIR__，不用dirname(__FILE__)或相对路径） - 如果项目结构是
public/index.php引用根目录下的vendor，路径就得写成require __DIR__ . '/../vendor/autoload.php'; - 运行前确认
vendor/autoload.php文件真实存在——它只在install或update成功后生成 - 不要把
vendor/提交进 Git，但composer.lock必须提交，否则协作和部署必然失准
composer.lock 不是中间产物，是环境一致性最轻量却最关键的锚点。很多人跳过它直接 update，结果本地能跑，CI 报错，线上崩溃——问题不在 Composer，而在没把它当契约来对待。 
