Composer 的 dev-master 不实时更新因缓存 commit hash，需 clear-cache 或指定 commit；minimum-stability 应按包设 --stability-dev；v2.5.x-dev 等别名由作者定义；lock 文件存 hash 而非分支名；CI 中推荐写死 commit hash。
require dev-master 时为什么总是拉不到最新提交
Composer 默认会缓存 dev-master 的 commit hash，不是实时追踪远程分支头。哪怕你 git push 了新提交，composer update 仍可能复用旧的锁定版本。
- 先运行
composer clear-cache清掉本地包元数据缓存 - 再加
--with-dependencies确保依赖树里所有dev-*分支都刷新 - 更可靠的做法是显式指定 commit：比如
composer require vendor/name:dev-main#abc1234，其中abc1234是目标提交的短哈希
用 stability flags 控制测试包可见性
Composer 默认只允许安装 stable 版本。要装 dev-、alpha、beta 或 rc 包，必须显式放宽稳定度策略。
- 项目级设置：在
composer.json根对象中加"minimum-stability": "dev"（或"beta"等） - 但注意：这会影响所有依赖，不推荐全局放开；更安全的是按包指定：
composer require vendor/name:dev-main --stability-dev -
--stability-dev等价于临时设minimum-stability=dev，且只对本次命令生效
如何精确 require 某个发布周期的测试版本（如 v2.5.x-dev）
很多开源库用 vX.Y.x-dev 命名开发分支（如 v2.5.x-dev），它不是 Git 分支名，而是 Composer 的“虚拟分支别名”，需对应真实分支或 tag。
- 先确认包仓库里是否存在该别名指向的源：查
composer show vendor/name -a，看输出中是否有v2.5.x-dev - 如果存在，直接
composer require vendor/name:v2.5.x-dev即可 - 如果不存在，说明作者没配置
branch-alias，此时只能退回到真实分支名（如2.5或release/2.5）或 commit - 别名映射由包作者在
composer.json的extra.branch-alias字段定义，你无法在 require 时覆盖
require 测试包后 lock 文件里为什么还是 stable 版本号
这是 Composer 的正常行为：composer.lock 记录的是解析后的具体 commit hash 和完整版本标识（如 "version": "dev-main#9f8e7d6c"），而不是你输入的 dev-main。
- 不要手动改
composer.lock里的 version 字段——下次composer install会覆盖 - 想切回某个特定测试版？用
composer require vendor/name:dev-main#commit-hash，然后composer update vendor/name - CI 环境中若需固定测试包版本，建议在
composer.json中写死 commit hash 形式，避免因远程分支移动导致构建结果漂移
实际操作中最容易忽略的是：你以为 dev-main 就是“最新”，但它背后可能被缓存、被分支重命名、被作者 alias 覆盖，甚至已被 force-push 覆盖掉。真要稳，就认 commit hash。
