composer require vendor/package:dev-master@dev 可安装 dev-master 分支，但需显式加 @dev 标签；其本质是动态指针，锁定 commit hash，更新需 composer update；生产环境慎用，存在不可重现与安全风险。
composer require 怎么指定 dev-master 分支
直接写 dev-master 通常会失败，因为 Composer 默认禁止安装不稳定的版本。必须显式声明包的稳定性要求，或在 require 时附带 @dev 标签。
- 正确写法：
composer require vendor/package:dev-master@dev - 如果项目
composer.json中已设"minimum-stability": "dev"，可简写为composer require vendor/package:dev-master -
dev-master不是固定分支名，它只是指向当前仓库默认分支（如 GitHub 的main或master）的别名；若默认分支已改为main，dev-master可能解析失败，此时应改用dev-main@dev
为什么 composer install 有时忽略 dev-master 更新
Composer 锁定的是具体 commit hash，不是分支动态指针。即使远程 dev-master 已更新，只要 composer.lock 里记录的 hash 没变，composer install 就不会拉新代码。
- 想强制同步最新提交：运行
composer update vendor/package（而非install） - 若该包被列为
require-dev，而你执行的是composer install --no-dev，它根本不会被安装 - 检查是否被
platform-config或config.platform干扰了版本解析逻辑
用 repository 自定义 dev-master 源时的常见坑
本地开发调试私有库时，常通过 repositories 添加 path 类型源，但容易因路径、autoload 或分支别名配置不当导致加载失败。
- path 类型仓库必须包含有效的
composer.json，且其中"version"字段不能写dev-master（应留空或删掉），否则 Composer 会拒绝识别为开发版 - 确保路径是绝对路径，或相对于
composer.json的相对路径；错误路径会导致Package not found错误 - 添加后需运行
composer clear-cache，否则旧缓存可能让新配置不生效 - 若目标仓库没有
dev-master分支（比如只有develop），就得用dev-develop@dev，并确认composer.json中"branch-alias"是否设置了映射
dev-master 在生产环境的风险提示
它本质上没有语义化版本约束，每次更新都可能是破坏性变更，连函数签名或配置格式都可能突然改掉。
- CI/CD 流水线中若用了
dev-master，构建结果不可重现——今天成功，明天可能因上游一次提交就失败 -
composer outdated不会提醒dev-master有更新，因为它不参与版本比较 - 审计工具（如
roave/security-advisories）通常跳过@dev包，安全漏洞可能长期被忽略
真正需要跟踪最新代码时，优先考虑 fork 后锁定具体 commit（如 dev-main#abc1234），而不是无条件依赖 dev-master。
