本地包的conflict字段会全局生效，因其被composer视为已发布包并参与整棵树sat求解；vcs仓库因惰性解析不立即触发校验，而path类型则同步加载其composer.json全部约束。
本地包的conflict字段会全局生效，不是只拦你自己
你把一个本地包通过path仓库引入后，Composer 不是“读取它的代码”，而是把它当做一个已发布的包，完整加载其composer.json里的所有约束。这意味着它的"conflict"、"require": {"php": "..."}、"minimum-stability"都会参与整个项目的 SAT 求解——哪怕你项目里根本没装它声明冲突的那个包，只要其他依赖（比如某个 SDK 或 require-dev 里的测试工具）间接拉进了那个版本，就会直接失败。
常见错误现象：
- 报错
Conclusion: don't install laravel/framework v11.0.0，但你的主项目只用了 L10 -
composer why-not laravel/framework:v11.0.0查不到路径，因为该包还没成功解析进composer.lock - 删了
vendor和composer.lock重装，依然卡在同一个 backtracking 步骤
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确认路径是否被识别：
composer config repositories看输出里有没有你的path条目 - 确保主项目
composer.json的require键名（如"acme/utils"）和本地包composer.json里的"name"完全一致（包括 vendor 前缀） - 临时删掉
composer.lock，运行composer update --dry-run -v，盯住日志里有没有Loading package acme/utils from path repository—— 没这句说明路径压根没加载
用 --dry-run -v 观察回溯点，比看报错更准
Composer 报错末尾的 Conclusion 只是最终失败状态，不是原因。真正关键的是它在 Resolving dependencies 阶段的回溯行为。加 -v 后你会看到类似这样的日志：
Trying acme/utils dev-main Skipped acme/utils dev-main, because it conflicts with laravel/framework (>=11.0)
这说明它尝试加载你的本地包时，立刻被它自己 composer.json 里的 conflict 拦住了——而不是你的项目或别的包在拦。
实操建议：
- 别等报错才加
-v，从第一次引入本地包就用composer update --dry-run -v - 重点关注
Trying和紧随其后的Skipped或because行，那是真实触发点 - 如果看到
Backtracking多次出现在同一包上，基本可以确定是它自己的约束太硬
改本地包的 composer.json，不是改命令参数
没有命令行参数能“绕过”本地包的 conflict 或 php 要求。你想让它不拦，就得改它自己的 composer.json。这不是妥协，是明确表达意图：这个包当前就是用来和 L10/L9/PHP 8.1 一起跑的。
实操建议：
- 删掉不必要的
"conflict"，特别是写死大版本号的（如"laravel/framework": ">=11.0"）——除非你真要禁止它被用在 L11 上 - 把
"require": {"php": "^8.2"}改成实际开发环境的版本，比如"^8.1"或"^8.0 || ^8.1 || ^8.2" - 如果只是临时调试，可暂时删掉
"minimum-stability": "dev"，避免它把整个项目的稳定性策略带偏 - 改完立刻再跑
composer update --dry-run -v，观察是否跳过了之前卡住的回溯点
vcs 仓库不会立即校验 composer.json，path 会
这是最常被忽略的区别。如果你把同一个包放 Git 仓库里，用 vcs 类型引入，Composer 默认按 tag/branch 解析，不直接读取开发分支的 composer.json；但 path 类型是立刻、同步、完整加载目标目录下的 composer.json，并把它所有字段纳入约束图。
所以当你发现 vcs 引入正常，path 却报 conflict，问题一定出在本地包的 composer.json 内容上，而不是路径写错或权限问题。
实操建议：
- 不要为了“绕开校验”而强行切到 vcs —— 这会让本地开发流变重，且掩盖真实约束问题
- 如果必须保留
conflict字段（比如用于正式发布），可在本地开发分支里用 git worktree 或 .gitattributes 排除它，而不是让 Composer 每次都加载一个不适用于开发场景的约束集 - 路径引用本身没问题，问题永远在那个被加载的
composer.json是否适配当前上下文
composer.lock 就能重来，其实只要 path 仓库还在，Composer 就会反复加载那个本地 composer.json 并再次撞上同样的 conflict。
