直接用 text/template 就够了，无需封装引擎；其本身已是编译型、高性能核心，真实痛点在于路径定位、函数注册时机、字段导出和转义误用，而非解析能力。
直接用 text/template 就够了，不需要封装“引擎”——所谓“轻量级模板解析引擎”，本质就是对 Go 标准库的合理复用，而非另起炉灶。
为什么别自己造 template 引擎
Go 的 text/template 已经是编译型、无依赖、高性能的文本渲染核心。你写的“定制化引擎”大概率只是包了一层 template.New().Funcs().Parse()，反而增加错误入口和维护成本。真实痛点不在“解析”，而在：路径定位不准、函数注册时机错、数据结构字段未导出、HTML 转义误用。
- 所有“动态加载模板文件”的需求，用
template.ParseGlob("templates/**/*.tmpl")一次性搞定，不用每请求都os.Open+Parse - 所有“支持 YAML/JSON 输出”的需求，不是改引擎，而是用
yaml.Marshal或json.Marshal处理最终数据，再塞进模板（或干脆不走模板，直出） - 所谓“云厂商 KMS 解密函数”，只需注册一个
func(string) (string, error)到FuncMap，和引擎无关
text/template 渲染字符串时变量不替换？检查三件事
这是最常卡住人的点：模板写了 {{.Name}}，输出却是空或 {{.Name}} 字面量。
- 传入
Execute的数据必须是导出结构体（字段首字母大写）、map[string]interface{}，或单值（此时模板用{{.}}）；传struct{ name string }永远为空 -
template.Must(template.New("t").Parse(s))返回的是*template.Template，后续必须用它调用Execute；不能New一次、Parse一次、再拿另一个New去Execute - 如果模板来自字符串，确保
Parse成功且无语法错误；Must会 panic，但若你忽略 error，就会静默失败
想支持 {{.Data | toYAML}} 这类函数？注册时机比函数本身更重要
自定义函数不是写完就能用。它必须在 Parse 之前注册，且只对当前 *template.Template 实例生效。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 正确顺序：
t := template.New("").Funcs(yamlFuncs).Parse(tmplStr) - 错误写法：
t := template.New(""); t.Parse(tmplStr); t.Funcs(yamlFuncs)→ 函数根本没注册进去 - 函数签名必须是 Go 模板能识别的类型，例如：
func(interface{}) string或func([]byte) template.HTML；返回template.HTML只在html/template中有效，在text/template里会 panic - 别在函数里做 IO（如读文件、调 HTTP），模板函数应瞬时返回；复杂逻辑提前算好，再传入数据
生产环境模板路径总报 no such file or directory？别信相对路径
Go 进程的工作目录（os.Getwd()）和代码位置无关，二进制挪个位置就崩。硬写 "templates/layout.tmpl" 是定时炸弹。
- 安全做法：用
os.Executable()定位二进制位置，再拼路径：filepath.Join(filepath.Dir(execPath), "templates", "main.tmpl") - 开发期可临时
os.Chdir切到项目根，但上线前必须删掉 - 用
template.ParseGlob("templates/**/*.tmpl")时，glob 路径也得基于可执行文件所在目录，不是源码目录 - 加载失败不会自动跳过，
ParseFiles遇到任一文件缺失就返回 error；别假设“缺一个没关系”
真正需要定制的，从来不是“怎么解析模板”，而是“怎么把数据准备好、怎么让函数安全可用、怎么让路径稳如磐石”。这些事做完，text/template 自己就是最轻、最可靠、最不给你添乱的“引擎”。
