Composer支持用“dev-分支名#完整40位commit哈希”锁定精确提交，如"dev-main#abc123…"，#是唯一官方隐式承认的commit锁定方式，@会导致解析失败。
用 composer.json 的 dev-* 分支 + commit 作为版本号
Composer 不支持直接写 sha1 当作版本号（比如 "vendor/package": "abc1234" 会报错“invalid version”），但可以绕过校验：把 commit 哈希拼进分支名，再用 dev- 前缀声明为开发版。Composer 会把它当作一个合法的“分支别名”来解析。
- 在
composer.json中写成："vendor/package": "dev-main#abc1234567890abcdef1234567890abcdef123456"（注意是#，不是@） -
main是原始分支名（也可以是develop、master等），abc123...是完整 40 位 commit hash - 执行
composer install或composer update vendor/package后，Composer 会精确检出该 commit，且不随远程分支更新而漂移 - 这个写法依赖 Packagist 或私有仓库的 VCS 驱动识别能力，GitHub/GitLab 原生支持；自建 Satis 需确认启用了
vcs类型源
为什么不能用 @ 符号或 dev-branch@commit？
因为 @ 在 Composer 版本约束中只用于分隔包名和版本（如 foo/bar@dev-master），不是语法的一部分；而 dev-branch@abc123 会被解析成“分支名是 dev-branch@abc123”，根本不存在这个分支，导致 clone 失败或回退到 latest commit。
- 常见错误现象：
Failed to download vendor/package: No valid composer.json was found...或静默检出错误 commit - Git URL 方式（
"dist": {"url": "...", "shasum": "..."}）虽能锁定，但需手动维护 dist 包，不适合日常开发流 - 使用
#是唯一被 Composer 官方文档隐式承认的 commit 锁定方式，见 version schema docs 中 “Branch alias” 和 “VCS repositories” 交叉说明
锁定后如何验证实际检出的确实是目标 commit？
光看 composer.lock 里的 source 字段不够——它只记录当时解析出的 commit，不保证后续 composer install 时仍有效（尤其当远程仓库被 force-push 覆盖该 commit 时）。
- 检查已安装包的 Git HEAD：
cd vendor/vendor/package && git rev-parse HEAD - 对比
composer.lock中对应条目的source.reference值是否一致 - CI 中建议加一道校验脚本：
composer show -s vendor/package | grep -q "abc1234567890...$" - 注意：如果项目启用了
composer config --global store-auths false或私有 Git 仓库未配置凭证，git rev-parse可能失败，得先确保 vendor 目录下是真实 Git 工作区（非 zip dist）
极端安全场景下还要防什么？
即使锁定了 commit，仍有两个隐蔽风险点：一是 Git submodules 未同步，二是依赖的依赖（transitive deps）没被同样锁定。
- 子模块需额外运行
git submodule update --init --recursive，否则可能漏掉关键补丁 - 所有间接依赖也应显式写入
composer.json并用相同dev-branch#hash格式锁定，否则composer update可能升级它们 - 私有仓库若用 GitHub Enterprise / GitLab CE，要确认其 API 返回的 commit 时间戳和树结构未被篡改（即启用 signed commits + verify signature）
- 真正极致安全的团队，会把
composer.lock+ 所有 vendor 子目录的git rev-parse HEAD结果一起签名校验并存档
