Nuxt生产环境部署到Vercel时从public目录加载MDX文件失败问题排查

看起来你遇到了Nuxt项目部署到Vercel生产环境后，无法正确加载public目录下MDX文件的问题——开发环境一切正常，但生产环境就是报动态导入失败的错误，而且文件明明已经出现在Vercel的静态资源列表里，这确实挺让人困惑的。我来帮你拆解一下问题原因，再给出可行的解决方案。

问题根源分析 #

你当前的实现逻辑在开发环境能工作，但生产环境不行，核心原因在于Nuxt对public目录文件的处理方式，以及动态import()的工作机制：

• 在开发环境中，../../public/docs这个相对路径指向的是项目源码里的MDX文件，Vite的开发服务器会实时编译这些MDX文件为可导入的JS模块，所以import()能正常工作。
• 但部署到Vercel生产环境后，public目录下的文件会被当作静态资源直接托管，不会经过Nuxt的编译流程。这时候你用import('/docs/xxx.mdx')，浏览器会请求这个静态资源URL，但拿到的是原始的MDX文本，而不是编译后的JS模块——浏览器自然无法识别，就会抛出“Failed to fetch dynamically imported module”的错误。

你提到MDX文件已经出现在Vercel的静态文件列表中，能看到文件路径正确，但这只是说明静态资源托管正常，不代表它能被当作JS模块导入。

解决方案 #

根据你的需求，我提供两种可行的方案，你可以根据自己的场景选择：

方案一：迁移MDX文件到源码目录（推荐） #

把MDX文件从public/docs移动到项目的源码目录（比如assets/docs或者专门的content/docs），让Nuxt在构建时编译这些文件，这样动态导入就能正常工作：

1. 调整文件位置：将public/docs下的所有MDX文件移动到assets/docs目录。
2. 更新环境变量：修改.env和.env.production：

   # 开发环境
   DOCS_BASE_PATH=~/assets/docs
   # 生产环境
   DOCS_BASE_PATH=~/assets/docs
   

   （~/是Nuxt的别名，指向项目根目录）
3. 修改loadMDX函数：
   因为现在MDX文件会被Nuxt编译，我们可以直接导入包含frontmatter的模块，不需要单独fetch文本解析：

   async function loadMDX(componentPath) {
     try {
       const { public: { docsBasePath } } = useRuntimeConfig();
       // 直接导入编译后的MDX模块（包含frontmatter）
       const module = await import(`${docsBasePath}/${componentPath}`);
       // 大部分MDX编译插件会把frontmatter放在module.frontmatter里，根据你的插件调整
       docsStates.value.selectedDocMatter = module.frontmatter;
       mdxContent.value = wrapWithProvider(module.default);
     } catch (error) {
       console.error(error);
       mdxContent.value = null;
     }
   }
   

   如果你之前依赖vfile-matter解析，需要确保你的MDX编译插件（比如@nuxtjs/mdx）已经配置为保留frontmatter。

方案二：使用MDX运行时编译（适合必须保留public目录的场景） #

如果你因为某些原因必须把MDX文件放在public目录，那需要在客户端用MDX运行时编译器来解析原始MDX文本，而不是依赖Nuxt的预编译：

1. 安装运行时依赖：

   npm install @mdx-js/runtime @babel/runtime
   

2. 修改loadMDX函数：
   去掉import()步骤，改用运行时编译器生成组件：

   import { mdx } from '@mdx-js/runtime';
   
   // ... 其他代码不变
   
   async function loadMDX(componentPath) {
     try {
       // 1) Fetch原始MDX文本
       const res = await fetch(`/docs/${componentPath}`);
       const text = await res.text();
   
       // 2) 解析frontmatter
       const file = new VFile({ value: text });
       matter(file);
       docsStates.value.selectedDocMatter = file.data.matter;
   
       // 3) 使用运行时编译器生成组件
       const MDXComponent = mdx(text, {
         components: {
           Codeblock,
           TabbedCodeBlock,
           Callout,
           BrowserView,
           DirStructure,
           table: Table,
           hr: HorizontalRule,
           h2: VdocsH2,
           ul: VdocsList,
           pre: VdocsBasiCodeBlock,
         }
       });
       mdxContent.value = defineComponent({
         setup() {
           return () => h(MDXComponent);
         },
       });
     } catch (error) {
       console.error(error);
       mdxContent.value = null;
     }
   }
   

   这种方式的缺点是会增加客户端的编译开销，性能不如预编译，但能满足你保留public目录的需求。

额外注意事项 #

• 如果你用方案一，记得在Nuxt配置文件中确保MDX插件已经正确配置，比如@nuxtjs/mdx：

  // nuxt.config.ts
  export default defineNuxtConfig({
    modules: ['@nuxtjs/mdx'],
    mdx: {
      frontmatter: true, // 确保frontmatter被保留
    }
  });
  

• 在Vercel部署时，确保构建命令正确（比如npm run build），Nuxt会正确编译源码目录下的MDX文件。

备注：内容来源于stack exchange，提问作者Ketsebaot Gizachew