golang原生不支持ssr，因其无js运行时，无法执行react/vue等框架的渲染逻辑；真正的ssr需node.js等具备js引擎的环境完成rendertostring，go仅适合作为bff代理或通过html/template实现预渲染+客户端hydrate。
为什么 Golang 原生不支持 SSR？
Go 的 net/http 和主流框架（如 gin、echo）本身只负责返回 HTML 字符串，不处理 JS 执行、DOM 渲染或客户端 hydration。所谓“SSR”，本质是服务端执行前端框架（如 React/Vue）的渲染逻辑，而 Go 没有内置 JS 运行时 —— 你不能直接在 http.HandlerFunc 里调用 ReactDOMServer.renderToString。
常见 SSR 架构选型：Go 做 BFF，Node.js 做渲染层
最稳妥的做法是把 SSR 逻辑剥离到独立 Node.js 服务，Go 作为后端 API 网关（BFF），按需代理渲染请求。这样避免在 Go 中嵌入 JS 引擎（如 otto 或 goja），它们不支持现代 ES 特性，也无法运行 React 18 的 renderToPipeableStream。
- Go 服务监听
/ssr/:path，转发请求到http://node-ssr:3000/render - Node.js 层接收数据（通过 query 或 body）、加载对应组件、调用
renderToString或renderToPipeableStream，返回 HTML +__NEXT_DATA__或window.__INITIAL_STATE__注入脚本 - Go 层只需拼接 HTML 模板，把注入脚本写入
<script></script>标签，不解析也不修改 JS 内容 - 注意：Node.js 渲染服务必须启用
sourceMap: false和dev: false，否则启动慢、内存泄漏风险高
如果坚持纯 Go 实现“类 SSR”：模板预渲染 + 客户端接管
这不是真正 SSR（无 JS 执行），但能解决首屏白屏和 SEO 基础需求，适合内容型站点（如文档、博客）。核心是用 html/template 或 gotpl 提前生成静态结构，再由前端框架挂载（hydrate）。
- Go 路由中用
template.ParseFiles("layout.html", "article.html")渲染带占位符的 HTML - 关键字段（如文章标题、摘要）从数据库查出后传入
template.Execute，确保 HTML 中已有文本内容 - 在页面末尾插入
<script>window.__INITIAL_DATA__ = <%= json.Marshal(data) %></script>，供前端 React/Vue 初始化时读取 - 前端入口必须调用
hydrateRoot（React 18）或createApp(...).mount()（Vue 3），且挂载容器要与服务端 DOM 结构完全一致，否则报错Hydration failed because the initial UI does not match what was rendered on the server
容易被忽略的细节：HTTP 缓存头与状态码
SSR 页面不是静态资源，但也不能每次都重新渲染。Go 层必须控制缓存策略，否则 CDN 或浏览器可能缓存错误状态。
- 动态页面（如用户个人页）设
w.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate") - 内容型页面（如博客文章）可设
"public, max-age=3600"，但需配合 ETag 或 Last-Modified 头做条件请求 - 渲染失败时，Node.js 渲染服务返回 500，Go 代理层不能吞掉它 —— 必须透传状态码，否则搜索引擎会把错误页当正常内容收录
- 404 页面必须由 Go 控制：先查数据库确认是否存在，不存在才返回
http.Error(w, "Not Found", http.StatusNotFound)，不能依赖 Node.js 渲染层返回 404（延迟高、不可靠）
真正 SSR 的复杂度不在 Go 代码本身，而在跨语言协作、hydration 一致性、缓存失效策略和错误边界隔离。别试图用 goja 跑 React —— 它连 Promise 都不完整实现。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
