我在把一组 HTML 模板接进批处理接口时，最先遇到的不是语法问题，而是两个生命周期问题：用户输入应该交给谁转义，以及模板和缓冲区应该复用到什么程度。这个场景的直接答案是：HTML 页面使用 html/template，让它根据插值所在的上下文自动转义；模板在启动阶段解析一次，批处理时用 ExecuteTemplate 写入可复用的 bytes.Buffer。

官方地址：https://pkg.go.dev/html/template

下面的小项目只处理一个明确任务：把不可信的姓名和链接参数放进页面，并在批量渲染时避免每条记录都重新解析模板。它不把 template.HTML 当成“万能免转义开关”，也不以未经测量的数字宣称优化幅度。

项目目标：安全输出和批处理性能同时落地

html/template 的关键能力是上下文自动转义。同一个 {{.Value}} 放在普通文本、属性或链接上下文中，处理方式并不完全相同；模板包会把必要的转义阶段加入模板执行过程。输入值不应该先由业务代码拼接成 HTML 字符串，更不要为了让标签“生效”就随意转换成 template.HTML。

性能部分也有一个容易被忽略的边界：解析模板是准备工作，执行模板才是批处理循环中的重复动作。把 ParseFS 放在每次请求里，会把不必要的解析和分配带进热点路径。

环境准备：用 embed.FS 固定模板生命周期

先在项目中放一个 templates/page.html。模板只保留页面结构和数据插值，数据仍由 Go 结构体提供：

  
你好，{{.Name}}
  查看资料

启动阶段解析嵌入文件。解析失败属于配置错误，应该尽早返回，而不是等到第一条业务数据到来才发现：

package main

import (
	"embed"
	"html/template"
)

//go:embed templates/*.html
var templateFiles embed.FS

var pageTemplates = template.Must(
	// ParseFS 只负责准备模板，避免批处理循环反复解析文件。
	template.New("pages").ParseFS(templateFiles, "templates/*.html"),
)

如果项目需要把模板放到外部文件系统，也可以在启动时调用 template.ParseFiles 或 ParseGlob。重点不是选择哪一种来源，而是把解析动作放在稳定的初始化阶段。

核心代码：让自动转义接管不可信输入

下面把用户输入直接作为数据交给模板。文本中的尖括号会被转成安全的 HTML 实体，链接属性也由 html/template 按属性上下文处理。示例保留错误返回值，避免把渲染失败误当成空页面：

type Profile struct {
	Name       string
	ProfileURL string
}

func renderProfile(w io.Writer, data Profile) error {
	// ExecuteTemplate 按名称执行已解析模板，数据仍保持为普通字符串。
	return pageTemplates.ExecuteTemplate(w, "page.html", data)
}

func handler(w http.ResponseWriter, r *http.Request) {
	data := Profile{
		// 这里模拟来自请求的输入，真实项目应先做业务层面的长度和格式限制。
		Name:       r.URL.Query().Get("name"),
		ProfileURL: r.URL.Query().Get("next"),
	}
	if err := renderProfile(w, data); err != nil {
		// 模板执行失败时返回服务端错误，不继续写入不完整响应。
		http.Error(w, "模板渲染失败", http.StatusInternalServerError)
	}
}

这里的“自动转义”不等于“所有业务输入都合法”。长度、格式、权限和允许的跳转范围仍应由业务代码决定；模板包负责的是把数据安全地嵌入 HTML 文档上下文。只有确实掌握来源和内容安全边界时，才考虑使用 template.HTML 等安全类型。

本地运行：在批处理循环里复用模板和缓冲区

如果一次要渲染很多条记录，可以复用模板对象，并让每一轮重新使用同一个缓冲区。Reset 会清空已写入内容，但不会把缓冲区对象本身丢掉；输出需要在下一轮复用前复制或发送出去：

func renderBatch(w io.Writer, rows []Profile) error {
	var buf bytes.Buffer
	for _, row := range rows {
		buf.Reset()
		// 每轮都复用已解析模板和缓冲区，避免重复构造模板对象。
		if err := pageTemplates.ExecuteTemplate(&buf, "page.html", row); err != nil {
			return fmt.Errorf("渲染 %q 失败: %w", row.Name, err)
		}
		// 写出后再进入下一轮；如果异步发送，必须先复制这段内容。
		if _, err := w.Write(buf.Bytes()); err != nil {
			return fmt.Errorf("写入 %q 失败: %w", row.Name, err)
		}
	}
	return nil
}

若输出目标是 http.ResponseWriter，通常不需要先把完整页面缓存到内存；可以直接执行到响应写入器。若必须先做统一响应封装，再使用缓冲区。优化目标是减少无意义的对象创建，而不是为了“复用”把一个缓冲区跨 goroutine 共享。

集成与验收：把安全边界和资源边界分开

1. 确认模板已经在初始化阶段解析，解析错误会让服务启动失败或被明确记录。
2. 确认用户输入仍是普通 string，没有通过字符串拼接生成 HTML。
3. 确认文本、属性和 URL 场景都由 html/template 处理，业务层另行限制长度、权限和跳转范围。
4. 确认循环中的缓冲区在写出后才 Reset，异步场景不会持有下一轮会被复用的底层数组。
5. 确认每次 ExecuteTemplate 的错误都被处理；需要吞吐优化时，再用基准测试比较分配和耗时。

我最后保留的判断很简单：安全性来自正确的模板包和正确的数据类型，批处理性能来自稳定的模板生命周期与可控的缓冲区生命周期。两者可以同时做到，但不能把“复用对象”误写成“共享可变状态”。

相关问题

为什么不用 text/template 生成 HTML？

text/template 不提供面向 HTML 上下文的自动转义。输出 HTML 页面时应优先使用 html/template，让模板语义参与转义。

模板对象可以被多个请求并发执行吗？

模板解析完成后，可以并发执行；不要在执行期间继续修改模板定义，也不要把同一个可复用缓冲区交给多个 goroutine。

用了 bytes.Buffer 就一定更快吗？

不一定。它只是减少了反复创建缓冲区的机会；最终应结合真实数据规模、输出目标和基准测试判断，不能只凭代码外观下结论。