Next.js结合Contentful CMS实现重定向的两种方案可行性咨询

方案一的可行性与问题解决 #

方案一完全可行，你遇到的ERR_MODULE_NOT_FOUND错误是由于next.config.mjs的模块解析规则与Next.js页面/数据获取函数不同导致的，并非方案本身不可行。以下是具体解决步骤和最佳实践：

1. 模块导入错误的修复 #

next.config.mjs运行在Node.js的ES模块环境中，路径解析逻辑与页面组件的Webpack解析不同，需注意以下几点：

• 使用正确的相对路径：如果你的next.config位于apps/dfds-unified-web/next.config.mjs，而redirects模块在同级的apps/api-calls/graphql/redirects，导入路径应改为相对路径：

  // next.config.mjs
  import getRedirects from '../api-calls/graphql/redirects';
  

• 确认模块导出格式：确保redirects模块使用ES模块导出（而非CommonJS的module.exports）：

  // apps/api-calls/graphql/redirects.js
  export default async function getRedirects() {
    // 调用Contentful GraphQL API获取重定向数据
    const res = await fetch('https://graphql.contentful.com/content/v1/spaces/[SPACE_ID]', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': 'Bearer [ACCESS_TOKEN]'
      },
      body: JSON.stringify({
        query: `
          query GetRedirects {
            redirectsCollection {
              items {
                fromUrl
                toUrl
              }
            }
          }
        `
      })
    });
    const data = await res.json();
    return data.data.redirectsCollection.items;
  }
  

• Monorepo路径配置：如果是TurboRepo等monorepo结构，可在next.config中配置路径别名简化导入：

  // next.config.mjs
  import path from 'path';
  
  const nextConfig = {
    webpack: (config) => {
      config.resolve.alias['@api-calls'] = path.resolve(__dirname, '../api-calls');
      return config;
    },
    // 其他配置...
  };
  

  之后即可用import getRedirects from '@api-calls/graphql/redirects';导入。

2. 方案一的正确实现 #

Next.js的redirects()函数支持异步，可直接在其中调用CMS API获取重定向规则：

// next.config.mjs
import getRedirects from '../api-calls/graphql/redirects';

/** @type {import('next').NextConfig} */
const nextConfig = {
  async redirects() {
    const cmsRedirects = await getRedirects();
    return cmsRedirects.map(redirect => ({
      source: redirect.fromUrl, // 注意格式：如'/old-path'
      destination: redirect.toUrl, // 如'/new-path'或外部链接
      permanent: true, // true对应301永久重定向，false对应302临时重定向
    }));
  },
};

export default nextConfig;

3. 方案一的适用场景与注意事项 #

• 适用场景：适合大量独立重定向（如旧路径跳转、无对应Page的路径跳转）、需要集中管理重定向规则的场景。
• 静态构建限制：如果使用SSG静态构建，重定向规则会在构建时固化，后续CMS更新重定向需重新构建。若需实时更新重定向，应改用Next.js Middleware在运行时动态获取规则并处理跳转：

  // middleware.js
  import { NextResponse } from 'next/server';
  import getRedirects from '@api-calls/graphql/redirects';
  
  export async function middleware(request) {
    const redirects = await getRedirects();
    const matchingRedirect = redirects.find(r => request.nextUrl.pathname === r.fromUrl);
    if (matchingRedirect) {
      return NextResponse.redirect(new URL(matchingRedirect.toUrl, request.url));
    }
    return NextResponse.next();
  }
  
  export const config = {
    matcher: ['/:path*'], // 匹配所有路径
  };
  

方案二的分析与对比 #

方案二将重定向字段与Page类型绑定，实现更简单，适合以下场景：

• 重定向仅关联现有Page（如页面URL变更后跳转）
• 重定向数量较少，无需集中管理

其核心实现方式是在getStaticProps中返回redirect对象：

// pages/[slug].js
export async function getStaticProps({ params }) {
  // 从Contentful获取Page数据
  const pageData = await getPageBySlug(params.slug);
  
  // 如果页面设置了重定向
  if (pageData.redirect) {
    return {
      redirect: {
        destination: pageData.redirect,
        permanent: true,
      },
    };
  }

  return {
    props: { pageData },
  };
}

方案二的优缺点 #

• 优点：内容建模贴合Page关联关系，实现简单，无需额外维护独立的Redirects类型。
• 缺点：重定向逻辑分散在页面中，大量重定向时维护成本高；无法处理已删除Page的旧路径跳转（因为Page不存在则无法触发getStaticProps）。

最终建议 #

• 优先选择方案一的场景：需要集中管理重定向、存在无对应Page的跳转需求、重定向数量较多。注意根据更新频率选择静态构建重定向或Middleware动态重定向。
• 优先选择方案二的场景：重定向仅关联现有Page、数量较少，追求快速实现。

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