模板必须预编译，应用启动时一次性解析并缓存；避免handler中动态parse；数据需扁平化减少反射开销；静态内容可缓存渲染结果，动态内容应缓存模板与预处理数据。
模板字符串每次解析都慢，必须预编译
Go 的 template.Parse、template.ParseFiles 和 template.ParseGlob 是 CPU 密集操作，涉及词法分析、AST 构建、函数校验。高频渲染时若每次调用，QPS 上不去，CPU 会明显打满。
正确做法是：应用启动时一次性解析全部模板字符串，存为全局变量或结构体字段。用 template.Must 捕获解析失败，避免运行时 panic。
-
template.Must(template.New("email").Funcs(funcMap).Parse(emailTplStr))—— 字符串模板也支持预编译，不只限于文件 - 多个模板共用同一
*template.Template实例时，用tmpl.Clone()分离命名空间（仅当真需要隔离时才用，否则直接复用） - 避免在 handler 中写
template.New().Parse(...)，这是最常见性能雷区
缓存已编译模板，选 sync.Map 还是 map + sync.RWMutex？
sync.Map 适合读多写少、key 动态分散的场景（如按模板名查），但其遍历和类型断言开销略高；普通 map[string]*template.Template 配 sync.RWMutex 在初始化后只读、并发执行多的场景下更轻量、更可控。
实际建议：
- 启动时加载完毕后不再写入 → 用
sync.RWMutex+ 普通 map，Load走RLock，无额外分配 - 需支持运行时热更新（如开发环境）→ 才考虑
sync.Map，但注意Load返回interface{}，需类型断言 - 别用
map不加锁，Go 的 map 并发写 panic 是确定行为
动态模板字符串渲染还卡？检查这三处反射开销
即使模板已预编译，Execute 仍可能慢——问题常出在数据访问层。Go 模板执行时对字段访问、方法调用、index、slice 等操作依赖反射，尤其对嵌套结构体、接口、未导出字段。
- 避免模板里写
{{.User.Profile.Address.City}}这类深层链式访问；提前在 Go 层扁平化数据：City: user.Profile.Address.City - 不用
index .Items 0取首项，改用with .Items+{{.0}}或直接传入FirstItem - 模板内禁止调用耗时函数（如 DB 查询、HTTP 请求），自定义函数必须轻量、无副作用
缓存渲染结果比缓存模板更快？要看内容是否静态
对完全静态或低频变更的内容（如邮件模板、错误页、首页 banner），缓存 bytes.Buffer 输出比每次都 Execute 更快。但要注意失效边界。
- 缓存 key 应包含模板名 + 数据 hash（如
sha256.Sum256序列化后的摘要），而非简单拼接字符串 - 不要缓存含时间戳、用户 ID 等动态字段的完整输出；这类场景应缓存模板 + 预处理数据，而非最终 HTML
- 生产环境慎用 fsnotify 热重载模板——它引入 goroutine 和文件监听开销，且容易漏触发；重启才是可靠方案
Execute 耗时的关键。很多人花时间换引擎，却没动过一次 .User.Profile.Address.City 这样的写法。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
