next.js + tailwind css 在 app router 下默认服务端渲染，样式类构建时提取并内联至 html 标签中；禁用 js 后样式仍存在即可验证，关键在 content 配置覆盖源码路径且 globals.css 由 layout.tsx 顶层导入。
Next.js + Tailwind CSS 默认就是服务端渲染，无需额外配置
只要项目是标准的 App Router（app/ 目录结构）且未显式禁用 SSR，Tailwind 的样式类在页面首次加载时就已内联到 HTML 中——这是 Next.js 服务端渲染的默认行为，不是靠 JS 注入或客户端 hydrate 实现的。
常见误解是以为需要手动“开启 SSR 支持”，其实 Tailwind 本身不区分 CSR/SSR；关键在于 Next.js 是否在服务端生成含样式的 HTML。验证方法很简单：禁用浏览器 JS 后刷新页面，如果样式仍在，说明 Tailwind 类已被服务端处理并注入 <style></style> 标签。
为什么 className 在服务端能生效？
因为 Tailwind 是一个构建时（build-time）CSS 工具，它通过扫描源码中的 className 字符串，提取出实际用到的类名，再生成精简的 CSS 文件。Next.js 的服务端渲染流程会把这份 CSS 内联进 HTML 的 中（或通过 cssBundleHref 引入），所以服务端不需要运行 Tailwind，只需要确保构建阶段能正确识别所有 className。
容易踩的坑包括：
- 动态拼接类名（如
className={`text-${size}-blue`}）会导致构建时无法静态分析，对应样式可能丢失 —— 必须用clsx或tailwind-merge配合 safelist - 组件定义在
node_modules或非app/、pages/目录下，会被 Tailwind 的content配置忽略，导致样式不生成 - 使用了
dangerouslySetInnerHTML插入含className的字符串，这类内容不会被扫描
如何确认 Tailwind 是否真正在服务端起作用？
打开 DevTools → Network → 刷新页面 → 找到 HTML 响应体，搜索 <style> 标签，里面应该包含类似 <code>.text-blue-500{--tw-text-opacity:1;color:rgb(59 130 246 / var(--tw-text-opacity))}</style> 的规则。如果只看到空的 <style></style> 或完全没这个标签，说明 Tailwind 没参与构建。
详细的 Three.js 3D 图形参考，涵盖场景设置、相机、几何体、材质、光照、动画、控制器、加载器、数学工具和调试。
检查点包括：
-
tailwind.config.js中的content是否覆盖了app/**/*.{js,ts,jsx,tsx}和components/**/*.{js,ts,jsx,tsx} - 是否误删了
app/layout.tsx里的或遗漏了inter.css等基础样式引入 - 是否启用了
experimental.optimizeCss（旧版 Next.js），该选项曾导致部分 class 被误删，现已被移除，不应再使用
动态主题或运行时切换暗色模式会影响 SSR 吗？
不影响初始 HTML 渲染，但会影响后续交互体验。Tailwind 的 dark: 变体默认依赖 class 切换（如 dark:bg-gray-800），而服务端无法知道用户偏好，所以通常初始渲染走 light 主题，再由客户端 JS 根据 prefers-color-scheme 或 localStorage 补上 dark class。
若想服务端也响应系统偏好，需在 app/layout.tsx 中读取请求头（如 Sec-CH-Prefers-Color-Scheme）或 cookie，但这属于边缘场景，且存在兼容性限制（Chrome 支持，Safari 不稳定）。更稳妥的做法是：服务端默认 light，客户端接管后立即同步一次 class，避免闪屏。
注意：dark: 类本身不增加 SSR 复杂度，真正复杂的是状态同步逻辑和 hydration 一致性 —— 这里最容易漏掉 useEffect 中的 class 设置，导致首屏和交互后样式不一致。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
