Next.js 14 App Router结合无头WordPress的动态路由方案咨询

针对你提出的两种路由方案，方案一更合理，下面从可维护性、扩展性、适配WordPress内容结构三个核心维度对比分析：

方案一：拆分pages和news独立catch-all路由 #

核心优势 #

• 职责边界清晰：
  • 用app/pages/[..slug]/page.js专门承接WordPress的内页（包括多级的About、Studies页面），app/news/[..slug]/page.js处理文章相关路由（列表、分类、详情页），直接对应WordPress的「Page」和「Post」两种核心内容类型，逻辑划分一目了然。
  • 首页单独用app/page.js实现，完全符合Next.js App Router的原生设计逻辑。
• 代码模块化易维护：
  不同内容类型的数据请求、渲染组件、业务逻辑可以拆分到各自的文件夹下，避免单个文件堆积大量条件判断。比如内页用getPageBySlug接口，文章用getPostBySlug接口，各自独立，后续修改某一类页面逻辑不会影响另一类。
• 路由级优化更灵活：
  可以针对不同内容类型单独配置Next.js的静态生成、缓存策略。比如内页适合用全量静态生成（generateStaticParams），文章适合增量静态再生（revalidate），直接在各自的page.js中配置即可，无需在代码里做条件分支。
• 扩展性强：
  后续如果新增内容类型（比如Products、Events），直接新增对应文件夹的catch-all路由即可，完全不影响现有代码结构。

方案二：单个根目录catch-all路由 #

核心问题 #

• 逻辑臃肿难维护：所有路由判断（内页/文章、列表/详情）都要集中在app/[..slug]/page.js中，随着页面类型增多，条件分支会越来越复杂，代码可读性和可维护性急剧下降。
• 路由优化受限：无法针对不同内容类型单独配置路由级别的静态生成、缓存规则，只能在代码中通过条件判断实现，不仅麻烦，还容易出错。
• 不符合路由设计直觉：Next.js App Router的核心思想是「文件系统即路由」，单个catch-all路由完全违背了这一设计理念，新接手的开发者需要花费大量时间理清整个判断逻辑才能上手。

补充建议（方案一的优化细节） #

• News列表页无需走catch-all，直接用app/news/page.js实现，更符合用户访问习惯（/news直接进入列表）；app/news/[..slug]/page.js专门处理文章详情、分类页等多级路由。
• 在pages/[..slug]/page.js中，通过WordPress的API获取slug对应的页面数据时，要校验数据合法性，如果返回404，直接抛出notFound()函数，Next.js会自动渲染404页面。

内容的提问来源于stack exchange，提问作者Čedomir Babić