结论：生产环境禁用 和 dev-master，优先用 ^ 或 ~，必须提交 composer.lock； 会导致大版本不兼容升级，dev-master 每次更新都不可控，^1.2.3 允许 minor/patch 升级，~1.2.3 仅允许 patch 升级，精确版本仅临时使用，composer.lock 才真正锁定依赖版本。
直接说结论：别用 *，优先用 ^ 或 ~，生产环境必须提交 composer.lock。
为什么 * 和 dev-master 在生产环境是危险操作
写 "overtrue/wechat": "*" 看似省事，但 Composer 会按 minimum-stability（默认 stable）装最新稳定版——可能跳到 2.0.0，而这个大版本很可能破坏你的调用方式。同理，"dev-master" 每次 composer update 都拉最新提交，API 变更、文档没跟上、甚至 CI 都过不了。
- 现象：本地跑通，上线后报
Class not found或Call to undefined method - 根本原因：语义化版本中主版本号（
MAJOR）变更 = 不兼容 API 修改 - 真实风险：你没改一行代码，
composer update后整个支付模块就挂了
^ 和 ~ 的区别必须分清
这两个符号都限制“哪些位能变”，但规则不同，选错会导致意外升级或锁死太死。
-
^1.2.3≡>=1.2.3 ：允许次版本（<code>MINOR）和修订版（PATCH）升级，推荐新项目默认用它 -
~1.2.3≡>=1.2.3 ：只允许修订版升级，适合对稳定性极度敏感的场景（比如金融类 SDK） -
~1.2≡>=1.2.0 ：等价于 <code>^1.2，但写法容易误解，建议统一用^ - 错误写法：
^1.2.*—— Composer 会报错，*不能和^混用
什么时候该用精确版本（如 "1.2.3"）
不是“越精确越安全”，而是为解决具体问题临时锁定。
- 当你确认某个版本有关键 bug，而下一版还没发布修复时，可锁死到已知可用版本
- 团队协作中，某成员本地因缓存装了
1.2.5，但其他人装的是1.2.4导致行为不一致，临时锁死可快速对齐 - 注意：
"1.2.3"会阻止所有自动更新，包括安全补丁；除非必要，不要长期使用 - 替代方案：用
^1.2.3+composer update vendor/package单独升级，比全局锁更可控
composer.lock 不提交 = 没设约束
很多人写了 ^2.0 就以为万事大吉，结果上线发现依赖版本和本地不一致——因为没提交 composer.lock。
-
composer install优先读composer.lock，忽略composer.json中的约束范围 - 如果
composer.lock没进 Git，CI/CD 流水线执行install时，会按当前 Packagist 上的最新匹配版本安装（可能已是2.9.0） - Composer 2.5+ 更严格：若
lock文件缺失某个require包，install直接失败，倒逼你养成提交习惯
最常被忽略的一点：约束只是“允许装哪些版本”，真正决定装哪个版本的，是 composer.lock 里记录的那一行 SHA-256 哈希值。
