修改 composer.json 前须先用 composer why-not 和 composer depends 定位冲突根源；仅在确认兼容、阻止已知不兼容版本或放宽 dev 依赖时手动编辑 require/conflict；更新必须用 composer update 加约束参数，禁用平台检查仅限调试；replace/provide 是高危最后手段，需确保功能完全实现并经充分验证。
直接修改 composer.json 前必须确认冲突根源
盲目改 composer.json 很可能让问题更糟——Composer 报错如 Your requirements could not be resolved 或 Conclusion: don't install xxx，本质是约束条件无法同时满足。先运行 composer why-not vendor/package:version 查清谁在阻止安装，再用 composer depends vendor/package 看谁依赖了冲突包。只有当这些命令指向明确的“上游锁死”（比如某 SDK 强制要求 guzzlehttp/guzzle:^7.0，而你项目需要 ^8.0），才考虑手动干预。
修改 require 和 conflict 字段的实操边界
手动编辑只应在以下情况生效：
- 确认某依赖版本确实兼容但未被
composer.json显式声明（例如你已测试过monolog/monolog:3.5.0能正常工作，但当前锁的是 3.4.0，且无其他包硬性限制） - 添加
conflict阻止 Composer 自动选入已知不兼容的版本（例如"conflict": {"laravel/framework": "10.25.0"}，因该版本存在一个已知路由解析 bug） - 将
require-dev中的工具类包（如phpunit/phpunit）版本范围放宽，避免它间接拉低主依赖版本
切勿删除 require 中的任何生产依赖来“腾位置”，这会导致运行时缺失类；也别把 ^ 改成 *——后者等于放弃语义化版本控制，后续 composer update 可能引入破坏性变更。
composer update 加参数强制重算依赖树
改完 composer.json 后，不要直接 composer install（它只按 composer.lock 安装）。必须用带约束的 update 命令触发重新求解：
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
- 仅更新刚改的包：
composer update vendor/package --with-all-dependencies（--with-all-dependencies确保其子依赖也被重新评估） - 若仍失败，尝试缩小范围：
composer update --dry-run先看计划，或加-v输出详细冲突路径 - 极端情况下需临时禁用平台配置检查（仅调试用）：
composer update --ignore-platform-reqs，但之后务必验证 PHP 扩展、PHP 版本是否真兼容
注意：每次 composer update 都会重写 composer.lock，提交前请核对 diff，确保没意外升级/降级其他无关包。
绕过自动解析的最后手段：replace 和 provide
当两个包声称提供同一功能（如都实现 PSR-18 客户端），但互不兼容时，可用 replace 告诉 Composer “这个包我用自己的替代”：
"replace": {
"psr/http-client": "*"
}
但必须同时确保你的代码真正实现了该规范，否则运行时报 Class not found。而 provide 更危险——它假装提供某个包，实际却不含任何代码，仅用于满足依赖声明。这类操作极易导致 CI 通过但线上报错，只应在你完全掌控所有调用链、且有完整集成测试覆盖时使用。
真正难处理的从来不是语法怎么写，而是改完之后没人验证那个被跳过的版本是否真没触发隐藏的类型提示错误或扩展钩子失效。
