最有效的三件事是直接写死关键包版本、禁用自动推导、隔离dev依赖；禁止在composer.json中使用^或~等宽松约束，生产环境require区仅允许显式版本号或带明确上限的范围。
直接写死关键包版本、禁用自动推导、隔离 dev 依赖，是规避 Composer 冲突最有效的三件事。盲目信任 ^ 或 ~ 约束，在中大型项目里等于把版本决策权交给 SAT 求解器——它不理解业务，只穷举，结果往往是凌晨三点还在看 Resolving dependencies。
composer.json 中禁止使用宽松约束
宽松版本号（如 ^2.0、~3.1）在单包开发时方便，但在多团队协作的项目中是冲突温床。Composer 会为每个 ^ 尝试所有兼容子版本，一旦某条路径触发 conflict 或平台限制，整个求解就失败。
- 生产环境
require区域只允许显式版本号或带明确上限的范围，例如"monolog/monolog": "2.9.1"或"guzzlehttp/guzzle": ">=7.4.5 - 绝对不要在
require里写"laravel/framework": "^10.0"—— 它等价于 “允许任意 10.x”，而 Laravel 10.40 可能已悄悄升级了symfony/console要求，间接卡死你的插件 - 如果必须保留弹性，改用
"prefer-stable": true+"minimum-stability": "stable"全局控制，而不是靠^放养
require-dev 必须与 require 逻辑隔离
require-dev 不是“开发才装”，而是“开发时参与依赖解析”。很多循环和隐式冲突都来自它：PHPUnit 加载你 src/，你又继承 PHPUnit 的类，Composer 就认为 phpunit/phpunit 是运行时依赖。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 所有测试、静态分析、CI 工具类包（
phpunit/phpunit、infection/infection、phpstan/phpstan）必须加"--no-dev"标志部署，且不能出现在require中 - 检查每个
require-dev包的autoload和autoload-dev字段，删掉任何含../、../../或指向项目源码的路径 - CI 流水线执行
composer install --no-dev前，先跑composer update --dry-run --no-dev，确认生产依赖图无变更
私有包和镜像源必须显式声明并验证
只要 composer.json 出现 "repositories" 字段（哪怕空数组），全局镜像（如阿里云）就静默失效。这时 Composer 会 fallback 到 packagist.org 回溯旧元数据，导致“明明有 v3.6.0 却装不上”。
- 删除
"repositories": []这类占位空数组；私有源必须带完整配置：{"type": "composer", "url": "https://your-private-repo.com"} - 全局镜像必须用
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/设置，末尾斜杠不能少 - 每次换源后立刻执行
composer clear-cache，再用composer show packagist/support验证source.url是否含镜像域名
真正难处理的从来不是报错信息本身，而是 conflict 字段被当成注释、replace 没覆盖全、或者 autoload-dev 里一个 ../src 让整个依赖图变成有向环——这些地方不打印错误，只让 composer update 卡住不动。动手前先 composer why-not，比删 vendor 有用十倍。
