require-dev 中写 "dev-master" 会导致拉取未测试的最新提交，引发 CI 失败、Class not found 等问题，且因未锁定 commit 而造成环境不一致；正确做法是用 "dev-main#abc1234" 或 "2.5.0@dev" 精确指定。
require-dev 里写 dev-master 会出什么问题
直接在 require-dev 中写 "vendor/package": "dev-master"，看似方便，实则埋雷。它不走语义化版本判断，而是强制拉取 master 分支最新 commit —— 这个 commit 可能是未测试的、破坏 API 的、甚至带语法错误的代码。
常见错误现象包括：
- CI 构建突然失败，报
Class not found或Call to undefined method -
composer install在不同机器上装出完全不同的代码（因为没 lock 住具体 commit） - 某天
dev-master被重置或 force push，本地vendor变成“薛定谔的可用”
正确做法是：用 dev-branchname#commit-hash 锁定具体提交，例如 "vendor/package": "dev-main#abc1234"；或者改用稳定标签 + @dev 后缀，如 "vendor/package": "2.5.0@dev"（前提是该 tag 确实存在且被标记为 dev 稳定性）。
如何让 require-dev 只在本地生效，不进生产环境
require-dev 本就只在 composer install 时、且未加 --no-dev 参数时才安装。但很多人忽略两个关键点：
-
composer.lock文件默认包含require-dev的所有依赖及其子依赖 —— 如果你把它提交了，composer install在生产环境仍会读取并尝试安装（除非显式加--no-dev） - 某些部署脚本漏掉
--no-dev，导致phpunit、phpstan等开发工具被装进生产vendor/，增大攻击面和部署体积
建议操作：
- CI/CD 部署命令必须带
composer install --no-dev --optimize-autoloader - 检查
composer.lock是否真没把 dev 依赖混进生产依赖树（可运行composer show --dev对比） - 若某包仅用于开发且无运行时影响（如
laravel/pint），可考虑移到scripts或单独用composer global require管理，不进项目依赖
^ 和 ~ 在 require-dev 中的行为差异
它们在 require-dev 和 require 中语义完全一致，但风险放大：开发工具升级更频繁，兼容性断裂更隐蔽。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"phpunit/phpunit": "^10.0"允许升到10.99.99，但 PHPUnit 11 不会进来 —— 安全，推荐 -
"phpunit/phpunit": "~10.0"等价于>=10.0.0 ，和上面一样；但写 <code>"~10.0.0"就变成>=10.0.0 ，锁死小版本 —— 过于保守，可能错过安全修复 - 最易踩坑的是
"phpstan/phpstan": "1.10.*"：它等价于~1.10.0，不是^1.10.0，容易误判更新范围
结论：对开发依赖，优先用 ^（兼顾安全与更新），避免 * 和裸 dev-；若需长期锁定，直接写精确版本号，比如 "phpunit/phpunit": "10.5.2"。
为什么 require-dev 里的包有时会“污染” require 的依赖解析
因为 Composer 解析依赖时，不区分 require 和 require-dev 的约束优先级 —— 所有约束统一参与版本求解。如果 require-dev 中某个包依赖 symfony/console:^6.0，而 require 中又用了 symfony/console:5.4.*，Composer 就会报冲突，哪怕你只想在本地跑测试。
典型表现：
-
composer update失败，提示Conclusion: don't install symfony/console v6.0.0 - 想装一个新 dev 工具，结果整个项目主依赖被迫升级
解决思路：
- 先运行
composer why-not symfony/console:5.4.*查清哪个 dev 包在拉高版本 - 对该 dev 包降级（如换用
phpstan/phpstan:1.8.0替代1.10.0） - 或使用
replace声明虚拟包（慎用），告诉 Composer “这个包我已通过其他方式提供”
真正难处理的，是那些既当开发工具、又在运行时被间接加载的包（比如某些 Laravel Dusk 组件）。这种边界模糊的情况，得靠 autoload-dev 配合命名空间隔离，而不是只靠版本约束。
