应先运行 composer why-not vendor/package:version 查清冲突根源，再用 composer update vendor/package --with-all-dependencies 局部更新，避免直接删 composer.lock 或盲目执行 composer update。

composer install 报错 “found x.x.x but x.x.x was required” 怎么办

这是最典型的版本约束冲突，Composer 检测到已安装的包版本不满足当前 composer.json 中声明的约束条件。根本原因不是“装错了”，而是锁文件（composer.lock）与 composer.json 不一致，或依赖树中某包被其他依赖强制指定了不兼容版本。

• 先运行 composer why-not vendor/package:version 查清谁在阻止升级（比如 A 依赖 monolog/monolog:^2.0，而 B 要求 ^3.0）
• 不要直接删 composer.lock —— 这会导致所有依赖重解析，可能引入新冲突；优先用 composer update vendor/package --with-all-dependencies 局部更新
• 若报错来自 dev-master 或分支别名（如 "dev-main as 2.5.0"），检查该包是否真发布了对应稳定版；分支别名只是“伪装”，实际仍按 commit hash 解析

如何写兼容性更强的版本约束

宽松 ≠ 放任，^ 和 ~ 行为差异极大，且受最低稳定版本策略影响。默认 minimum-stability 是 stable，所以即使写了 "dev-main" 也可能被忽略。

• ^1.2.3 允许升级到 1.x 的任意小版本和补丁版（即 1.2.3 → 1.99.99），但不会升到 2.0.0
• ~1.2.3 更保守：只允许补丁升级（1.2.3 → 1.2.99），小版本变动（如 1.3.0）就拒绝
• 生产环境慎用 *、dev- 前缀或 branch-alias；测试时可临时加 --stability-dev，但必须明确知道哪些包因此降级了稳定性
• 如果多个包都依赖 guzzlehttp/guzzle，但各自约束不同（如 ^6.5 vs ^7.0），Composer 会选一个能同时满足的最高公共版本 —— 若无交集就报冲突

强制覆盖版本约束的几种手段及其风险

所谓“强制”，本质是绕过 Composer 的自动解析逻辑，代价是失去可复现性和协作安全性。仅限紧急修复或内部私有包场景。

dmap-jsapi-skill

DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。

下载

• composer require vendor/package:1.2.3 --no-update 再 composer update vendor/package：跳过自动推导，锁定具体版本
• 在 composer.json 中用 replace 或 provide 声明虚拟包，欺骗依赖检查（例如让自研缓存组件“提供” psr/cache-implementation）
• 修改 composer.lock 手动改某包的 version 和 source/reference 字段 —— 极易导致下次 update 被覆盖，且无法通过 composer validate
• 设置 "prefer-stable": true 并配合 "minimum-stability": "dev" 可缓解部分冲突，但会拉取大量不稳定快照，CI 环境慎用

为什么 composer update 不解决冲突，反而更糟

因为 composer update 默认更新全部包到最新兼容版本，而依赖图越复杂，全局最优解越难找。它不是“升级”，而是重新求解整个约束系统 —— 尤其当存在间接依赖（transitive dependency）时，一个小包的次要版本变动可能触发整条链路回退。

• 始终用 composer update --dry-run 预览变更，重点关注 Downgrading 和 Removing 行
• 对关键包（如 symfony/framework-bundle）执行 composer update symfony/* --with-dependencies，限制影响范围
• 如果项目长期未更新，建议分阶段操作：先 composer update --minor-only（需插件 hirak/prestissimo 或 Composer 2.2+ 原生支持），再逐步放开
• 真正棘手的冲突往往藏在 require-dev 里 —— 某个测试工具要求新版 phpunit，却和主框架的 phpunit 兼容层冲突，此时应考虑移出 require-dev 或用 platform-check 隔离

实际冲突常发生在团队协作时：有人本地 update 后提交了新 composer.lock，但没同步说明改动点。最稳妥的做法，是把 composer.lock 视为代码的一部分，每次变更都附带清晰的依赖影响说明，而不是靠“重装一遍”蒙混过关。