一、yarn.lock文件冲突的解决之道
在团队协作开发中，yarn.lock文件冲突简直是家常便饭。这个文件记录了每个依赖包的确切版本，当多人同时修改依赖时，Git就会无情地抛出冲突提示。
典型场景：
小张添加了lodash@4.17.20，同时小李在另一个分支升级到了lodash@4.17.21，合并时就会看到这样的冲突：
<<<<<<< HEAD
lodash@^4.17.20:
version "4.17.20"
=======
lodash@^4.17.21:
version "4.17.21"
>>>>>>> feature/upgrade-deps
解决方案：
- 保守派：保留较新版本（手动合并后运行
yarn install） - 激进派：直接删除
yarn.lock后重新生成（慎用！可能引发依赖地狱） - 稳妥派：使用
yarn import从package.json重新生成（会尽量保持现有版本）
# 技术栈：Node.js + Yarn
rm yarn.lock # 删除冲突文件
yarn import # 从package.json重建
yarn install # 验证依赖树
注意：如果项目使用了
resolutions字段强制指定版本，需要特别检查该配置是否被冲突影响
二、依赖安装失败的常见姿势
当看到Error: Can't resolve dependency时，别急着砸键盘，试试这些方法：
经典错误案例：
error An unexpected error occurred: "https://registry.yarnpkg.com/react/-/react-17.0.2.tgz:
ETIMEDOUT 请求超时"
三板斧解决方案：
- 换源大法：
yarn config set registry https://registry.npmmirror.com
- 缓存清理：
yarn cache clean
- 网络重试（适合CI环境）：
# 重试3次，间隔5秒
for i in {1..3}; do yarn install && break || sleep 5; done
深度修复方案：
当依赖树出现环形引用时（比如A依赖B@1.0，B@1.0又依赖A@latest）：
yarn why <package-name> # 先定位问题依赖
yarn upgrade-interactive # 交互式更新
三、缓存损坏的急救方案
Yarn的缓存目录（默认在~/.cache/yarn）偶尔会抽风，表现为：
- 安装时报
Invalid checksum - 明明网络正常却提示包不存在
核弹级清理：
# Linux/Mac
rm -rf ~/.cache/yarn/v6
# Windows
rd /s /q "%LOCALAPPDATA%\Yarn\Cache"
温和型修复：
# 验证缓存完整性
yarn check --verify-tree
# 选择性重建
yarn install --force
缓存迁移技巧（适合多环境部署）：
# 导出已缓存依赖
yarn cache list > cached-packages.txt
# 在新环境预加载
cat cached-packages.txt | xargs yarn cache add
四、防患于未然的最佳实践
锁文件版本控制：
在.gitattributes中添加：yarn.lock merge=union让Git自动合并非冲突变更
依赖安装优化：
# 使用--frozen-lockfile确保环境一致 yarn install --frozen-lockfile # 生产环境去掉devDependencies yarn install --production缓存策略：
# 设置缓存目录（适合Docker构建） yarn config set cache-folder /tmp/yarn-cache # 离线安装模式 yarn install --offline
终极忠告：
当遇到玄学问题时，记住这个万能口诀：
rm -rf node_modules yarn.lock && yarn install
虽然暴力，但有效率达90%以上。当然，记得先commit你的代码变更！
评论