Next.js 与 Go 分离架构:SSR、API、上传和内容渲染的边界
以当前博客为例,说明 Next.js 负责体验、Go 负责业务时,公开读取、后台写入和媒体上传应该如何分工。

前后端分离并不等于所有页面都在浏览器 fetch。内容站既需要 SEO 与首屏性能,也需要后台交互和独立 API。当前项目把公开读取放在 Next.js 服务端,把管理操作留在客户端,把内容规则收口到 Go。
公开页面
博客列表、文章详情、项目页、RSS 和 Sitemap 都从 Go API 获取已发布数据。Next.js 服务端直接请求后端,避免浏览器首屏等待,也不会把管理 Token 暴露到页面。
后台页面
登录后 Token 存在浏览器本地会话中,管理页面调用受保护的 API。文章和项目编辑器只提交结构化 JSON,不负责生成可信的 contentText 或版本号。
媒体上传
编辑器选择图片并检查大小与类型
浏览器把文件发送到 Go 上传接口
Go 生成存储路径并上传 MinIO
数据库只保存公开 URL
公开页面通过受控图片域展示资源
渲染安全
Tiptap JSON 不等于天然安全。后端限制节点和 mark,前端 Renderer 再限制链接协议与可渲染属性。两层校验分别保护数据入口和页面输出。
为什么保留 contentText
列表摘要不需要解析整棵 JSON
搜索可以针对普通文本建立索引
阅读时长无需依赖 HTML
后台可以快速比较内容是否为空
缓存策略
管理接口始终 no-store。公开列表和详情可以在内容发布后使用按需失效或短时间缓存,但缓存策略必须和发布动作绑定,不能让后台显示成功而前台长时间看不到更新。
部署关注点
NEXT_PUBLIC_API_BASE_URL 与服务端 API 地址分开配置
MinIO 公网域名与内部 endpoint 分离
CORS 只服务浏览器后台请求
健康检查覆盖前端、API、数据库和对象存储
Next.js 管理页面体验,Go 管理业务事实;结构化文档是两者之间稳定的契约。