Next.js 页面切换后样式被污染问题

2025年7月30日·前端开发

Next.js 和 Tailwind CSS 构建博客系统过程中，页面跳转后出现样式丢失或错乱，实质是全局 CSS 类名在 App Router 架构下发生了污染

在构建基于 Next.js 和 Tailwind CSS 的博客系统时，我遇到一个页面切换后样式被污染的问题：从分类页跳转回首页后，文章卡片的样式出现了丢失或改变。

问题现象

首页 page.tsx 通过服务端渲染加载文章数据，并用 MainContent 组件渲染文章列表。每篇文章通过 .article-item 类名包装，样式定义在 app/styles/home.css。初次访问首页时样式正常，但从分类页等页面跳转回首页时，文章卡片样式部分消失或布局错乱。

技术背景

Next.js App Router（app 目录）
Tailwind CSS
样式模块化，每个页面对应一个 CSS 文件
部分组件为客户端组件（use client）

原因分析

1. 类名复用导致样式污染

首页和分类页等页面都定义了 .article-item，但样式内容不同。由于 Next.js App Router 的页面切换是客户端渲染，前一个页面的 CSS 仍然保留在页面中，导致相同类名的样式被后加载的 CSS 覆盖或污染。即使显式 import 样式文件，也无法避免 CSS 作用域冲突。

2. CSS 作用域全局化

Next.js 默认的 CSS（包括通过 import 进来的 CSS 文件）是全局作用域。只要类名相同，后加载的样式就会影响所有同名元素。这在页面切换时尤为明显，尤其是 Tailwind 结合自定义类名时。

3. Tailwind 构建机制

Tailwind 会扫描所有用到的类名生成原子类，但自定义类名（如 .article-item）的样式完全依赖于你在 CSS 文件中的定义，且不会自动隔离作用域。

之前方案的局限

显式导入页面样式：无法解决全局作用域污染问题。
抽离全局样式：如果不同页面对同一类名有不同需求，抽离到全局反而会丢失页面差异化。
原子类替代自定义类名：虽然推荐，但如果组件复杂或样式复用多，维护成本高。

更优解决方案

1. 使用 CSS Modules 实现样式隔离（强烈推荐）

将页面或组件样式文件改为 CSS Modules（如 home.module.css），并通过模块化 className 绑定，彻底避免全局类名污染。

示例：

/* app/styles/home.module.css */
.articleItem {
  @apply bg-white dark:bg-gray-800 rounded-xl p-6 shadow-md hover:shadow-lg transform transition-transform duration-200 ease-out;
}

// app/page.tsx
import styles from './styles/home.module.css';

<article className={styles.articleItem}>...</article>

优点：

样式作用域仅限当前组件/页面
不会被其他页面的同名类覆盖
维护简单，支持 Tailwind @apply

2. 避免自定义全局类名冲突

如果必须用全局 CSS，确保每个页面或组件的自定义类名唯一（如 .home-article-item、.category-article-item），避免不同页面间的类名复用。

3. 优先使用 Tailwind 原子类

对于简单样式，直接在 JSX 中写 Tailwind 原子类，减少自定义类名和外部 CSS 文件依赖。

<article className="bg-white dark:bg-gray-800 rounded-xl p-6 shadow-md hover:shadow-lg transition-transform duration-200">

4. 页面卸载时清理动态注入的样式（不推荐，复杂且易出错）

理论上可以在页面卸载时手动移除对应的 style 标签，但实际开发中不推荐，维护成本高且易引发副作用。

总结

本质问题是全局 CSS 类名冲突。在 Next.js App Router 架构下，页面切换不会自动卸载前一页面的 CSS，导致同名类样式互相污染。最佳实践是使用 CSS Modules 或唯一命名的全局类名，彻底隔离页面样式。对于简单场景，直接用 Tailwind 原子类最省心。