provide 声明包虚拟提供某接口以满足依赖，conflict 硬性排除不兼容包；二者不触发安装但决定依赖解析结果，用于替代、兼容桥接与版本冲突拦截。
Composer 的 provide 和 conflict 字段不是装饰性配置，而是用于解决包间语义依赖冲突与虚拟实现的关键机制。它们不参与自动安装，但深刻影响依赖解析结果——尤其在替换、兼容层、多版本共存等场景中起决定性作用。
provide：声明“我假装是某个东西”
该字段让一个包向 Composer 声明自己“提供了”另一个包的功能接口（哪怕实际代码完全不同），从而满足其他包对那个包的 require。常用于替代包、轻量实现或兼容桥接。
- 典型用法是替代核心组件，比如
"psr/log": "^1.0"被一个精简日志封装器提供，它不依赖 Monolog，但实现了 PSR-3 接口，就能写："provide": { "psr/log": "^1.0" } - 支持通配符版本，如
"symfony/console": "*"表示“能提供任意版本的 symfony/console”，但要谨慎——Composer 不校验实际能力，只信你写的声明 - 若多个包都
provide同一包（如都声称提供cache/adapter-interface），Composer 会任选其一满足依赖；此时可配合replace或约束require来引导选择
conflict：主动拦截不兼容的组合
conflict 不是报错开关，而是依赖解析器的硬性排除规则。一旦某包被列为 conflict，Composer 在构建依赖图时会直接拒绝任何包含它的解，哪怕它只是间接依赖。
- 常见于大版本断裂场景，例如 Laravel 9 包明确写
"conflict": { "php": " 或 <code>"doctrine/dbal": "^2.0"，防止低 PHP 版本或旧 DBAL 混入 - 可用于阻止已知 bug 组合，如
"guzzlehttp/guzzle": "7.3.0"因某次发布引入竞态问题，可在你的 SDK 中直接冲突掉该精确版本 - 支持版本约束语法，包括
!=、、<code>^等；但注意conflict不支持||或复杂逻辑，需拆成多条
provide + conflict 联合控制“替代生命周期”
当你要废弃一个包并迁移到新实现时，二者配合最有效。例如：原包 acme/legacy-cache 即将停更，新包 acme/modern-cache 需无缝接管。
- 在新包中：
"provide": { "acme/legacy-cache": "^2.0" },<br>"conflict": { "acme/legacy-cache": "^2.0" }
→ 表示“我能提供 legacy-cache 的能力，但不允许它同时存在”，强制用户卸载旧包 - 旧包也可反向声明：
"conflict": { "acme/modern-cache": "*" }
避免两者被意外共装导致行为混乱 - 这种双向锁定+提供，是平滑迁移的基础设施，比文档提醒或脚本检测更可靠
注意事项与陷阱
这些字段强大，但误用会导致依赖解析失败或静默错误。
-
provide不触发自动加载或安装，你得确保类映射、autoloader、运行时逻辑真能支撑所声明的能力 -
conflict是全局生效的，如果冲突范围太宽（如"*"），可能意外阻断合法依赖链 - 不要用
provide冒充未实现的接口——Composer 不校验，但运行时报错没人替你背锅 - 查看最终解析结果可用
composer show --tree或composer depends --tree vendor/package辅助验证是否按预期生效
基本上就这些。它们不是日常开发必填项，但在构建 SDK、维护生态兼容、推动技术升级时，是绕不开的底层控制手段。
