Composer不是标准而是基石，因其是PHP生态中事实上的依赖管理工具，由实践规模、框架采纳率和社区共识确立；它不靠强制力，而靠不可替代性——Laravel、Symfony等主流框架均依赖其运行。
Composer 不是行业标准，它是现代 PHP 生态中事实上的依赖管理工具，其地位由实践规模、框架采纳率和社区共识共同确立。
Composer 为什么不是“标准”而是“基石”
标准（如 PSR 系列）由 PHP-FIG 组织制定，需经投票、草案、正式发布流程；而 Composer 是一个开源命令行工具，由 Jordi Boggiano 和 Nils Adermann 于 2012 年发起，靠解决真实痛点赢得广泛采用。它不靠强制力，靠不可替代性——没有它，Laravel、Symfony、Drupal 8+、Magento 2 都无法以当前形态存在。
关键区别在于：
- PSR-4 是
autoload映射规范，属于“怎么写代码才可被自动加载”的约定； -
composer是执行者，它读取composer.json，按 PSR-4 规则生成vendor/autoload.php，并确保类文件物理路径与命名空间严格对应； - 你可以在不使用 Composer 的项目里手动实现 PSR-4 加载逻辑，但没人会这么做——因为
composer dump-autoload一行就搞定。
composer.json 中的 require 和 require-dev 怎么影响部署
这两个字段直接决定哪些包会被装进 vendor/，进而影响生产环境体积、启动速度和安全面。
立即学习“PHP免费学习笔记（深入）”；
常见误操作：
- 把测试工具（如
phpunit/phpunit）写在require里 → 生产环境多装几十 MB 无用代码； - 用
dev-master或@dev作为版本约束 →composer install在不同机器上可能拉到不一致的 commit，破坏composer.lock的确定性； - 忽略
platform配置 → 本地 PHP 8.2 开发，服务器是 PHP 8.1，composer install却没报错，直到运行时报Attribute不存在。
正确做法是：生产部署始终用 composer install --no-dev --optimize-autoloader，且确保 composer.lock 已提交到 Git。
vendor 目录为什么不能直接提交到 Git
因为 vendor/ 是派生产物，不是源码。它的内容完全由 composer.json + composer.lock + 当前 PHP 环境决定。
硬提交 vendor/ 带来的实际问题：
- Git 历史臃肿：一次
monolog升级可能带来上千个文件变更，diff 失去意义； - 协作冲突：两人同时更新不同包，
vendor/合并几乎必然失败； - 镜像失效风险：某天 packagist.org 某个包被撤下，你本地
vendor/还在，但新同事git clone后无法复现环境。
例外场景极少，比如离线封闭环境且禁止任何网络请求，此时应生成 vendor.zip 并走内部分发流程，而非把整个目录塞进 Git。
composer install 和 composer update 的本质区别
composer install 是“按图索骥”：只读 composer.lock，确保所有机器安装完全一致的依赖树；composer update 是“重新规划路线”：忽略 lock 文件，根据 composer.json 中的版本约束重新解析依赖图，并更新 lock 文件。
线上部署必须用 install；开发中升级依赖才用 update。容易踩的坑：
- CI/CD 脚本里误写
composer update→ 每次构建都可能引入未测过的次要版本变更； - 团队没养成
git add composer.lock习惯 →install在别人机器上还原不出你的环境； - 用
^锁定大版本（如^8.0）却没跑全量测试 →update后可能因symfony/console的 BC break 导致命令行崩溃。
真正麻烦的从来不是命令本身，而是人对 composer.lock 文件意图的理解偏差——它不是缓存，是契约。
