只有明确要升级依赖时才执行composer update，且须在git status确认工作区干净后操作；ci/cd、线上部署及日常安装一律用composer install以保障环境一致。
谁该执行 composer update，什么时候执行
只有明确要升级依赖时才运行 composer update，且必须在 git status 确认工作区干净后操作。CI/CD 流水线、线上部署、日常开发安装一律用 composer install —— 它读 composer.lock，不碰版本解析逻辑，是唯一能保障环境一致的命令。
常见错误现象：本地改了 composer.json 后顺手 composer update，结果 CI 报错 Class not found；或者某人 composer update 后没提交 composer.lock，别人 composer install 装出旧版依赖，行为不一致。
- 团队中应指定专人或固定周期（如每月第一个周五）统一执行
composer update，并提交新composer.lock - 临时试某个包的新版本？用
composer update vendor/package-name精确更新，避免连带升级其他包 - CI 脚本第一行加
ls -la composer.lock，防止缓存导致误用旧 lock 文件
composer.json 里怎么写版本号才不容易翻车
项目（application）和库（library）的写法完全不同：项目必须锁死关键依赖的主版本，库则要放宽范围。比如你写的是电商网站，"monolog/monolog": "^2.10" 是合理选择；但如果你开发的是一个可被他人复用的 SDK，就得写成 "monolog/monolog": "^2.0 || ^3.0"，否则下游项目一集成就冲突。
浮动版本（如 "^2.0"）本身不是问题，问题是它隐含了对 SemVer 的信任。而现实中很多包不严格遵循 SemVer，次版本升级也可能引入 BC break。所以对核心框架（Laravel、Symfony）、关键工具（Doctrine DBAL、Guzzle）建议显式锁定到小版本，例如 "laravel/framework": "10.48.12"。
- 别用
*、dev-main或分支名写进require，生产环境禁止 VCS 源 -
require-dev里放phpunit/phpunit、roave/security-advisories没问题，但绝不能放运行时必需的doctrine/migrations - 所有
config.platform配置（如"php": "8.2.10"）必须和composer.lock里的platform字段完全一致，否则解析结果可能偏差
为什么 composer.lock 一冲突就容易搞崩环境
因为 composer.lock 不是“记录结果”的日志文件，而是“决定行为”的契约文件。Git 合并冲突时手动删掉
典型错误操作：合并时选了 theirs 的 composer.lock，但 composer.json 里已有对方没写的包，结果 composer install 报错 “Required package is not present in the lock file”。
- 正确做法：先手动合并
composer.json，确保所有新增/删除的依赖都体现在最终版本里 - 然后删掉本地
composer.lock和vendor/目录 - 再跑一次
composer update，让 Composer 重新计算完整依赖树并生成新 lock - 最后提交新的
composer.lock，不要跳过这步
镜像源和缓存怎么配才不干扰依赖解析
镜像源配错不会报错，只会让 Composer 在后台疯狂回溯 packagist.org 的旧索引，卡在 Resolving dependencies 半小时不动。根本原因不是网络慢，是元数据源没对齐。
验证是否生效最简单的方法：运行 composer config -g repo.packagist，输出必须是完整 URL 字符串，比如 https://mirrors.aliyun.com/composer/；如果为空或格式不对，全局镜像就失效了。
- 换镜像后必做
composer clear-cache，否则 Composer 仍用旧缓存里的 provider 地址请求 - 项目级
repositories字段（哪怕只写"repositories": []）会直接屏蔽全局镜像配置，慎用 - 私有包源必须显式声明
"type": "composer"，漏写会导致 fallback 到 VCS 模式，绕过镜像代理
composer update 当成 npm install 那样随手就敲，或者觉得 composer.lock 就是个中间产物可以忽略。这些习惯一旦形成，lock 文件就不再是保障，反而成了定时炸弹。
