遇到依赖版本冲突应先分析ERESOLVE报错的三句话定位导火索、现有版本和依赖要求，再用npm ls命令查依赖树结构，结合lock文件与peerDependencies声明确认根因，最后通过overrides等精准方案解决。
遇到依赖版本冲突，别急着删 node_modules 或加 --force。先看清报错在说什么，再顺着依赖树一层层定位，才是高效解法。
读懂 ERESOLVE 报错的三句话
npm 7+ 的 ERESOLVE 错误其实已经把关键信息写清楚了，重点看三段：
- While resolving: 正在安装/校验哪个包（冲突的“导火索”）
-
Found: 项目里已有的版本（比如
react@17.0.2） -
Could not resolve dependency: 新包要求的 peer 或子依赖版本（比如
peer react@"^18.0.0"）
这三句合起来就是：“你想装 A 包，但它硬要 React 18，而你项目里只有 React 17。” 理清这个逻辑，方向就明确了。
用命令查清依赖树真实结构
别猜，直接看实际安装结果：
立即学习“Java免费学习笔记（深入）”；
-
npm ls <package-name>：查某个包在树里装了几份、在哪一层（比如npm ls react） -
npm ls --depth=0：只看顶层直接依赖，快速确认有没有意外提升的包 -
npm ls --all | grep -A5 -B5 <package-name>：在完整树里搜关键词，找隐藏的间接引用
如果发现同一个包（如 lodash）出现在多个层级，且版本不同，那就是潜在冲突源。
检查 lock 文件和 peer 依赖声明
package-lock.json 是当前依赖关系的“事实快照”，比 package.json 更可信：
- 打开它，搜索冲突包名，看它被解析出的具体版本和所在路径
- 对照报错里的
peer提示，去相关包的node_modules/<pkg>/package.json里查它的peerDependencies字段，确认约束是否真不兼容 - 注意
devDependencies里有没有意外引入生产环境包（比如误装了webpack到dependencies）
针对性解决，不盲目升级或降级
确认根因后，优先选影响最小的方案：
- 若只是 peer 版本不匹配，且你确定能兼容，用
"overrides"强制统一（npm 8.3+）：
"overrides": { "react": "18.2.0", "antd": { "react": "18.2.0" } } - 若某间接依赖版本太老导致冲突，可尝试在
resolutions（yarn）或overrides（npm）中锁定它 - 避免直接
npm install xxx@latest——语义化版本的^可能拉来不兼容的大版本，应明确指定小版本范围（如"^18.2.0"）
