composer install 默认按 composer.lock 安装；无 lock 文件时，依 composer.json 的语义化版本约束（如 "^2.0"）解析并安装当前最高兼容小版本（如 2.10.2）。^ 允许主版本内任意升级，~ 仅允许修订号升级。
composer install 默认用哪个版本？
默认不锁定具体版本，而是按 composer.json 里写的约束去解析最新兼容版本。比如写 "monolog/monolog": "^2.0"，执行 composer install 时会取当前满足该约束的最高小版本（如 2.10.2），前提是 composer.lock 不存在或已过期。
关键点在于：composer install 优先照着 composer.lock 装；只有首次安装、删了 lock 文件、或运行 composer update 时，才重新解析版本约束。
- 没
composer.lock→ 按composer.json的语义化版本规则找最新匹配版 - 有
composer.lock→ 无视composer.json的约束文字，只装 lock 里记死的版本 -
composer update→ 重新解析所有约束，更新 lock 并装新版本
^ 和 ~ 版本通配符到底差在哪？
这两个符号决定“哪些数字可以动”，直接影响依赖升级范围和破环风险。
^2.3.4 允许升级到 2.x.x 中任意版本（只要不进 3.0.0），即主版本不变，次版本和修订版都可升 —— 这是大多数包的默认推荐写法。
~2.3.4 只允许升到 2.3.x，也就是“固定主+次版本，只放开修订号”—— 更保守，适合对行为敏感的库（比如某些解析器、序列化工具）。
-
^1.2≡>=1.2.0 （等价于 <code>1.2.*） -
~1.2≡>=1.2.0 （等价于 <code>1.2.*，但~1.2.0才等价于1.2.*；~1.2实际被解释为~1.2.0） - 写
^0.3.0很危险：它只锁主版本0，允许升到0.999.999，而 0.x 不保证向后兼容
为什么 composer update 后 vendor 里版本变了，但代码却出错了？
因为 ^ 或 ~ 允许的版本范围内，上游可能引入了非预期的行为变更，哪怕没改主版本号。
常见诱因：
- 某个次要版本偷偷改了函数返回类型（PHP 8+ 类型检查更严）
- 第三方包在
2.8.0加了个新参数，默认值看似安全，但你的调用漏传了，触发了新分支逻辑 - 依赖链中某中间包升级后，把另一个你没直接 require 的包也带升了（例如
symfony/console升级导致symfony/polyfill-mbstring被换掉）
解决思路不是禁用 ^，而是：每次 composer update 后看 composer show -s 输出的变化，重点关注你实际用到的类/方法是否在变更日志里被标记为 “BC break” 或 “deprecated”。
想让所有新 require 都默认加 ^，怎么设？
不能全局设置默认通配符。Composer 没提供这个配置项，composer init 生成的模板虽然用 ^，但只是脚手架行为，不影响后续手动 require。
真正可控的方式只有两个：
- 每次运行
composer require vendor/name时不加版本，让它自动选一个（默认就是^x.y.z） - 显式写全，比如
composer require monolog/monolog:^3.0，避免它猜错（比如你想要^3.0，但它默认给你^2.0）
注意：composer config --global prefer-stable true 只影响“同约束下选稳定版还是 dev 版”，不改变通配符逻辑。
最常被忽略的一点：团队协作时，有人手写 "foo/bar": "2.5.0" 这种固定版本，有人写 "foo/bar": "^2.5"，lock 文件会合并成后者的行为 —— 但下次他本地 update，就可能跳到 2.9.0，而别人没同步测试。版本策略必须写进 README 或 CI 脚本里，不能靠约定。
