Go 的 html/template 和 text/template 都能解析模板、绑定数据、执行输出，API 看起来几乎一样，但选择标准很简单：最终结果会不会交给浏览器当 HTML 解析。会，就优先使用 html/template；只是邮件纯文本、配置文件、代码片段或日志，就使用 text/template。不要因为两者都能输出字符串，就把安全语义混在一起。

先按最终输出类型做选择

把“模板文件长什么样”放到第二位，先确认结果的消费者。浏览器会继续解析标签、属性和脚本上下文，因此页面渲染需要 html/template；命令行帮助、邮件正文、Markdown、SQL 模板或代码生成则通常只需要文本替换，可以使用 text/template。

这不是性能优先级，而是输出解释权的区别：HTML 输出中的同一个字符串，进入文本、属性、URL 或脚本上下文时，安全处理方式并不相同。

用同一份数据看自动转义差异

下面的例子把可能来自表单的内容同时交给两个模板。代码只演示选择依据，不把用户输入转换成可信 HTML。

package main

import (
    "os"
    htmltemplate "html/template"
    texttemplate "text/template"
)

func main() {
    // 这段字符串模拟未经过审核的用户输入。
    data := "你好"

    // HTML 页面使用 html/template，让数据按 HTML 上下文输出。
    htmlTmpl := htmltemplate.Must(htmltemplate.New("page").Parse("
{{.}}
"))
    _ = htmlTmpl.Execute(os.Stdout, data)

    // 纯文本输出使用 text/template，不承担 HTML 安全职责。
    textTmpl := texttemplate.Must(texttemplate.New("mail").Parse("内容：{{.}}\n"))
    _ = textTmpl.Execute(os.Stdout, data)
}

在真实 Go 源文件中，模板字符串应直接写成

{{.}}

可信片段要单独划边界

有些场景确实需要让一段经过审核的标签生效，例如后台维护的固定图标片段。这时不要把所有字段都改成可信类型，也不要把用户输入直接强转为 template.HTML。官方文档明确把这类类型定义为安全承诺，错误使用会让内容原样进入输出。

type ViewData struct {
    Title       string
    TrustedIcon htmltemplate.HTML
}

func render(w io.Writer, data ViewData) error {
    // Title 仍是普通字符串，会经过上下文转义。
    const page = `
{{.Title}}
{{.TrustedIcon}}
`
    tmpl, err := htmltemplate.New("page").Parse(page)
    if err != nil {
        return err
    }
    // TrustedIcon 只能来自固定白名单或可靠的 HTML 清洗结果。
    return tmpl.Execute(w, data)
}

更稳妥的设计是让“审核/清洗”发生在数据进入视图模型之前，并在字段命名上暴露责任。若片段来源不清楚，就保持 string，让 html/template 把它当普通数据处理。

把选择落到项目复查清单

代码评审时可以追问三件事：输出的最终消费者是谁？模板数据是否可能来自不可信输入？是否存在把普通字符串整体转换为可信类型的捷径？这三问比单看 import 名称更容易发现问题。

常见问题

html/template 能不能生成纯文本？

可以输出文本，但如果结果不是 HTML，选择它通常没有收益。按输出格式选包，能让代码意图更清楚。

text/template 能不能配合 HTML 转义函数？

可以自行调用转义函数，但上下文判断和维护责任都会落到业务代码。页面渲染优先使用 html/template 更稳妥。

把 string 转成 template.HTML 就能避免乱码吗？

这只是关闭一部分转义，不是修复乱码的方法。只有确定内容来自可信源或已经完成安全清洗时，才应使用这类类型。

最终记忆点只有一句：浏览器解析的 HTML 选 html/template，其他纯文本选 text/template；可信片段单独审核，不能靠强制类型转换越过边界。