Yarn 换了依赖，Vite 仍用旧代码：检查 pnpm linker 的缓存识别

yarn install 已经把依赖升级，Vite 开发页却仍执行旧版本代码，重启也没有提示重新优化依赖。若 Yarn 4 配了 nodeLinker: pnpm，检查 Vite 是否找到了能够反映安装变化的锁文件。

Vite 8.3.0、8.3.3 与 Yarn 4.1.1 的这一组合中，node_modules/.vite/deps/_metadata.json 的 lockfileHash 可以一直是 e3b0c442。这是空字符串的短哈希，表示这条缓存判断没有读到预期文件，不表示项目真的没有依赖变化。

包管理器名称相同，安装布局未必相同

旧识别路径针对 Yarn 检查 node_modules/.yarn-state.yml 和 .pnp.cjs。pnpm linker 不一定生成这些文件，也不等于真正由 pnpm 安装，因此不能期待 node_modules/.pnpm/lock.yaml 必然存在。

先核对 .yarnrc.yml 中实际启用的 linker，再比较锁文件、已安装包版本、预构建响应内容与缓存元数据。已安装包变了，浏览器仍拿到旧代码，才符合这里的链条。若磁盘上的包也没变化，应先处理安装或工作区解析。

8.3.5 的正式实现已增加 yarn.lock 回退

Vite 8.3.5 在常规安装状态文件全部缺失时，会继续查找 yarn.lock，并把它的内容纳入锁文件哈希。项目兼容时，可通过原包管理流程采用包含该逻辑的正式版本，保留清单与锁文件，再停止旧开发服务并重启。

这里确认的是 8.3.5 已包含此实现，不把它写成未经核对的首个修复版本。框架自带 Vite 时，确认实际执行的那份版本，避免只升级顶层包而框架继续运行旧副本。

暂时无法更新时，可以在每次相关依赖变化后，通过真正调用 Vite 的开发命令传入 --force。若 dev 脚本直接是 Vite，形如：

yarn dev --force

参数会强制重做开发预构建。脚本经过框架或其他包装时，按其透传规则处理。它能更新当次缓存，却没有修好旧版的自动失效判断，因此下一次依赖变化仍需留意。

不要创建内容不真实的 .yarn-state.yml 来骗过识别，也不必删除锁文件或清空 Yarn 的全部缓存。后两种操作会改变依赖现场，无法证明 Vite 已能感知正确的状态文件。

验收下一次变化，而不只是首次强制刷新

先确认预构建响应中的实际依赖代码已更新，再在受控分支做一次正常依赖变更，沿原流程安装和启动，检查无需强制参数时哈希也会变化、页面执行新代码。自定义 cacheDir 时，检查那个目录的元数据，别盯着未使用的默认路径。

最后按原流程单独检查生产构建。开发预构建缓存恢复，只能证明开发依赖优化链条恢复，不代表生产资源和部署路径已经验收。