不该重写模板解析器，因text/template与html/template已高度优化，支持嵌套、管道、自定义函数等；手动实现易致安全漏洞、语法错误和作用域泄漏，而扩展FuncMap或使用Clone+Option即可满足定制需求。
Go 标准库的 text/template 和 html/template 已经足够健壮，绝大多数场景下不需要、也不建议从零手写模板引擎——它容易引入安全漏洞、性能问题和语法歧义。
为什么不该重写解析器：template.Parse 的底层已覆盖核心需求
标准模板引擎的解析阶段（词法分析 + 语法树构建）已被高度优化，支持嵌套结构、管道链、自定义函数、上下文隔离等。自行实现需处理：{{.Field}}、{{if .Cond}}{{end}}、{{range $k, $v := .Map}} 等语法的优先级与边界，稍有不慎就会出现未闭合标签、变量捕获错误或作用域泄漏。
- 比如手动解析
{{with .User}}{{.Name}}{{else}}Guest{{end}}，需维护嵌套深度栈和作用域快照，而template.New内部已用parse.Tree完整建模 - 标准库对
{{.}}的空值处理（nil map/slice → 空字符串）、HTML 自动转义、上下文感知（如在href="..."中自动做 URL 转义）都依赖预定义的 context mode，自研很难复现
真正需要“自定义”的地方：扩展 FuncMap 而非重写引擎
多数所谓“定制模板需求”，实际是添加业务函数，比如日期格式化、权限判断、i18n 翻译。这完全可通过 template.FuncMap 注入，无需碰解析逻辑。
示例：注册一个带时区的日期函数
funcMap := template.FuncMap{
"formatTime": func(t time.Time, layout, locName string) string {
loc, _ := time.LoadLocation(locName)
return t.In(loc).Format(layout)
},
}
t := template.New("page").Funcs(funcMap)
t, _ = t.Parse(`{{formatTime .CreatedAt "2006-01-02" "Asia/Shanghai"}}`)
- 所有传入
FuncMap的函数必须是可导出的（首字母大写），且参数/返回值类型需被模板引擎识别（如string、int、error） - 避免在函数中 panic；应返回
error并在模板里用{{if .Err}}{{.Err}}{{else}}{{.Result}}{{end}}处理 - 函数内不要直接操作
http.ResponseWriter或全局状态——模板应保持纯数据驱动
当真要替换渲染逻辑时：用 template.Clone + Option 控制行为
Go 1.22+ 支持 template.Option（如 template.WithContext），配合 Clone 可安全派生新模板实例，隔离不同环境的函数或配置，比硬编码新引擎更轻量。
- 例如为测试环境注入 mock 函数：
t.Clone().Funcs(testFuncs)，不影响主模板 - 使用
template.WithContext可将context.Context透传进自定义函数，用于超时控制或 trace ID 注入 - 注意
Clone不复制已解析的*parse.Tree，所以应在Parse后调用，否则会重复解析
真正难的是设计安全的函数边界和上下文生命周期管理——比如一个 dbQuery 模板函数，如何防止 N+1 查询、连接泄漏或 SQL 注入？这些问题不在模板引擎层解决，而在函数实现和调用约定里约束。
