支持“局部同构刷新”的Web架构核心是渲染职责的精细切分：首屏关键内容（如标题、摘要、正文前300字）必须服务端直出以保障SEO；局部刷新组件需严格水合，props与key须100%一致，并通过__INITIAL_DATA__注入；客户端仅接管交互衍生数据，且须提供服务端fallback。
设计支持“局部同构刷新”的 Web 架构，核心不是堆砌技术，而是明确“哪些内容必须服务端直出、哪些可以客户端接管、边界如何不被破坏”。它本质是渲染职责的精细切分，而非单纯引入 SSR 或 CSR 工具链。
首屏关键内容必须由服务端完整输出
搜索引擎爬虫不执行 JavaScript，也不等待异步加载。任何依赖 useEffect、React.lazy、Suspense 或客户端数据请求（如 useSWR）才出现的标题、正文、导航链接、结构化数据（JSON-LD），都会直接丢失 SEO 权重。
- 文章页的标题、摘要、发布时间、作者、正文前 300 字，必须在服务端 HTML 中以纯文本形式存在
- 禁止用空 div 或 loading 占位符代替真实内容；fallback 不等于无内容
- 动态修改 document.title 应替换为服务端模板变量或框架的
setHeadAPI 静态注入
局部刷新区域需满足严格水合前提
所谓“局部”，是指一个服务端可预测、客户端可精确匹配的 DOM 子树。一旦 mismatch，React 会丢弃服务端 HTML、重新创建节点——SEO 内容消失、样式闪动、事件绑定失效。
- 每个可刷新组件必须有稳定 key，如
key={post.id}，禁用Math.random()或数组索引 - 服务端传给该组件的 props（含
null/undefined）必须与客户端初始 props 100% 一致；推荐通过window.__INITIAL_DATA__内联 JSON 注入 - 避免全局状态（如 Zustand store）直接驱动局部刷新，除非该状态的初始值已由服务端同步提供
客户端接管必须显式可控、可观测
Next.js 的 "use client" 或 Remix 的 clientLoader 不代表自动安全。水合失败常静默降级为纯 CSR，而你无法感知哪块内容已脱离 SEO 覆盖。
- 为每个启用局部刷新的组件包裹
<ErrorBoundary fallback=<div aria-live="polite">加载失败</div>> - 在服务端响应头或日志中明确标记“此页面含可水合区块：/comments、/related-posts”，用于线上监控 mismatch 率
- 可加轻量级 hydration 检查逻辑，例如
useEffect(() => { console.log('hydrated:', document.getElementById('comments')?.hasAttribute('data-reactroot')) })
数据获取策略要分层设计
服务端负责首屏必需数据，客户端负责交互衍生数据。两者不能混用同一套异步逻辑，否则极易引发状态漂移和 hydration 错位。
- 服务端使用
getServerSideProps（Next.js）或loader（Remix）预取首屏数据，并确保返回值可序列化、无副作用 - 评论区、相关推荐等非首屏区块，若需局部刷新，应由客户端发起 fetch，但必须提供服务端提供的 fallback 内容（如默认 3 条静态评论）
- 禁用客户端“先清空再渲染”模式；局部更新应基于已有 DOM 增量 patch，而非 replaceChild
