应使用 ^ 约束符（如 "^1.2.3"），它允许升级 minor 和 patch 版本但禁止 major 升级；避免使用 * 或 dev-main 等宽松约束；配合 --dry-run 预览、按包更新及 composer outdated 定期检查可进一步保障版本稳定。
默认情况下，Composer 会根据你定义的版本约束（如 ^1.2.3 或 ~1.2）决定是否允许更新到新版本。若想在 composer update 时**只升级小版本（minor）和补丁版本（patch），不升级主版本（major）**，关键在于正确使用版本约束符，并配合合适的命令选项。
使用 ^（caret）约束符
^ 是最常用且推荐的方式，它允许 minor 和 patch 升级，但禁止 breaking change 的 major 升级（前提是遵循语义化版本规范）。
-
^1.2.3→ 允许升级到1.x.x中任意高于或等于1.2.3的版本，如1.2.4、1.3.0、1.9.9，但不会到2.0.0 -
^1.2等价于^1.2.0，效果同上 -
^0.1.2在0.x范围内行为略有不同（只允许 patch 升级），需注意早期版本的特殊规则
避免使用宽松约束（如 *、dev-main 或无约束）
这些写法会让 Composer 拉取最新可用版本，可能跳过 major 版本边界。
- ❌
"monolog/monolog": "*"—— 可能升级到3.0.0 - ❌
"monolog/monolog": "dev-main"—— 总是拉取最新开发分支，完全不受控 - ✅ 改为
"monolog/monolog": "^2.8"或更精确的"^2.8.0"
用 composer update 时限制范围（可选补充）
即使约束符已设好，执行 composer update 默认仍会尝试满足所有约束并升级到最新兼容版本。若想进一步确保不意外触发 major 升级（比如因依赖树中其他包间接要求），可：
- 运行
composer update --dry-run预览将发生的变更，检查是否有 major 版本被纳入 - 对特定包显式更新，如
composer update monolog/monolog --with-dependencies，避免全量更新带来的不确定性 - 保持
composer.json中的约束始终使用^，这是最根本的防线
检查并锁定当前主版本（预防性操作）
如果项目已稳定在某主版本（如 1.x），可在 composer.json 中显式固定主版本号，增强可读性和防护：
- 写成
"symfony/console": "^1.0 || ^2.0"显式允许多个主版本（不推荐，增加复杂度） - 更稳妥的是只写
"symfony/console": "^1.10"，让 Composer 自动守住1.x边界 - 定期运行
composer outdated查看哪些包有新 minor/patch 可升，主动管理而非被动等待
基本上就这些。核心就是：用 ^ 写约束，别偷懒用 *，再加点预览和检查习惯，就能稳稳守住主版本线。
