composer.json 的 version 字段基本没用——Composer 安装时认 Git tag（如 v1.3.0），而非该字段；仅在私有仓库、path repository 别名（如 "dev-main as 1.3.0"）或 CI/CD 解析时起辅助作用。
composer.json 里 version 字段到底有没有用？
基本没用——除非你手动发布到 Packagist 或私有仓库时强制指定，否则 Composer 完全忽略它。本地开发改 version 不影响安装行为，也不参与版本解析。真正起作用的是 Git tag（如 v1.2.0）或仓库中 composer.json 的实际位置（如 dev-main 分支）。很多人改了 version 发现 composer update 没反应，就是卡在这儿。
想让别人装到指定版本，得靠 Git tag + packagist 同步
Composer 安装时认的是「源代码的 Git 标签」，不是 composer.json 里的 version。所以正确流程是：
- 先在项目根目录 commit 干净后，打带前缀的 tag：
git tag v1.3.0 - 推送到远程：
git push origin v1.3.0 - 如果包已注册到 Packagist，勾选「auto-update」就能自动同步 tag；没注册就手动 trigger sync 或提交新版本
- 下游用户才能用
"vendor/name": "^1.3"正常安装
注意：tag 名必须符合语义化版本格式（vX.Y.Z 或 X.Y.Z），否则 Packagist 可能识别失败，composer require 会报 Could not find package。
本地测试时怎么绕过 tag 强制指定版本？
开发阶段不想每次打 tag，又想让 composer require 装自己改的代码，有两个靠谱办法：
- 用
pathrepository：在根composer.json加"repositories"，指向本地路径，然后 require 时用"dev-main"这类分支名 - 临时改
require的版本约束为"dev-main as 1.3.0"—— 这样 Composer 会把dev-main当作1.3.0解析，但前提是你的composer.json里version字段也得写成"1.3.0"（仅限这种 alias 场景下才需要对齐） - 别碰
minimum-stability和prefer-stable，它们会影响dev-前缀包的默认行为
修改 version 字段最容易踩的三个坑
虽然它多数时候被忽略，但改错仍会导致奇怪问题：
- 在私有 Satis/SatisPress 仓库里，
version是生成 metadata 的依据，填错会导致下游 resolve 失败，报Could not parse version constraint - 某些 CI/CD 流程（比如自动生成 CHANGELOG）会读取
version，和 Git tag 不一致时，版本号和实际代码对不上 - 如果误把
version写成dev-master这类非标准值，在 Packagist 上可能触发警告甚至拒绝同步
真正要改的永远是 Git tag，composer.json 里的 version 只是辅助记录或适配特定分发场景，别把它当版本控制的源头。
