npm EOVERRIDE：override 与直接依赖的版本写法不一致

npm install 还没完成依赖解析，就报 EOVERRIDE，并指出某个 override 与直接依赖冲突。先比较根 package.json 里的原始版本写法：即使一个范围包含另一个固定版本，npm 也不一定允许这种直接依赖的覆盖。

例如 devDependencies 声明 react-error-overlay: "^6.0.9"，overrides 却指定 "6.0.9"。固定版本确实落在那个范围里，但两份 spec 不相同，仍会触发这项限制。这里的版本用于说明历史组合，不是当前安全版本或新项目的推荐依赖。

比较 spec，不只看最终安装版本

检查错误点名的包，在 dependencies、devDependencies 等直接依赖声明中找到它，再查看根 overrides 是否同样覆盖了它。保留 ^、~ 等符号比较，不能把它们去掉后只看数字。

已核对的 npm 11.6.0 文档和解析实现要求：覆盖一个直接依赖时，依赖声明与 override 要使用相同 spec，或者用美元符号引用直接依赖的 spec。这个检查不是普通 peerDependencies 冲突；改 legacy-peer-deps 不能代替修正 override 契约。

还需确认实际执行 npm 的目录及版本。workspace 包自身的 overrides 不会像根项目的 overrides 那样参与整棵树解析，不能在错误位置修改一份同名配置后，就认定解析器已经采用它。

希望覆盖跟随直接声明，用引用

下面是要合并进根 package.json 的局部字段，不要覆盖整个文件；原来的其他依赖及 overrides 都要保留：

{
  "devDependencies": {
    "react-error-overlay": "^6.0.9"
  },
  "overrides": {
    "react-error-overlay": "$react-error-overlay"
  }
}

$react-error-overlay 引用这里直接依赖的 spec。因此它跟随 ^6.0.9 这个范围，不会继续强制原来固定的 6.0.9。若原来的目的就是锁定一个确切版本，先判断是否允许放宽，再选择修改方式，不能只因安装通过就认为策略保持不变。

另一种写法是把 override 也改为完全相同的 ^6.0.9。这同样保留范围，但两处需要一起维护。如果项目明确要求固定版本，则应在兼容性审查后把直接依赖和 override 都改成相同的固定 spec，并核对由此产生的锁文件变化。

不能只修改 override 来强制另一个版本，同时让直接依赖继续声明不一致的要求。确实要改变直接依赖版本时，应改对应依赖声明并评估消费者兼容性，而不是用覆盖掩盖它。

不要把整段 overrides 删掉

其他覆盖可能用于修正独立依赖问题。删除整个字段会同时撤销这些约束，让依赖树产生更多变化。应只处理错误点名的配置，并先保存包清单与锁文件。

也不需要为这项错误清空 npm 缓存或删除锁文件。根配置本身冲突时，重新下载还是会遇到同一限制；丢掉锁文件则扩大了重新选版本的范围。不要把 --force 当作版本兼容性证明。

按照项目已有的 npm 版本和安装流程更新，检查锁文件差异。首次 EOVERRIDE 消失后，仍可能出现 ERESOLVE，例如另一个 React peer 链冲突。这表明安装走到了下一项检查，不是完整修复失败，也不说明应撤回已经正确的 spec 修正。新的错误按React 与 react-dom 的 peer 依赖链继续排查。

验收包括依赖树与原业务功能

在隔离目录采用同一提交、版本与配置验证安装，再运行项目已有构建及关键功能。确认目标依赖实际选择的版本符合原来的范围或固定策略，同时保留其他 overrides 的预期效果。

若用 npm ci 检查可重复安装，先确保清单与审定锁文件一致，并保留目录中的手工修改；ci 会重新安装 node_modules。本地与 CI 的解析配置不同，可另查legacy-peer-deps 与锁文件校验。

需要撤回时一起恢复包清单、锁文件及本次相关配置，再按原流程恢复依赖。只恢复一个字段却留下另一套锁定结果，会重新制造不一致。