部署上线必须用 composer install，本地开发升级依赖才用 composer update；前者按 lock 文件安装精确版本，后者重解析 json 并更新 lock，易引入不兼容变更。
composer install 和 update 到底该用哪个？
部署上线必须用 composer install，本地开发想升级依赖才用 composer update。前者只读 composer.lock，装的是锁定的精确版本；后者重新解析 composer.json，可能拉来不兼容的新版，还重写锁文件。
- 首次运行
composer install时若无composer.lock，它会自动执行一次update并生成锁文件——这看似省事，实则绕过团队共识，建议先git commit空的composer.lock或由负责人统一生成 - 线上 CI/CD 脚本里一旦出现
composer update，就等于把版本控制权交给了网络和时间，极大概率引发凌晨告警 - 只想升某一个包？用
composer update monolog/monolog，别裸跑update，否则子依赖可能卡在旧版引发冲突
加依赖别手写 composer.json，用 require 就对了
composer require 不是“下载包”的快捷方式，而是“声明+安装+锁定”三步合一的操作。它会自动写进 require 或 require-dev 字段、执行安装、更新 composer.lock。
- 开发依赖（如 PHPUnit）必须加
--dev：composer require phpunit/phpunit --dev，否则上线环境可能误装调试工具 - 指定版本别只写
7.5，得带约束符：composer require guzzlehttp/guzzle:^7.5（推荐）或~7.5.0；写成7.5会被解释为严格等于7.5.0，几乎匹配不到 - 如果只想加包但不动其他依赖，加
--no-update：composer require symfony/console --no-update，再手动composer update symfony/console
初始化项目别 Ctrl+C 中断 init，小心半截 composer.json
composer init 是交互式生成合法 composer.json 的唯一安全方式，能避开引号漏写、逗号多写、JSON 格式错误等低级坑。但它不会覆盖已有文件——中途 Ctrl+C 可能留下不完整 JSON，导致后续命令报错。
- 运行前先确认：
ls -la composer.json，有就删掉再 init，或直接用参数跳过交互：composer init --name=myorg/myapp --description="My API" - PHP 版本约束写
php: ^8.1比php: >=8.1更安全，Composer 会据此校验环境并阻止安装失败 - 如果项目要支持多个 PHP 大版本，别写死
^8.1，改用^8.1 || ^8.2或更宽泛的约束，避免 CI 因 PHP 小版本差异失败
换源、查配置、修 autoload，这些 config 命令真香
国内用 Composer，不配镜像源就是自找慢。而 composer config 不只是换源，还能控制插件启用、类加载优化、私有仓库认证等关键行为。
- 切阿里源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（-g表示全局，不用每个项目重复设） - 查看当前所有生效配置：
composer config --list；查某一项，比如 autoload 后缀：composer config autoloader-suffix - 启用权威类映射提升性能：
composer config classmap-authoritative true，但前提是确保所有类都已纳入classmap或psr-4，否则会找不到类 - 调试时想看 autoload 是否生效？改完
composer.json的autoload段后，务必运行composer dumpautoload，否则新增的命名空间不会被识别
实际项目里最常被忽略的，是 composer.lock 文件不该被 .gitignore 掉，也不该靠人肉维护——它就是你依赖关系的“合同”。一旦有人绕过它直接改 composer.json 又不跑 update，整个团队的 vendor 就不再一致。
