Next.js 14 middleware 导入 firebase-admin 后报 WASM 解析错误

Next.js 14.2.4 的 middleware 导入 firebase-admin，构建或访问页面时报错，调用栈指向 farmhash_modern_bg.wasm：

Module parse failed: Unexpected character
The module seem to be a WebAssembly module,
but module is not flagged as WebAssembly module for webpack.

先核对导入发生在哪里。该版本 middleware 使用 Edge runtime，Node-only 的服务器库进入这条依赖链时，问题不只是 Webpack 少开了一个 WASM 开关。给整个项目开启 asyncWebAssembly，不能让 Edge 获得库依赖的全部 Node API。

沿导入链确认运行边界

记录 Next.js、SDK、传递依赖和构建器版本，找到 middleware 直接或间接导入的服务器模块。一个共享工具文件即使只有部分函数用于 middleware，也可能把顶层服务器依赖带入它的构建。

Edge 不支持全部原生 Node API，包使用 ESM 也不代表可在 Edge 执行。WASM 解析错误与动态编译限制也要按实际调用判断；不应根据错误里的一段通用 Webpack提示，给所有库统一配置 loader。

暂时保留 Next.js 14 时，把 Node-only 操作留在受保护的服务器入口，或者采用经过核对、支持 Edge 的鉴权实现。迁移时仍要验证令牌、权限和失败策略，不能只解码令牌内容就视为完成认证。

15.5 与 16 的配置不能混用

Next.js 15.5 起 Node.js Middleware 支持稳定。采用这一升级路径时，按对应版本的 middleware 约定选择 Node runtime，同时检查部署平台支持；升级依赖、设置运行时和实际部署验收需要一起完成。

Next.js 16 将文件约定改为 proxy.ts，命名导出也改为 proxy，默认使用 Node.js runtime。当前 16.4 的 Proxy 文件不能设置 runtime 配置选项，设置它会报错。因此，不能把旧 middleware 中选择 runtime 的写法不加区别地带到 proxy 文件。

旧文件有 matcher、重写、header、cookie 等逻辑时，迁移要保留并重新验收这些行为。重命名文件不会证明全部路由已经覆盖，也不应让静态资源、图片和登录入口意外进入鉴权重定向循环。

选择 Node runtime 解决的是运行环境边界，不承诺任意 SDK、任意 WASM 加载方式在所有版本都可用。若已经运行于 Node 仍失败，继续分析当前构建器和实际依赖，不将旧 Edge 结论当成当前根因。

数据入口继续执行权限检查

Proxy 或 middleware 可以处理路由前的检查与跳转，但业务读写入口仍要自行验证身份和权限。不能因为页面经过 Proxy，就让接口或 Server Action 信任客户端传来的用户标识。

客户端可公开的数据与服务器凭据也要分开。修复导入时，不要把 admin SDK 及其密钥改成浏览器依赖，更不能为通过构建删除鉴权调用。

保存原依赖、锁文件、路由前置逻辑和部署配置，在受控环境验证完整构建、受保护与公开页面、无效令牌、接口直访及静态资源。回退应恢复整套对应产物与配置；多副本部署另需检查Server Action 构建版本一致性，它与这个 middleware 的运行时问题不同。