composer install 严格按 composer.lock 安装锁定版本，确保环境一致；composer update 忽略 lock 文件，重新解析 composer.json 并升级依赖，可能引入不兼容变更。
Composer 是 PHP 的依赖管理工具，不是包管理器，也不是插件或 IDE 扩展——它不改写你的代码、不注入运行时逻辑、不提供语法高亮。它只做三件事：解析 composer.json 里声明的依赖关系，下载对应版本的代码到 vendor/ 目录，并生成可直接 require 的自动加载逻辑。
composer install 和 composer update 的区别在哪
这是最常被混淆的操作，直接决定你项目是否可复现：
-
composer install读取已存在的composer.lock文件，严格安装其中锁定的版本——适合部署、CI、新同事拉代码后首次构建 -
composer update忽略composer.lock（即使存在），重新解析composer.json中的版本约束（如"^2.0"或"1.2.*"），升级到满足条件的最新兼容版本——仅应在明确要更新依赖时执行 - 如果项目没有
composer.lock，install会退化为update行为，结果不可控 - 团队协作中，
composer.lock必须提交进 Git；删掉它再跑install，等同于裸跑update
autoload 配置写错会导致类找不到，但报错不提示 autoload 问题
常见现象是 Class 'YourNamespaceLogger' not found，而你确认文件路径和命名都对——大概率是 autoload 块没生效或配置有误：
-
psr-4映射必须以反斜杠结尾："YourNamespace\": "src/"，少一个就不匹配 - 路径是相对于
composer.json所在目录的，不是相对于vendor/或入口脚本 - 修改
autoload后必须运行composer dump-autoload，否则变更不会写入vendor/autoload.php - 若用
files加载全局函数，路径也必须存在且可读，否则dump-autoload会静默失败（不报错，但函数仍不可用）
为什么 vendor 目录不该提交到 Git，但 composer.lock 必须提交
这是协作一致性的底层机制：
立即学习“PHP免费学习笔记（深入）”；
-
vendor/是产物，体积大、易变、含平台相关二进制（如某些扩展的 .so/.dll），且重复存储——Git 里存它纯属冗余 -
composer.lock是“确定性快照”：记录每个包的精确 commit hash（对 VCS 包）或 dist zip 校验和（对 dist 包），保证install在任何机器上还原出完全相同的依赖树 - 不提交
lock文件 = 放弃版本控制权，等于把“用哪个版本的 monolog”交给网络、镜像源、甚至 Packagist 的缓存状态来决定 - CI 环境通常禁用
update，只允许install，就是靠lock文件兜底
国内环境装包慢或失败，别只换镜像源
镜像源（如阿里云、腾讯云）能缓解下载慢，但很多失败根本不在下载层：
- 先确认 PHP 版本 ≥ 7.4（
php -v），openssl扩展已启用（php -m | grep openssl），否则连 HTTPS 源都连不上 - 错误信息含
file could not be downloaded或SSL certificate problem，优先检查系统 CA 证书（Linux 常见于 ca-certificates 包过旧） - 使用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/设置全局镜像，比每次加-vvv查日志更直接 - 若仍卡在某个包，尝试加
--prefer-dist（强制走压缩包而非 git clone），尤其对带大量历史的 GitHub 仓库有效
composer 的复杂点从来不在命令本身，而在于它把「版本语义」、「自动加载路径绑定」、「锁文件与声明文件的职责分离」全压进一个看似简单的 JSON 文件里。稍一松懈，就会在 CI 失败、本地能跑线上报错、或者某次 update 后整个 autoload 失效——这些都不是 Composer 的 bug，而是它在忠实地执行你写的规则。
