组件级局部刷新的同构架构核心是划清服务端与客户端边界：服务端必须直出含完整seo内容的html，客户端仅接管明确标记的可水合子树；任何props、key或数据不一致都会导致hydration mismatch，破坏seo与交互。
组件级局部刷新的同构架构，本质不是加功能，而是划边界：服务端必须直出可被爬虫直接读取的 HTML 内容，客户端只接管那些明确标记为「可水合、可更新」的子树。任何模糊地带——比如用 useEffect 动态填充标题、用 Math.random() 当 key、或让服务端和客户端对同一组件传入不一致的 props——都会导致 hydration mismatch，进而让 SEO 内容被丢弃、样式闪动、事件丢失。
服务端必须直出首屏关键 HTML，且不可 defer
搜索引擎爬虫不执行 useEffect，不等待 Suspense，也不解析 React.lazy 加载的代码。所有影响 SEO 的内容（标题、摘要、主图 alt、结构化链接）必须在初始 HTML 字符串中完整存在。
- 禁止把文章正文包裹在
<suspense fallback="<div">Loading...></suspense>里——fallback 不是 SEO 内容，爬虫看到的就是空 div - 服务端渲染时，
document.title不能靠客户端 JS 设置；应通过模板变量或框架的setHeadAPI 在响应头或中静态注入 - 若使用 Next.js，确保
getServerSideProps或generateStaticParams返回的数据已覆盖首屏全部语义内容，而非仅返回骨架
每个局部刷新区域需有稳定 key 和严格一致的初始 props
React 水合时会逐节点比对服务端 HTML 和客户端虚拟 DOM。只要某个组件的 key 或初始 props 出现差异（哪怕 null vs undefined），就会触发整棵子树丢弃重建，SEO 内容随之失效。
-
key必须稳定可预测：用post.id、comment.slug等服务端可生成的字段，禁用index或Math.random() - 客户端读取的初始数据必须与服务端完全一致：推荐将服务端序列化的数据通过
window.__INITIAL_DATA__内联到 HTML，再由客户端 JSON.parse 读取，避免因类型转换（如字符串"123"vs 数字123）引发 mismatch - 避免用全局状态（如
zustandstore）驱动局部刷新，除非该 store 的初始值已在服务端同步注入并冻结
水合失败必须显式捕获，不能静默降级
Next.js 的 "use client" 或 Remix 的 clientLoader 不代表水合安全。hydration 错误默认不抛异常，React 会静默放弃服务端 HTML、重新挂载——你根本不知道哪块内容已经脱离 SEO 覆盖。
- 为每个启用局部刷新的组件包裹
<errorboundary fallback="<div" aria-live="polite">加载失败></errorboundary>，并在componentDidCatch或useEffect(() => { /* 检查 document.getElementById('xxx') 是否已存在且有 innerHTML */ })中做运行时验证 - 在服务端日志中明确标记响应是否含可水合区块，例如
log('SSR_RENDER', { path: req.url, hydratable: ['/comments', '/related-posts'] })，便于线上监控 mismatch 率 - 禁止在水合后立即调用
setState：首次渲染应完全基于服务端提供的 props，后续更新才由交互触发
真正难的不是写一个能局部刷新的组件，而是让服务端和客户端对「这个组件此刻该长什么样」达成 100% 共识。共识崩塌一次，SEO 就掉一截；而这种崩塌往往没有报错，只有一片安静的白屏或错位的 DOM。
