composer install 按 composer.lock 精确还原依赖，用于团队协作和部署；composer update 按 composer.json 重新解析并升级兼容版本，仅在需更新依赖时使用，且必须提交新 lock 文件。
composer install 和 composer update 到底该用哪个
装依赖时最常混淆的两个命令，本质区别在于：前者按 composer.lock 精确还原，后者按 composer.json 重新解析并升级到最新兼容版本。
- 团队协作或上线部署必须用
composer install——它跳过版本计算，直接读composer.lock，速度快、结果确定 - 只有你明确想更新某包（比如修复安全漏洞）或新增/修改了
composer.json中的依赖，才运行composer update -
composer update默认更新所有包，加--with-dependencies会连带更新子依赖；但更安全的做法是限定范围：composer update monolog/monolog - 误用
composer update后没提交新的composer.lock，会导致其他成员执行install时环境不一致
为什么 --no-dev 参数经常被漏掉
生产环境部署时，--no-dev 不是可选项，而是必须项。它禁用 require-dev 下的所有包（如 phpunit、phpcs），避免把开发工具打进线上环境。
- 漏加会导致：线上自动加载器变大、内存占用升高、潜在安全风险（比如暴露测试路由或调试接口）
- Docker 构建中常见错误写法：
composer install放在基础镜像里，没加--no-dev，结果vendor/里塞了一堆不该存在的包 - CI/CD 流水线建议统一加
--no-dev --optimize-autoloader --classmap-authoritative，后两者能显著提升自动加载性能
autoload 的 psr-4 和 classmap 混用时要注意什么
自定义类自动加载配置写错，会导致 Class not found 错误，而且这个错误不报路径，只报类名，排查起来特别绕。
-
psr-4要求命名空间前缀 + 目录映射严格匹配，比如"App\": "src/"表示AppFooBar必须位于src/Foo/Bar.php -
classmap是扫描指定目录下所有.php文件并生成类名→文件路径的静态映射，适合老项目或含非标准命名的类，但每次增删文件后要手动跑composer dump-autoload - 如果同时用了两者，
psr-4匹配失败才会 fallback 到classmap，所以别指望 classmap 能“兜底”psr-4 的路径错误 - 改完
autoload后，必须执行composer dump-autoload，否则配置不生效；加-o参数可生成优化后的 classmap
composer create-project 为什么有时卡住或拉错版本
用 create-project 初始化新项目时，看似简单，实则受模板版本、稳定性标识、本地配置三重影响。
- 默认行为是安装
stable版本，但很多开源项目主干是dev-main，这时得显式指定：composer create-project laravel/laravel myapp dev-main - 如果本地
config.stability设为dev，可能导致意外拉取不稳定分支，建议初始化时加--stability=stable - 国内用户常因 packagist.org 访问慢导致超时，可提前设置镜像：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意该镜像已停用，应换为https://packagist.laravel-china.com或阿里云源） - 创建完别忘了检查生成的
composer.lock是否包含预期版本，尤其留意packages-dev部分是否混入了开发依赖
update 加了 --with-all-dependencies 却没意识到它会穿透多层依赖树，或者 autoload 里一个斜杠方向写反，让整个命名空间失效。 
