Next.js使用msnodesql连接Windows认证SQL Server报错排查

两个报错本质是同一个问题：msnodesqlv8是Node.js专属原生二进制模块，依赖process.dlopen、Windows系统底层ODBC接口等仅服务端Node runtime存在的能力，完全无法在浏览器环境运行。你当前的配置将数据库连接逻辑打包进了客户端前端bundle，webpack尝试将原生.node文件做浏览器兼容处理，才先后触发二进制文件解析失败、process.dlopen is not a function的运行时错误。重装node_modules完全解决不了环境分层的问题。

• 所有数据库相关逻辑必须全部放在Next.js服务端侧执行，禁止在客户端组件、直接面向浏览器的代码中直接导入msnodesqlv8或数据库连接文件。合法的执行位置包括：getServerSideProps/getStaticProps服务端数据获取方法、pages/api/路径下的API路由、App Router模式下的服务端组件/服务端动作。
• 修正next.config.js配置，区分服务端、客户端的webpack打包规则，不要给客户端侧打包原生模块，同时删掉多余的浏览器端polyfill配置，参考配置如下：

module.exports = {
  webpack: (config, { isServer }) => {
    if (isServer) {
      // 仅服务端启用node-loader处理.node原生二进制文件
      config.module.rules.push({
        test: /\.node$/,
        loader: "node-loader",
      });
    } else {
      // 客户端侧打包时直接忽略msnodesqlv8相关依赖，避免被打进前端bundle
      config.resolve.alias = {
        ...(config.resolve.alias || {}),
        msnodesqlv8: false,
        "mssql/msnodesqlv8": false,
      };
    }
    // 移除原有配置中fs/path/os/timers等服务端模块的fallback项，这些模块不需要在浏览器侧模拟
    config.experiments = {
      ...config.experiments,
      topLevelAwait: true,
    };
    return config;
  },
};

• 排查代码引用关系：你报错栈里提到的src/API/connection.js目前被前端页面quiz-portal.js直接导入，这是核心错误点。页面如果需要数据库数据，要么在服务端数据获取方法中调用连接逻辑，将处理后的非敏感数据传给页面渲染；要么封装成API接口，前端仅通过fetch调用接口拿数据，绝对不能让前端代码直接接触数据库连接逻辑。

如果不想处理原生模块的编译、打包问题，可以直接用mssql包内置的tedious驱动实现Windows身份验证，不需要依赖msnodesqlv8，也不需要编译任何二进制文件，配置参考：

const sql = require('mssql')
// 注意：以下逻辑同样必须运行在Next.js服务端，不能在浏览器侧执行
const poolPromise = new sql.ConnectionPool({
  server: '你的SQL Server实例地址',
  database: '目标数据库名',
  driver: 'tedious',
  options: {
    trustedConnection: true, // 开启Windows集成身份验证
    encrypt: false, // 根据你的SQL Server实际TLS配置调整，本地开发默认一般为false
    trustServerCertificate: true
  }
}).connect();

该方案的权限要求和msnodesqlv8完全一致：运行Next.js服务的Windows账号需要拥有目标SQL Server的对应访问权限，不需要额外安装SQL Server Native Client组件。

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