RSC输出的HTML默认未压缩，因压缩由反向代理接管且需显式配置Content-Encoding与Vary头；流式响应下Next.js构建配置无效，须用middleware或自建server配合CompressionStream/zlib实现流式压缩。
React Server Components 输出的 HTML 为什么没压缩？
默认情况下，RSC（通过 Next.js App Router 或类似框架）生成的 HTML 不会自动启用 gzip/brotli 压缩，哪怕你开了 output: 'standalone' 或部署在 Vercel。这不是 React 的 bug，而是服务端渲染链路中压缩通常由反向代理（如 Nginx、Cloudflare、Vercel Edge）接管——但它们只对明确标记为可压缩的响应生效。
常见现象：curl -I https://yoursite.com 返回里没有 content-encoding: gzip，HTML 文件体积比本地 npx html-minifier 处理后大 30%～50%。
- Next.js 默认不设置
Content-Encoding，也不修改Content-Type的charset声明，导致边缘缓存跳过压缩逻辑 -
headers配置（next.config.js）对 RSC 渲染的流式 HTML 无效，因为那是 runtime 动态生成的，不是静态资产 - Vercel 环境下必须显式开启
compression: true在vercel.json中，且仅对非流式响应生效；RSC 的text/html; charset=utf-8流式响应需额外声明Vary: Accept-Encoding
如何让 RSC 输出的 HTML 被正确压缩并缓存？
核心是两件事：让运行时响应带上正确的 Content-Encoding 协商头，并确保中间层不破坏流式传输。Next.js 14+ 后，推荐用中间件（middleware.ts）拦截 HTML 响应流，而非改写构建配置。
- 在
middleware.ts中检查request.headers.get('accept-encoding')，若含gzip或br，则对response.body做流式压缩（用CompressionStreamAPI，非 Node.js 的 zlib） - 必须手动设置
response.headers.set('Content-Encoding', 'gzip')和response.headers.set('Vary', 'Accept-Encoding')，否则 CDN 不会区分存储压缩/未压缩版本 - 避免在中间件里调用
response.json()或response.text()，这会消费流，导致后续无法再 pipe —— RSC 的 body 是ReadableStream，只能 pipe 一次 - 若用自建 Node.js server（如 Express +
renderToPipeableStream），需用res.flushHeaders()配合zlib.createGzip()，且不能设Content-Length（流式响应本就不该有）
HTML 标签冗余和 hydration 冗余怎么删？
RSC 本身不生成客户端 JS，但 Next.js 默认仍注入 <script> 块用于 hydration 协调（如 __next 全局变量、router 初始化）。这些对纯静态 RSC 页面是累赘。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 确认组件真的无客户端交互：移除所有
'use client'，禁用useEffect/useState，然后在layout.tsx顶部加export const dynamic = 'force-static' - 在
next.config.js中设experimental.optimizeCss: true并配合swcMinify: true，能删掉 dev-only 的注释和调试属性（如data-reactroot） - 禁用自动脚本注入：在
next.config.js加output: 'export'（仅适用于完全静态站点），或用app/head.tsx覆盖默认<head>，手动剔除next/dist/compiled/react-dom/client.js相关 script 标签 - 注意：删 hydration 脚本后，
Link组件会退化为普通<a>，SPA 导航失效 —— 这不是 bug，是预期行为
字体、CSS 和资源加载时机怎么对齐 RSC 流式特性？
RSC 支持 renderToPipeableStream 分段输出 HTML，但默认 CSS-in-JS 库（如 Emotion、Styled Components）或 next/font 会在流结束前才注入 <style>，造成 FOUC 或阻塞首屏解析。
-
next/font的font-display: swap是默认值，但必须把inter等字体实例提前 import 到layout.tsx，否则 RSC runtime 无法在流开头就写入<link rel="stylesheet"> - 避免在 Server Component 内部动态
import()CSS 模块 —— 这会导致样式延迟注入，应提至 layout 或使用const styles = css\`...\`配合styled-jsx的global模式 - 关键 CSS 应内联：用
getServerSideProps已弃用，改用generateMetadata中的other: { 'critical-css': '<style>...' }，再在head.tsx中读取并插入<style>标签 - 第三方字体（如 Google Fonts）务必用
preconnect+preload，否则 RSC 流式输出中字体请求会卡在 HTML 解析完成之后
流式 HTML 的优化不是“多压几个字节”，而是让每个字节都出现在它该出现的时间点——压缩晚了，用户等；样式晚了，页面闪；脚本晚了，交互断。这些时间点在 RSC 下全由服务端调度，没法靠浏览器补救。
