Go 网页模板要显示用户输入，同时保留转义，直接选用 html/template，把输入保持为普通 string，再交给模板执行即可。不要用 text/template 生成 HTML，也不要为了“显示原样标签”把不可信内容转换成 template.HTML。前者缺少 HTML 上下文保护，后者会把信任边界交给调用方。

一、用 html/template 输出普通用户输入

先看一个评论预览场景。模板作者控制页面结构，Comment 来自请求参数，因此它应当只是数据，而不是一段待执行的 HTML。

package main

import (
    "html/template"
    "log"
    "os"
)

type Page struct {
    Comment string
}

func main() {
    const page = `
评论预览
{{.Comment}}
`
    tmpl, err := template.New("comment").Parse(page)
    if err != nil {
        log.Fatal(err)
    }
    data := Page{Comment: `请稍后联系我`}
    if err := tmpl.Execute(os.Stdout, data); err != nil {
        log.Fatal(err)
    }
}

这里的重点不是手动调用 HTMLEscapeString，而是让模板知道插值所在的 HTML 上下文。输出会把 和 > 编码成实体，浏览器展示的是带尖括号的文字，不会新增一个 em 元素。模板解析或执行出错时也要保留错误处理，避免把半截页面继续写给客户端。

二、同一个字段换位置，转义规则也会换

html/template 的价值在于上下文感知。一个值放进正文和放进链接参数，不应该使用同一种编码。下面的模板没有手写转义函数：

const page = `
{{.Label}}
查看结果`

data := struct {
    Label string
    Query string
}{
    Label: `新手 `,
    Query: `Go 模板 & 转义`,
}

Label 在 title 属性里需要处理引号等边界，在段落正文里则按 HTML 文本处理；Query 位于 URL 查询参数中，还需要进行 URL 语义上的编码。这个差异正是不要先把所有输入拼成“已转义字符串”的原因：调用方通常不知道最终插槽属于哪种上下文。

三、template.HTML 不是显示原样输入的快捷键

包里确实有 template.HTML 这类 typed string。它的语义是：调用方已经确认这段内容可以作为 HTML 结构使用。因此下面的转换只应出现在可信模板片段、经过专门清洗的结果或应用自身生成的固定片段上：

trusted := template.HTML(`系统提示`)
err := tmpl.Execute(w, trusted)

如果 trusted 的内容来自评论、昵称、Markdown 原文或管理员可编辑字段，就不该直接转换。更稳妥的边界是：外部输入先作为普通字符串保存；如果业务确实需要有限 HTML，则使用明确的白名单清洗流程，清洗结果再由专门代码封装为可信类型，并记录来源和规则。不要混用 text/template、手动拼接标签和多次转义，否则页面容易出现“看似安全但显示乱码”或属性边界失守。

四、提交前用四项清单复查

这样处理后，用户输入仍然能被页面看见，但不会因为它携带标签或引号就改变模板结构。所谓“保留转义”，不是让字符串永远保持某一套实体编码，而是让数据在最终输出位置使用匹配的编码规则。

相关问题

为什么不用 template.HTMLEscapeString 先处理一遍？

单独处理只知道字符串，不知道它最后会进入正文、属性还是 URL。优先让 html/template 在最终上下文中编码，避免重复转义或编码不足。

用户输入里真的需要显示

保持普通字符串并交给模板输出即可，页面会显示这段文字而不是执行它。不要为了显示尖括号而使用 template.HTML。

html/template 能替代所有富文本清洗吗？

不能。它负责模板输出时的上下文转义，不等于富文本白名单清洗；需要保留有限标签时仍要使用独立的清洗策略。