手动缓存node_modules后yarn build报找不到模块如何解决

这个实现思路本身完全可行，build报找不到模块基本都是打包、解压环节漏了关键操作，不是方案逻辑有问题。

高频踩坑点（按出现概率排序） #

• 打包时遗漏隐藏文件、软链接：node_modules下的.bin目录、包级隐藏配置、yarn生成的跨包软链接是依赖正常运行的核心，大部分GUI压缩工具、默认参数的zip命令要么跳过.开头的隐藏文件，要么把软链接当成实体文件复制，直接导致依赖引用路径错乱，monorepo子包的依赖尤其容易出这个问题。
  打包必须在项目根目录用命令行执行，参数别错：
  zip -r -y deps_cache.zip ./*/node_modules ./node_modules
  其中-y参数是核心，作用是原样保留软链接关系，不要把软链转成实体文件。不要拆分单独打包每个子目录的node_modules，会破坏目录相对路径结构，直接从根目录把所有层级的node_modules带着原有目录结构打进同一个压缩包就行。
• 解压后文件权限丢失：如果你的Azure DevOps构建代理跑在Linux环境，本地Windows/macOS打出来的压缩包解压后，node_modules/.bin下的可执行文件会丢执行权限，yarn install虽然能通过版本校验，但build阶段调用对应脚本时就会报找不到模块/命令。解压后补一行权限修正即可：
  find . -name "node_modules" -type d -exec chmod -R 755 {}/.bin \;
• 缓存和锁文件未绑定：缓存包必须和生成它时的yarn.lock做绑定，每次构建先算当前仓库yarn.lock的哈希值，只有哈希和缓存包标记的哈希完全一致时才用缓存，否则直接重新安装依赖、生成新缓存包，避免缓存内依赖版本和当前代码要求不匹配。

Azure DevOps 环境正确执行流程 #

你提到没法用yarn自带缓存是误解，不过用blob存储自定义缓存的方案完全可用，按这个顺序走不会出问题：

1. 拉取全新代码后，第一步计算当前yarn.lock的哈希值，去blob存储查有没有对应哈希的依赖缓存包
2. 存在缓存包的话直接下载到项目根目录，用unzip -o deps_cache.zip命令强制覆盖解压，不要手动挪动压缩包到子目录解压
3. 解压完成后执行yarn install --frozen-lockfile --offline，这一步会自动校验依赖完整性、补全缺失的关联关系，正常1秒内就能跑完
4. 校验通过直接执行yarn build即可
5. 如果不存在对应缓存包，正常执行yarn install --frozen-lockfile安装全量依赖，安装完成后按之前说的参数打包node_modules，上传到blob存储并标记对应yarn.lock的哈希，供后续构建使用

注意：打缓存包的时机要选在纯净的yarn install执行完成后立刻操作，不要在build、lint等会修改node_modules内容的步骤之后打包，避免缓存里混入临时文件导致异常。

内容的提问来源于stack exchange，提问作者palten08