解决Next.js与next-intl中间件导致的资源请求404问题

在使用Next.js国际化方案next-intl时，开发者可能会遇到一个常见问题：当项目中使用第三方UI库（如PrimeReact）时，.next目录下的静态资源请求会被中间件重定向到带有语言前缀的路径，导致404错误。

问题现象

在项目中同时使用next-intl和PrimeReact时，浏览器会尝试加载.next目录下的静态资源文件（如CSS、JS等）。然而，next-intl的中间件配置可能会将这些请求重定向到类似.next/[locale]/...的路径，由于该路径不存在，最终导致404错误。

问题根源

问题的核心在于中间件的匹配规则（matcher）配置不当。默认情况下，next-intl的中间件会匹配所有非特定路径的请求（如_next、_vercel等），并将它们重定向到带有语言前缀的URL。这种设计对于页面路由是合理的，但对于静态资源请求则会导致问题。

解决方案

正确的做法是在中间件配置中明确排除对.next目录下静态资源的处理。next-intl官方文档提供了两种配置方式：

1. 显式排除静态资源路径：

const CONFIG = {
  matcher: [
    // 匹配根路径
    "/",
    // 匹配带有语言前缀的路径
    `/(${LOCALES.join("|")})/:path*`,
    // 排除静态资源路径
    "/((?!_next|.next|_vercel|.*\\..*).*)"
  ]
}

2. 动态获取支持的语言列表（推荐）：

const CONFIG = {
  matcher: [
    // 匹配所有路径，但不包括已知路径和文件
    "/((?!_next|.next|_vercel|.*\\..*).*)"
  ]
}

最佳实践

1. 明确排除静态资源：在matcher配置中，确保明确排除了.next和_next目录，这是Next.js存放构建产物的标准位置。

2. 使用动态语言列表：避免在matcher中硬编码语言列表，这样当语言配置变更时不需要同步修改中间件配置。

3. 测试资源加载：配置完成后，务必检查浏览器开发者工具中的网络请求，确保所有静态资源都能正常加载。

4. 考虑CDN场景：如果项目部署在CDN上，确保CDN配置不会干扰静态资源的请求路径。

总结

Next.js国际化是一个强大的功能，但在与第三方库集成时需要注意中间件对静态资源请求的影响。通过合理配置matcher规则，可以确保国际化功能正常工作的同时，不影响静态资源的加载。这种配置方式不仅适用于PrimeReact，也适用于其他需要在Next.js中使用静态资源的第三方库。