新项目应使用 composer install 以确保依赖版本与 composer.lock 一致；composer update 会按 composer.json 重新解析并更新 lock 文件，仅用于升级或调试。
composer install 和 composer update 到底该用哪个
新项目拉代码后跑不起来，八成是搞混了这两个命令。composer install 读 composer.lock 装**完全一致**的依赖版本，适合部署和协作；composer update 忽略 lock 文件，按 composer.json 里写的约束（比如 "^8.0"）去拉最新匹配版，会改 lock 文件——除非你在升级依赖或调试兼容性问题，否则别乱跑。
- CI/CD 流水线、生产环境部署必须用
composer install，否则可能因依赖漂移导致行为不一致 -
composer update后记得提交更新后的composer.lock，不然队友install不出同样环境 - 想只更新某一个包？用
composer update vendor/package-name，避免全量重算依赖树
composer require 的 -dev、--no-update 和 --ignore-platform-reqs 怎么选
加依赖不是输完命令就完事，参数选错轻则装不上，重则破坏现有环境。
-
composer require package/name默认装到require区，上线也会带；加-dev才进require-dev，比如phpunit/phpunit - 如果只是临时加个包试试，不想立刻执行安装（比如当前 lock 文件有冲突），加
--no-update，它只改composer.json - 遇到
Your requirements could not be resolved且确认是 PHP 版本/扩展限制（比如本地 PHP 8.3 但包声明只支持 8.2），可临时加--ignore-platform-reqs强行装——但别提交，也不要在 CI 里用
为什么 composer dump-autoload 经常被忽略却很关键
类找不到、Class not found 报错，很多人先查命名空间、文件路径，其实常是 autoloader 没刷新。Composer 不是实时监听文件增删的，composer dump-autoload 就是手动重建自动加载映射。
- 新增了
psr-4映射目录、改了autoload配置，必须跑一次这个命令 - 开发中频繁加类又不想每次
update，加-o（composer dump-autoload -o）生成优化版（classmap），比默认的 PSR-4 查找快不少 - 如果用了
files类型 autoload（比如全局函数文件），改了那些文件也得重新 dump，否则不会生效
composer global 命令的权限和路径陷阱
composer global require 装的是全局工具（比如 laravel/installer 或 phpstan/phpstan），但它不等于系统级命令——它依赖 Composer 自己管理的 bin 目录是否在 $PATH 里。
- 装完运行报
command not found？先查composer global config bin-dir --absolute，再确认这个路径进了 shell 的$PATH - 多个 PHP 版本共存时，
composer global装的二进制文件绑定的是**当前执行 composer 的 PHP 版本**，换 PHP 后可能无法运行 - 全局装的包升级要小心：
composer global update会更新所有全局包，建议用composer global update vendor/package精确控制
lock 文件不是摆设，global 命令不是免配置银弹，autoload 不是改完代码就自动生效——这些点不踩一遍坑，效率提不起来。
