Rollup 提示找不到原生模块，cause 却是 GLIBC_2.32 not found

Linux 构建突然停在 Cannot find module @rollup/rollup-linux-x64-gnu，错误还建议删除锁文件、重新安装。先展开完整 cause。如果里面已经写出了 .node 文件路径和下面的错误，就不应继续按“包没有装上”处理：

version `GLIBC_2.32' not found
code: 'ERR_DLOPEN_FAILED'

这表示动态加载器找到了原生文件，却无法满足它要求的 glibc 符号。重复安装同一个不兼容二进制，不会给运行系统补出这些符号。

4.62.3 的原生产物出现过兼容性回归

Rollup 4.62.3 的 Linux x64 GNU 产物提高了实际 glibc 要求，导致 Debian 11 Bullseye、RHEL 8 系列等较旧环境加载失败。错误中先显示 2.32，并不表示整个二进制只需要 glibc 2.32；同一产物还可能引用更高版本的符号。

正式 4.62.4 修复了这次旧 Linux 兼容性回归。它是已确认包含修复的版本，不是要求所有项目现在固定到这个旧版本。应在当前工具链支持范围内采用包含修复的受维护版本，并核对真正参与构建的 Rollup 与平台包。

先在失败的构建环境检查，而不是只查看开发机：

getconf GNU_LIBC_VERSION
npm ls rollup @rollup/rollup-linux-x64-gnu

上面第二个包名只对应 Linux x64 GNU。ARM 或 musl 环境应查看实际错误中的平台包，不能为了安装成功强行加入另一种架构的包。包管理器不同，也应保留项目原有的锁文件和依赖管理方式。

若 Rollup 由 Vite 等工具间接带入，沿依赖树找到版本约束，再按上层工具支持的组合更新。不要只把平台包强制覆盖到与 Rollup 本体不同的版本，也不要把某个副本显示新版本当成所有工作区都已切换。

外层安装提示并不能区分所有加载错误

受影响版本的原生加载包装会把多种 require 失败统一改写成“Cannot find module”，同时把真实错误放到 cause。确实缺少可选平台包时，应检查安装日志、锁文件和平台选择；但当 cause 已经是 ERR_DLOPEN_FAILED 与缺少 glibc 符号时，重点是产物兼容性。

Rollup 4.65.0 还改进了原生模块启动错误的转发。更新后错误文字可能不同，不能用外层一句提示是否变化来判断二进制已恢复兼容。

不要为一个构建依赖手工替换系统 libc，或把其他发行版的 libc 塞进全局动态库路径。这会影响同机其他程序。优先更换兼容的应用依赖产物；需要升级基础镜像时，按原有迁移与回退流程处理完整工具链。

修正依赖后重新生成构建环境，用原来的打包入口验收，并核对实际解析版本。若产物还要部署到另一套旧系统，构建机通过也不能代替目标环境的加载检查。只有原生模块能加载、构建完整结束、生成的页面或应用能正常使用，才算这条故障恢复。

若 cause 指向的是包文件缺失、架构不匹配或 musl/glibc 选错，应转查相应分支；不要把所有 Rollup 原生加载失败都归到 4.62.3 的这次回归。