Next.js 13实例化控制器类时出现WEBPACK_DEFAULT_EXPORT初始化错误

这个错误ReferenceError: Cannot access '__WEBPACK_DEFAULT_EXPORT__' before initialization本质是模块初始化顺序冲突或循环依赖导致的，Next.js的SSR/模块打包机制（基于Webpack）比CRA的纯客户端打包对模块加载顺序更敏感，而你的类继承链（MyObject→BusinessObject→DataAccessObject）在这种机制下触发了未初始化的引用问题。

以下是针对性的解决方法：

1. 排查并解除循环依赖 #

循环引用是这类问题的高发原因，比如MyObject依赖BusinessObject，BusinessObject依赖DataAccessObject，而DataAccessObject又间接引用了MyObject。

• 用工具快速排查：本地运行npx madge --circular ./path/to/controllers，找出循环引用链。
• 重构代码解开循环：把共享逻辑（比如通用的数据库操作常量、类型定义）抽成独立的无依赖模块，让各个类只依赖这个独立模块，而非互相引用。

2. 调整类的导入导出与实例化时机 #

• 避免默认导出混用：把控制器的默认导出改成命名导出，减少Webpack解析时的歧义：

  // 控制器文件：@monorepo/controllers/MyObject.js
  export class MyObject extends BusinessObject {
    // ...类逻辑
  }
  

  // API路由文件中
  import { MyObject } from "@monorepo/controllers/MyObject";
  

• 延迟实例化：不在模块顶级作用域实例化类，而是放到API路由的处理函数内部执行，确保模块完全初始化后再创建实例：

  export async function GET() {
    // 仅在函数内部实例化，避免模块加载时触发未初始化引用
    const myObj = new MyObject();
    const data = await myObj.loadData();
    return Response.json(data);
  }
  

3. 重构BusinessObject的DAO实例化逻辑 #

不要在BusinessObject的构造函数中直接实例化DataAccessObject，改为懒加载方式，确保DAO在真正需要使用时才初始化：

class BusinessObject {
  #dao;

  constructor() {
    // 不在构造函数中实例化DAO
  }

  async loadData() {
    // 第一次调用方法时才初始化DAO
    if (!this.#dao) {
      const { DataAccessObject } = await import('./DataAccessObject');
      this.#dao = new DataAccessObject();
    }
    return this.#dao.find();
  }
}

4. 检查Monorepo的模块解析配置 #

确保Next.js能正确识别monorepo的路径别名，在next.config.js中添加配置：

const path = require('path');

/** @type {import('next').NextConfig} */
const nextConfig = {
  webpack: (config) => {
    config.resolve.alias['@monorepo'] = path.resolve(__dirname, '../path/to/your-monorepo-root');
    return config;
  },
};

module.exports = nextConfig;

同时确认monorepo中各个包的编译输出格式统一（比如都是CommonJS或ES模块），避免Next.js解析时出现模块类型冲突。

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