html/template 不该用于前后端分离项目，因其本质是服务端渲染（SSR）工具，输出 HTML 字符串，与 Vue/React 的 DOM 操作逻辑冲突，会导致路由失效、状态割裂、调试困难和热更新失效；Go 在此类项目中应仅作 API 层，统一返回 JSON。
Go 语言模板引擎（html/template）在现代开发中已基本退出前后端分离项目的核心链路——它只适合 SSR 场景（如管理后台、邮件模板、静态页面生成），而你如果正在走「前端转 Go 全栈」路线，不该花时间深挖模板语法，更不该用它对接 Vue/React 前端。
为什么 html/template 不该用于前后端分离项目
它本质是服务端渲染（SSR）工具，输出 HTML 字符串，和前端框架的 DOM 操作逻辑冲突。强行混用会导致：
- 前端无法接管路由（
router.push失效，页面跳转变成整页刷新） - 状态管理割裂（Vue 的
ref/ React 的useState与 Go 模板变量无关联） - 调试困难（Chrome DevTools 看到的是 Go 渲染后的静态 HTML，不是组件树）
- 热更新失效（改了 Vue 组件，Go 模板不感知；改了 Go 模板，前端构建系统不触发）
前后端分离项目里，Go 应该只做 API 层
你的 Go 后端职责非常明确：接收 HTTP 请求、校验参数、查库/调中间件、返回 JSON。所有视图层交给前端。关键实操点：
- 用
Gin或echo路由，统一返回application/json，别写HTML响应 - 前端发请求时带
Content-Type: application/json，Go 用c.ShouldBindJSON(&req)解析 - 跨域必须配
CORS中间件（github.com/rs/cors或 Gin 内置gin-contrib/cors），否则浏览器直接拦截 - 错误响应也走 JSON：
{"code":400,"msg":"invalid email"}，前端统一用axios.interceptors.response处理
什么场景下才需要学 html/template
仅限以下真实需求，且优先级远低于 API 开发能力：
立即学习“go语言免费学习笔记（深入）”；
- 写内部运营后台（无复杂交互，纯表单+列表，不接 Vue）
- 生成带样式邮件（
text/html邮件正文，用template.ParseFiles加载 .html 文件） - 导出 PDF 报表（配合
go-wkhtmltopdf等库，先用模板生成 HTML 再转 PDF） - SEO 敏感型静态页（如企业官网首页，但更推荐用 Hugo/Jekyll 预生成）
真要用，记住两个坑：{{.Name}} 会自动 HTML 转义（防 XSS），但 {{.RawHTML|safe}} 才能插入未转义内容；template.FuncMap 可注入自定义函数，但别在里面写业务逻辑——它不是后端代码执行环境。
前端转 Go 的真实学习路径优先级
按投入产出比排序，别被“全栈”二字带偏：
- 第一周：
net/http+encoding/json写通一个增删改查接口，连上 MySQL（用database/sql就行，GORM可延后） - 第二周：用
Gin重构路由，加cors和JWT中间件，前端用fetch调通登录流程 - 第三周：引入
Viper管理配置（config.yaml），把 DB 地址、JWT 密钥从硬编码移出 - 之后再碰
html/template—— 它不是门槛，是特定场景的补丁
模板引擎本身很简单，难的是判断什么时候不该用它。前端人容易下意识复用“模板渲染”思维，但 Go 在前后端分离架构里，角色就是 JSON 提供器。这点没转过来，后面学 Docker、K8s 都会卡在职责错位上。
