composer install 必须在含 composer.json 和 composer.lock 的项目根目录执行，它严格按 lock 文件安装依赖；若 lock 缺失，应优先从 git 恢复而非运行 update，否则会破坏版本一致性。
composer install 必须在有 composer.json 和 composer.lock 的目录下运行
直接执行 composer install 不会“自动创建依赖”，它只做一件事：按 composer.lock 里锁定的版本，把包精确安装到 vendor/ 目录。如果项目刚初始化、还没生成 composer.lock，命令会退回到读 composer.json 并生成新 lock 文件——但这不是推荐路径，尤其在线上环境。
常见错误现象：composer install 报错 “Could not find a composer.json file” 或 “Your requirements could not be resolved”，往往是因为当前目录不对，或 composer.json 缺少 require 字段（比如只写了作者信息没写依赖）。
- 确保你在项目根目录（即
composer.json所在目录）执行命令 - 如果刚用
composer init初始化，且一路回车没加任何依赖，composer.json里会没有"require":{}，此时composer install会成功但vendor/为空——这不是 bug，是预期行为 - 若想装默认 autoload 支持（比如 PSR-4 自动映射），至少要让
composer.json包含"autoload":{"psr-4":{"App\":"src/"}}这类配置，否则vendor/autoload.php虽存在，但不会加载你自己的类
线上部署必须用 composer install --no-dev
开发时可能需要 phpunit、laravel/pint 等工具，它们通常写在 composer.json 的 "require-dev" 里。composer install 默认会装全部，但生产环境不该跑测试工具、代码格式化器，更不该暴露 dev-only 的 autoloader 配置。
典型风险：某次上线漏加 --no-dev，导致 vendor/bin/phpunit 被部署到线上，被扫描工具误报为可执行入口；或者 symfony/var-dumper 在生产环境触发敏感数据输出。
-
composer install --no-dev会跳过require-dev里的所有包，并忽略其 autoload 规则 - 该命令要求
composer.lock已存在且由开发环境生成——所以开发机必须先运行完整composer install提交 lock 文件 - CI/CD 流程中建议显式加
--optimize-autoloader（等价于-o），它会生成 classmap 提升加载性能，尤其对无命名空间的传统文件有效
composer install 失败时优先检查 PHP 版本和扩展
报错如 The requested PHP extension mbstring is missing from your system 或 Your lock file does not contain a compatible set of packages，90% 不是 Composer 本身问题，而是 PHP 环境不匹配。
Composer 会严格校验 composer.json 里声明的 "php": "^8.1" 或类似约束，也会检查扩展是否启用。很多团队在 Docker 里用 PHP 8.3，但宿主机本地是 7.4，composer install 就会失败，哪怕只是本地验证。
- 运行
php -v和php -m确认当前 CLI 使用的 PHP 版本和已启用扩展（重点：openssl、mbstring、json、zlib） - 注意 CLI 和 Web SAPI 的 PHP 配置可能不同：Apache mod_php 加载的
php.ini和终端php -i显示的可能不是同一份 - 若用 XAMPP/MAMP，务必确认终端调用的是它们自带的 PHP，而不是系统自带的老版本——可通过
which php和php -i | grep "Loaded Configuration File"双重验证
不要用 composer update 替代 composer install
composer update 会重新解析整个依赖树，升级所有包到满足约束的最新兼容版本，并重写 composer.lock。composer install 则完全不动 lock 文件，只照着它装——这是二者本质区别，也是协作项目里最常被搞混的点。
现象举例：开发 A 提交了新功能并跑了 composer update，push 了新的 composer.lock；开发 B 拉取后只运行 composer install，结果发现本地 vendor/ 和 A 的完全一致；但如果 B 错误地也跑 composer.update，就可能引入未测试过的版本，导致 CI 构建失败。
- 团队协作中，
composer install是标准动作；composer update应仅在明确需升级依赖时由负责人执行，并伴随充分测试 - CI 脚本里严禁出现
composer update，必须固定为composer install --no-dev -o - 如果
composer.lock被意外删除，应先git checkout -- composer.lock恢复，而不是立刻composer install——后者会生成新 lock，破坏版本一致性
实际项目里最容易被忽略的，是 composer.json 中 "config": {"platform-check": true} 这个默认开启的检查项——它会让 composer install 在 PHP 版本不匹配时直接中断，而不是静默降级。这个行为在跨环境部署时特别关键，但很多人直到线上报错才意识到自己本地 PHP 版本比服务器高。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
