已发布的composer包版本不可变，修正php兼容性等约束必须发布新版本；git标签须为轻量标签且命名规范，packagist仅识别如v1.2.3格式的标签，注解标签或含非法字符的标签将导致同步失败。
已发布的 Composer 包版本不可修改，任何“打补丁式”修正（比如给旧 Tag 补 PHP 版本上限）都必须通过发布新版本实现。
Git Tag 必须是轻量 Tag 且推送到远程
Composer 和 Packagist 只识别 git tag v1.2.3 这类轻量 Tag；git tag -a v1.2.3（带注解的 Tag）在旧版 Packagist 上可能因空 message 解析失败，导致同步中断。常见卡点：
- 只本地执行了
git tag，没运行git push origin v1.2.3 - Tag 名含非法字符：如
v1.2.3+build.1、v1.2.3-beta.1—— Packagist 会跳过 - Packagist 仓库设置里未勾选 “Automatically update the package on new commits?”
-
composer.json里手动写了"version": "1.2.4"，和 Tag 名不一致，同步被拒
^ 和 ~ 的锚定逻辑不是“松紧”，而是坐标系不同
很多人以为 ^ 是宽松、~ 是保守，其实它们根本不在同一维度上对齐：
-
^1.2.3锚定主版本号1，等价于>=1.2.3 -
~1.2.3锚定最左侧非零段1.2，等价于>=1.2.3 -
^0.5.1是特例：0.x 阶段不承诺兼容性，所以它只允许>=0.5.1 ，哪怕只是加个 public 方法也合法 -
~0.0.4锚在第三位，只允许升到0.0.9，不会到0.1.0
已发布版本的 PHP 兼容性无法事后追加
一旦 v1.0.0 被 Packagist 抓取，它的 composer.json 就固化为该版本元数据——包括 "php": ">=7.0" 这种宽泛声明。你不能删 Tag、改历史、重推同名标签，否则：
- 下游用户
composer update可能因哈希不匹配失败 - CI 构建突然中断，没人知道是哪次推送动了历史
- Packagist 缓存不会自动刷新，手动删包重提风险极高
唯一干净做法：发一个新 patch 版本，比如 v1.0.1，并在其 composer.json 中收紧为 "php": ">=7.0 。
composer.lock 永远压倒 composer.json 的版本约束
你把 "monolog/monolog": "^2.0" 改成 "^3.0"，composer install 依然装 2.10.0——因为 composer.lock 里还记着它。生效只有两条路：
- 运行
composer update monolog/monolog：只更新该包及其子依赖，不动其他 - 先
composer update --dry-run看影响范围，确认无误再执行composer update
直接删 composer.lock 再 install，等于放弃版本确定性，在团队协作中是危险操作。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
