Next.js同项目集成API与静态站点导出的方案咨询

不需要强制拆分API和前端模块，同一个项目完全可以满足需求，你遇到的构建报错本质是静态构建阶段没有运行中的服务端，硬编码的本地端口接口请求自然无法拿到响应。

最适配你场景的同项目实现方案（无需额外部署服务） #

你的数据基本固定、没有频繁更新需求，完全没必要保留运行时API，调整下数据获取逻辑就行，全程不用拆分项目：

• 先把原来写在API Routes里的SQLite查询逻辑抽成独立的公共函数，比如把app/api/xxx/route.js里读库的逻辑拆到lib/data.js这类公共文件里，直接导出可调用的查询函数，不要把数据读取逻辑死死绑在API路由上。
• 页面拿数据的时候，不要再写fetch请求打本地接口，直接在服务端组件、generateStaticParams（App Router）或者getStaticProps（Pages Router）里调用刚才抽好的查询函数。构建阶段Next.js会直接执行这些逻辑，从SQLite读数据，把内容直接预渲染进静态HTML，全程不需要发HTTP请求，自然也不存在接口地址写错的问题。
• 配置next.config.js开启静态导出：

/** @type {import('next').NextConfig} */
const nextConfig = {
  output: 'export',
  // 如果用了next/image又没接第三方图片优化服务，加下面这行
  images: { unoptimized: true }
}
module.exports = nextConfig

• 抽完逻辑后，原来的API Routes文件不会被打进静态导出包——毕竟纯静态站点没有Node运行时，跑不了服务端接口逻辑。如果这些接口没有外部系统调用的需求，直接删掉就行，完全不影响静态页面生成。

这个方案是静态站点的最优选择：构建完直接把生成的out目录扔到任何静态托管服务上就能跑，不需要跑Node服务，也不用带数据库，访问速度最快，也不会有跨域、接口地址不对的问题。

需要保留对外API能力时的处理方式 #

如果你确实需要把这些API开放给其他外部客户端调用，再考虑拆分或者调整部署模式：

• 不想拆分项目的话，就把静态导出的前端资源部署到静态托管，API部分单独部署成Node服务，前端代码里用环境变量区分开发/生产环境的接口地址，不要硬写本地端口，生产环境指向你部署好的API服务域名即可。
• 不想分开部署的话，就不要开静态导出模式，直接把整个Next.js项目以Node服务的形式部署，前端和API同域运行，自然不会有接口地址问题，只是这种部署方式需要支持Node运行时的主机，不能用纯静态托管服务。

你之前构建报错的根本原因 #

跑next build生成静态文件的时候，本地并没有启动next dev或者next start的服务，你写死的http://localhost:端口/api/xxx这类地址在构建阶段根本访问不到，自然会报fetch失败。就算你特意在构建前先启动本地服务，静态导出的产物里也不会包含API路由对应的运行逻辑，部署上线后用户请求这些接口还是会返回404。

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