一、先把普通文本交给 html/template

text/template 只负责把数据套进文本模板，本身不提供 HTML 自动转义；html/template 才是面向 HTML 的模板包。官方 html/template 文档还强调，它的转义是有上下文的：同一个值出现在正文文本、属性或 URI 中，处理方式并不相同。从数据进入模板上下文，到 HTML文本上下文和属性/URI上下文，再经过上下文转义，最后才形成浏览器文档片段。

例如昵称来自表单或数据库时，直接传入模板即可：

package main

import (
	"html/template"
	"log"
	"net/http"
)

var page = template.Must(template.New("page").Parse(`
欢迎，{{.Name}}
`))

func handler(w http.ResponseWriter, r *http.Request) {
	// 动态值保持普通字符串，不在进入模板前拼接 HTML 标签。
	data := struct{ Name string }{Name: r.URL.Query().Get("name")}
	if err := page.Execute(w, data); err != nil {
		// 输出失败要交给日志或错误页处理，不能继续拼接半截响应。
		log.Printf("execute template: %v", err)
	}
}

func main() {
	// 仅演示模板边界；生产服务还应配置超时和访问日志。
	http.HandleFunc("/", handler)
	log.Fatal(http.ListenAndServe(":8080", nil))
}

访问参数即使包含尖括号，也只会作为标题文字出现。这里的关键不是手动调用 HTMLEscapeString，而是让模板知道值所在的位置；重复手动转义反而可能造成双重编码。

二、把模板结构与动态数据分开

直接拼字符串的问题有两层。第一层是结构和数据混在一起，调用方很难判断一段内容到底是标签、属性值还是用户文字；第二层是同一个字符串可能被复用到不同上下文，手动替换几个字符并不能覆盖 URI 或脚本上下文。

更稳妥的写法是让模板保存固定结构，让数据对象只提供字段。属性值也直接写在引号内，避免让数据参与属性边界：

const tpl = `{{.Label}}`

func render(w io.Writer, query, label string) error {
	// Parse 只解析固定模板；query 和 label 都是待转义的数据。
	t, err := template.New("link").Parse(tpl)
	if err != nil {
		return err
	}
	// Execute 让 html/template 根据 href、title 和文本节点分别处理值。
	return t.Execute(w, struct {
		Query string
		Label string
	}{Query: query, Label: label})
}

当模板结构本身不完整、引号没有闭合，或分支让一个插值可能落入多种语境时，优先重构模板，而不是继续增加转义函数。模板解析阶段能发现的边界问题，应尽量在启动或测试时暴露。

三、template.HTML 只能接住已经确认的片段

有些页面确实需要输出有限的富文本，例如后台维护的说明片段。这时可以使用 template.HTML，但它表达的是“这段内容已经被确认可以作为 HTML”，而不是“这段字符串看起来像 HTML”。一旦把用户输入无条件转换成该类型，自动转义就失去了意义。实际设计时，要把用户输入、普通字符串、HTML 清洗器、可信来源、template.HTML、自动转义、原样片段和模板结果分开。

type Content struct {
	Title string
	Body  template.HTML
}

func makeContent(title string, cleaned []byte) Content {
	// cleaned 必须来自明确的可信来源或已完成策略审查的清洗器。
	return Content{Title: title, Body: template.HTML(cleaned)}
}

func renderContent(w io.Writer, c Content) error {
	// Title 仍是普通字符串；Body 才是经过边界确认的富文本。
	t := template.Must(template.New("content").Parse(`
{{.Title}}
{{.Body}}
`))
	return t.Execute(w, c)
}

不要用正则表达式临时删除几个危险标签就把结果标记为可信；清洗策略应由项目明确维护，并覆盖标签、属性、协议和未闭合结构等边界。若只是想显示尖括号，保留为普通 string 才是正确选择。

四、用四组输入做回归检查

模板改动后不必只看“页面能否打开”，应把同一字段放到实际使用的上下文中检查。至少准备以下输入：

• 文本：hello，预期显示为文字而不是新标签。
• 属性：包含双引号和空格的名称，预期不会跳出 title 引号。
• 查询参数：包含 & 和引号，预期链接仍是一个完整的 URI。
• 协议：把 javascript: 作为链接数据，预期被拒绝或变成安全占位，而不是可执行链接。

检查结果时要区分“转义正确”和“业务内容合法”。html/template 能保护模板边界，但不会替业务判断 Markdown、富文本或链接白名单；清洗与授权仍由应用负责。

相关问题

为什么不用 text/template 再手动转义？

手动转义容易漏掉属性、URI 等上下文。HTML 输出应直接使用 html/template，让模板包统一处理。

template.HTML 能不能修复显示不完整？

它只适合已经确认安全的 HTML 片段；显示普通尖括号时不要使用它，应继续传普通字符串。

模板变量来自数据库就一定可信吗？

不一定。数据库只是存储位置，数据仍可能由用户提交。是否能原样输出要看来源、清洗策略和字段契约。