Composer本身不是构建工具，其冲突本质是误将它当作执行器，实际冲突源于混用的脚本、插件或CI环境；它仅负责依赖解析、下载与autoloader生成。
直接说结论：Composer 本身不是构建工具，所谓“开发工具链冲突”本质是误把 Composer 当成 gulp/webpack/make 那类执行器，它只管依赖下载、版本解析和 autoloader 生成——冲突从来不在 Composer，而在你混用的脚本、插件或 CI 环境里。
composer.json 里写 scripts 不等于构建流程
很多人在 scripts 字段塞一堆 "build": "npm run build && php build.php"，以为这就是“构建工具链”。但 Composer 的 scripts 只是钩子（hook），不提供并发控制、缓存、依赖图拓扑排序。一旦脚本里调用了 Node.js 工具、PHP 编译器或自定义 CLI，版本兼容性就脱离 Composer 管控。
- 常见错误现象：
composer install后vendor/bin/php-cs-fixer报错 “Class not found”，其实是php-cs-fixer依赖的symfony/console版本和项目里其他包冲突，而 Composer 并不校验 CLI 工具的运行时依赖 - 真实场景：你在
scripts里调用phpstan，但它要求 PHP 8.2+，而项目platform锁的是"php": "8.1"—— Composer 不拦，PHPStan 运行时报错 - 参数差异：
composer run-script默认不继承环境变量；composer run-script --no-ansi --no-interaction才适合 CI，否则可能卡在交互提示上
plugin 和 script 混用导致 hook 执行顺序失控
Composer Plugin（如 kylekatarnls/update-helper）监听的是生命周期事件（如 post-autoload-dump），而 scripts 是按字符串顺序执行的。两者没约定先后，容易出现“autoloader 已生成，但 plugin 还没写完 migration 提示”的竞态。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 容易踩的坑：
composer update触发了post-update-cmd脚本，同时update-helper插件也在监听post-autoload-dump—— 如果脚本里删了vendor/或重写了autoload.php，插件拿到的就是脏状态 - 性能影响：每个 plugin 都会实例化自己的
Package解析器；加了 3 个 plugin，composer install时间可能多出 40%（尤其在低配 CI runner 上） - 兼容性注意：
composer-plugin-api版本必须匹配 Composer 主版本（v2.7.x 要求"composer-plugin-api": "^2.3"），否则 plugin 直接被跳过，连 warning 都不报
CI/CD 中 vendor/bin 下二进制文件的版本来源不透明
vendor/bin 里的可执行文件（如 phpunit、phpstan、doctrine）看似“属于项目”，实则由各自包的 bin 字段声明，Composer 只做软链。它们的版本行为完全独立于 composer.lock 中记录的 SHA。
- 典型问题：
composer.lock显示"phpunit/phpunit": "9.6.15"，但vendor/bin/phpunit --version输出10.5.2—— 因为项目根目录下存在全局安装的phpunit，Composer 软链优先指向了它 - 验证方法：运行
ls -l vendor/bin/phpunit，看是否指向../phpunit/phpunit/phpunit；如果不是，说明被外部覆盖 - 安全做法：CI 中统一用
./vendor/bin/phpunit（带./前缀），禁用$PATH中的全局 bin；本地开发可用 alias，但别写进scripts
最常被忽略的一点：Composer 不解析 require-dev 里工具的子依赖兼容性。比如你 require-dev 了 "phpunit/phpunit": "^9.6" 和 "nunomaduro/larastan": "^2.0"，它们都依赖 phpstan/phpstan，但一个要 ^1.10，一个要 ^2.0 —— Composer 会选一个满足两者的版本（如果存在），但不会告诉你 larastan 在该版本下实际功能受限。这种隐性降级，只能靠 composer show --tree 手动翻。
