在 Go 服务里展示 Markdown、富文本或后端提示时，最容易犯的错是把所有内容都当成 HTML。正确的做法是：用户输入继续使用普通 string，交给 html/template 按上下文自动转义；只有来源受控、经过明确 allowlist 的片段，才在渲染前转换为 template.HTML。这个类型不是“消毒器”，也不会替你判断内容是否可信。

先区分普通字符串和受信 HTML

html/template 默认假设模板作者可信，而 Execute 的数据参数不可信。它会根据变量出现的位置，分别处理文本、属性、URL、JavaScript 和 CSS 上下文。下面这个小项目同时渲染用户评论和后端固定提示，重点不是做富文本编辑器，而是把数据类型的边界写进代码。

package main

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

type PageData struct {
    Comment string
    Notice  template.HTML
}

func main() {
    const page = `
发布预览
  
评论：{{.Comment}}
  
`

    // 普通评论保持 string，让模板根据 HTML 文本上下文自动转义。
    data := PageData{
        Comment: ``,
        // 这里只放代码内固定的提示片段，不接收浏览器提交值。
        Notice: template.HTML(`审核提示：请先预览再发布`),
    }

    // 解析失败和输出失败都要返回，避免把半截 HTML 当成成功页面。
    tmpl, err := template.New("preview").Parse(page)
    if err != nil {
        log.Fatal(err)
    }
    if err := tmpl.Execute(os.Stdout, data); err != nil {
        log.Fatal(err)
    }
}

这个示例中，Comment 的尖括号会变成 HTML 实体，所以浏览器只显示文本；Notice 的 strong 和 em 标签保留。这里的“受信”来自代码内固定来源，而不是因为类型转换本身产生了安全性。

把受信边界收窄到渲染前

真实项目里，受信片段可能来自内部 Markdown 渲染器、固定邮件模板或后端维护的帮助文案。建议把流程拆成两个类型：外部内容先保留为字符串，经过允许标签和属性的 allowlist 处理后，再由一个命名清楚的函数构造 template.HTML。不要在控制器里看到字段名就直接强转。

func trustedNotice(source string) (template.HTML, error) {
    // 这里代表项目自己的 allowlist 结果；未通过审查就拒绝构造受信类型。
    if source != "release-note-v1" {
        return "", fmt.Errorf("notice source is not allowlisted")
    }
    // 受信片段来自固定后端文案，不把用户输入拼进 HTML。
    return template.HTML(`
本段来自内部发布说明。
`), nil
}

上面的函数故意没有伪装成通用清洗器。若来源是 Markdown 或富文本，应该选用经过评估的 allowlist 方案，并明确允许哪些标签、属性和 URL 协议；验证完成后再构造受信值。把 source 改成用户提交的 HTML 再强转，等于绕过了 html/template 最重要的保护。

运行检查要看什么

把代码保存为 main.go 后执行 go run .。验收不需要猜测：页面应显示一行普通评论文本，其中 不会被浏览器解释；内部提示仍显示粗体和斜体。若输出中出现未预期的标签，先检查数据是否被错误地转换成 template.HTML，再检查模板变量所在的上下文。

还要注意，html/template 的自动转义是上下文相关的。把普通字符串放入 href、事件属性或脚本代码时，仍要让模板知道它处于什么位置；不要用字符串拼接绕过模板，也不要因为某个 HTML 片段可信，就把同一变量复用到 URL 或 JavaScript 场景。

常见问题

template.HTML 能不能解决 XSS？

不能。它表达的是“调用方已经确认这段内容可作为 HTML”，会减少相应转义；如果内容来自用户，直接转换反而会绕过默认保护。

为什么普通字符串显示成了实体？

这是预期行为。html/template 把数据当作文本并按上下文编码，浏览器看到的是文字而不是标签。

HTML、URL 和 JavaScript 可以共用一个受信字段吗？

不建议。不同上下文的边界和允许字符不同，最好让字段类型和构造函数反映实际用途，避免一个“万能安全字符串”到处复用。

判断是否该使用 template.HTML，可以只问一句：这段内容是否经过了可说明、可复查、与业务绑定的 allowlist？如果答案不确定，就保留普通字符串，让模板继续自动转义。