composer.json 的 version 字段应使用版本约束而非固定版本；推荐用 ^ 表示兼容性升级（如 "^7.5" 允许 7.5.0–7.x.y），慎用 ~（如 "~2.8" 等价于 ">=2.8.0"）。
composer.json 里 version 字段不是你想填啥就填啥
PHP 项目依赖版本不是靠手动写死 "monolog/monolog": "2.10.0" 来管的，composer.json 中的版本约束本质是“允许安装的范围”，不是“必须锁定的精确版本”。直接填具体数字容易导致协作时本地装的不是同一版，CI 构建失败，甚至线上行为不一致。
实操建议：
- 用
^（推荐）：比如"guzzlehttp/guzzle": "^7.5"表示允许安装7.5.0到7.x.y的最新兼容版（即不跨主版本），这是最常用也最安全的写法 - 用
~要小心：比如"~2.8"等价于>=2.8.0 ，但对三位版本理解易错，不建议新手用 - 绝对锁定只在必要时：比如发现某 patch 版本有严重 bug，才临时写成
"doctrine/dbal": "3.7.2"，之后记得及时放开 - 别信
dev-master：它会随上游变动，CI 构建可能今天通、明天挂，生产环境禁止出现
运行 composer update 前必须先确认 composer.lock 是否提交
composer.lock 是真实生效的依赖快照。没有它，composer install 就退化成 update，每次拉代码都可能装出不同版本——这正是线上环境出问题的高频原因。
常见错误现象：
立即学习“PHP免费学习笔记（深入）”；
- 本地
composer install装出的symfony/http-foundation是6.4.3，同事拉完代码跑出来却是6.4.5→ 锁文件没提交或被 .gitignore 忽略了 - CI 报错
Class not found，但本地正常 → CI 执行的是install，而你本地其实一直靠update维持着最新依赖，锁文件早已过期
实操建议：
- 确保
composer.lock在 Git 仓库中且未被忽略（检查 .gitignore 里有没有composer.lock） - 更新依赖时，先改
composer.json，再运行composer update vendor/package-name（指定包），而不是无脑composer update - 提交时，
composer.json和composer.lock必须一起 commit，缺一不可
composer outdated 显示的“可升级”不等于“应该升级”
这个命令列出所有有新版的包，但 PHP 生态里，小版本升级也可能破坏行为（比如 Laravel 10 升级后 Request::ip() 返回值逻辑变化），盲目跟新等于埋雷。
使用场景：
- 安全审计：配合
composer audit（Composer 2.5+）查已知漏洞，优先处理标CRITICAL的包 - 大版本迁移准备：比如计划升 Symfony 6 → 7，先用
composer outdated --major-only看哪些包卡在 v6 - 日常维护：每月跑一次
composer outdated --direct，只看根依赖（你直接 require 的），跳过层层传递的子依赖
性能与兼容性影响：
- 升级
phpunit/phpunit可能要求更高 PHP 版本，CI 的 PHP 镜像得同步调 - 升级
laravel/framework后，若第三方包还没适配，composer update会直接失败，报your requirements could not be resolved
多环境依赖差异只能靠 require-dev 和平台配置，别动 autoload
开发机装 xdebug、测试跑 phpunit、线上禁用调试工具——这些不能靠注释掉 require 或手动删包解决，否则 composer install --no-dev 就失效了。
实操建议：
- 把
phpunit/phpunit、mockery/mockery这类只在开发/测试用的包，全部塞进require-dev，别混在require里 - 线上部署时明确加参数：
composer install --no-dev --optimize-autoloader，前者剔除 dev 包，后者生成静态映射提升性能 - 如果某些包在不同 PHP 版本下行为不同（比如
ext-redis5.x vs 6.x），用config.platform锁定模拟环境："config": { "platform": { "php": "8.1.20", "ext-redis": "5.3.7" } }，避免本地 PHP 版本高，CI 低，导致依赖解析结果不一致
最容易被忽略的是 platform 配置——它不改变你本地扩展，只告诉 Composer “当我在目标环境运行时，这些扩展是存在的”，这才是跨环境依赖稳定的底层逻辑。
