TypeError: crypto$2.getRandomValues is not a function

先说结论：这个问题是版本配置不对导致的，经过排查node版本，  crypto-js版本，最后得出结论是：打包部署时要么node版本是18，要么vite版本改到5.4.11 ，crypto-js版本降级到3.3.0没用 依然报错。

这两天在发版时遇到一个问题

经过一系列排查之后锁定问题是版本号导致的，但一开始只以为是node版本导致的，因为我本地npm run dev 和build都正常，但只要通过jenkins 打包部署就会有这个报错，jenkins的node配置一直都是16.16.0，我本地node版本是18，但是jenkins的node升级对于我们公司来说很麻烦，需要一台新的服务器 也不现实，所以我尝试： 1. 将本地node版本降级   2. crypto-js由4.2.0降级到3.3.0 

3. 安装插件crypto-browserify去兼容  都不行，打包依然存在这个问题。

很崩溃，春节前还好好的，中间也没有提交记录。节后回来就不行了

后面我看到我的vite版本，虽然package.json里面 vite版本是5.3.1 但是package-lock.json里面版本是 5.4.14 ，（我猜测应该是同事提交代码时他的vite版本高，提交后导致的，package-lock.json提交记录里面也不会体现，所以没有发现）

 然后我将package.json里面 "vite"版本改成了 5.4.11 并且 我将^  去掉了。因为 ^ 和 ~ 是版本范围的限定符，^ 表示允许升级到不改变主版本号的最新版本，~ 表示允许升级到不改变次版本号的最新版本。然后npm i 之后再次运行之后报错就没了，  jenkins打包部署也成功了。

这样处理虽然解决当下问题，但是也会有一个弊端，vite的版本号就锁定了。

补充个小知识点：

package.json 是项目的基本配置文件，主要用于记录项目元数据、定义脚本命令和指定依赖的版本范围；而 package-lock.json 则：

1. 锁定依赖版本

记录了项目中每个依赖的确切版本号、下载地址和哈希值，即使依赖包的开发者发布了新的小版本，使用 package-lock.json 也能保证安装的是之前锁定的版本。

2. 提高安装速度
由于 package-lock.json 记录了依赖包的精确信息，当再次安装依赖时，npm 可以直接根据这个文件下载所需的依赖包，而不需要重新解析版本范围，从而提高安装速度。

3. 保证环境一致性

在团队开发或持续集成 / 持续部署（CI/CD）环境中，不同开发者或服务器上安装的依赖版本可能会因为版本范围的原因而有所不同，package-lock.json 可以确保所有人安装的依赖版本完全一致，避免因依赖版本不一致而导致的问题。

以上是豆包给出的答案，package-lock.json 主要作用就是锁定版本，保证项目在不同环境下的一致性和稳定性