Next 14（App Router）+ fetch() + .env构建报错求助

构建时预渲染错误的核心原因 #

执行npm run build时，Next.js会触发预渲染（静态生成/SSG）流程，此时本地开发服务器http://localhost:3000并未启动。你的代码通过NEXT_PUBLIC_API_URL=http://localhost:3000调用/api/events，构建阶段发起的fetch请求无法拿到正常JSON响应，反而会收到404页面的HTML内容——这就是TypeError: fetch failed（请求无有效响应）和SyntaxError: Unexpected token '<'（把HTML当成JSON解析）的根源。

针对性解决策略 #

1. 优先采用：服务器组件直接调用Prisma #

在Next.js App Router中，服务器组件直接调用Prisma是官方推荐的最佳实践，完全不需要额外走API层：

• 服务器组件在服务器端运行（包括构建预渲染阶段），可以直接访问Prisma客户端和数据库，无需通过HTTP请求中转。
• 既解决了构建时的fetch错误，又减少了API层的额外开销，代码逻辑更简洁。

示例代码（服务器组件）：

// app/events/page.tsx
import prisma from '@/lib/prisma';

export default async function EventsPage() {
  const events = await prisma.event.findMany();
  return (
    <div>
      {events.map(event => <div key={event.id}>{event.name}</div>)}
    </div>
  );
}

2. 若需保留API调用（如客户端组件场景） #

如果是客户端组件必须调用API，可通过以下方式规避构建错误：

• 给组件添加dynamic="force-dynamic"，强制组件在运行时渲染（构建时不预渲染），这样运行时服务器已启动，fetch请求能正常访问localhost:3000：

  // app/events/ClientEvents.tsx（客户端组件）
  'use client';
  
  export default function ClientEvents() {
    // 客户端fetch逻辑
    const fetchEvents = async () => {
      const res = await fetch(`${process.env.NEXT_PUBLIC_API_URL}/api/events`);
      const data = await res.json();
      return data;
    };
    // ...其他逻辑
  }
  
  // 父服务器组件中引入
  import ClientEvents from './ClientEvents';
  export default function EventsPage() {
    return <ClientEvents dynamic="force-dynamic" />;
  }
  

关于环境变量的疑问 #

不需要新增构建环境变量，你当前的问题核心不是变量本身，而是构建阶段localhost服务不可用导致的fetch失败。NEXT_PUBLIC_API_URL的作用是给客户端提供API地址，但构建预渲染阶段是服务器端执行，此时用这个变量调用本地API本身就是错误策略。

直接在组件中调用Prisma是否正确？ #

完全正确，且是Next.js App Router的推荐方案：

• 安全性：服务器组件不会将Prisma代码或数据库凭证暴露给客户端，所有数据库操作都在服务器端完成。
• 性能：省去了HTTP请求的往返开销，数据获取更高效。
• 注意事项：
  • 仅在服务器组件中调用Prisma，客户端组件不能直接使用（会导致数据库凭证泄露）。
  • 做好错误处理，比如用try/catch捕获数据库操作异常。
  • 若需要数据缓存，可结合Next.js的fetch缓存机制（如next: { revalidate: 60 }）或Prisma的查询缓存。

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