dev-master不能作为版本使用，它只是浮动指针，真正锁定需用dev-branch#full-hash格式（如dev-main#abc123...），分支名须与远端完全一致（大小写、斜杠敏感），私有库须配vcs repositories，require时须加--stability=dev或@dev，且需验证composer.lock的source.reference与vendor下git rev-parse head一致。
dev-master 不能当版本用，它只是个浮动指针
写 "vendor/pkg": "dev-master" 看似装了 master 分支，实际只是告诉 Composer 去拉当时 HEAD 的提交；下次 composer update 可能拉到新 commit，force push 后旧 hash 在 composer.lock 里直接失效。这不是锁定，是裸奔。
- 远端分支被删、重命名或 force push，
composer install就会卡在Could not find package -
composer.lock里source.reference字段若显示"main"或"HEAD"，说明根本没锁住 commit - CI 构建结果不一致，往往就因为本地和线上拉到了不同 commit
真正锁定 commit 只有一种写法：dev-branch#full-hash
必须用 dev-main#abc1234567890abcdef1234567890abcdef123456 这种格式——# 是唯一被 Composer VCS 驱动识别的 commit 锚点，@ 会被当成分支名解析，短哈希（如 abc123）可能不唯一，40 位完整小写哈希才可靠。
- 分支名必须和远端完全一致：
dev-Main≠dev-main，dev-feature/login不能写成dev-feature-login - 私有仓库必须提前在
composer.json的repositories里声明"type": "vcs"和带.git后缀的 URL - 执行
composer update vendor/pkg前，建议先删掉vendor/vendor/pkg和composer.lock中对应段落，避免缓存干扰
命令行安装 dev 分支必须显式放宽稳定性
composer require vendor/pkg:dev-main 默认失败，因为 minimum-stability 默认是 stable，而所有 dev- 开头的引用都属于不稳定版本，不加参数就进不了版本解析阶段。
- 临时安装推荐：
composer require vendor/pkg:dev-main --stability=dev（不改全局配置） - 单包放宽更安全：
composer require vendor/pkg:dev-main@dev（@dev只对该包生效） - 别永久设
"minimum-stability": "dev"——这会让所有依赖都可能降级到任意dev-版本，失控风险极高
验证是否真锁住了，不能只看 composer.lock
composer.lock 的 source.reference 只记录当时解析出的哈希，防不住远程 force push 覆盖。必须检查已安装包的真实 Git HEAD。
- 运行：
cd vendor/vendor/pkg && git rev-parse HEAD，输出必须和composer.lock里对应字段完全一致 - CI 中可加校验脚本：
composer show -s vendor/pkg | grep -q "abc1234567890$" - 如果
vendor/下是 zip 解压而非真实 Git 工作区（比如用了--prefer-dist），git rev-parse会失败——得确保加了--prefer-source参数
dev-main#...，而是每次更新都重新核对哈希来源、每次 CI 都跑一次 git rev-parse、每次引入新包都人工确认其签名状态——这些动作没法自动化到 100%，但漏掉一次就可能让整条信任链失效。
