在go中使用`html/template`设置自定义分隔符（如`{[{`和`}]} `）后调用`parsefiles`，若未正确指定模板名称或执行方式，会导致`nil pointer dereference` panic；根本原因是模板树中存在命名不一致的空模板，`execute()`误操作了未初始化的模板节点。
当您通过 template.New("test").Delims("{[{", "}]}") 创建模板时，实际生成了一个名称为 "test"、但内容为空的根模板（即“模板定义”），而后续调用 ParseFiles("index.html") 会解析文件并创建一个新模板，其名称默认为文件名 "index.html"，并将其加入该模板树中。
此时模板树结构如下：
- 根模板："test"（已设置自定义分隔符，但未解析任何内容 → 内部 *parse.Tree 为 nil）
- 子模板："index.html"（已成功解析，包含有效语法树）
问题就出在 sherrifTmpl.Execute(w, r) —— 它尝试执行的是根模板 "test"，而非刚解析的 "index.html" 模板。由于 "test" 模板从未被解析，其内部 t.escape() 所依赖的 t.text 和 t.tree 均为 nil，最终在 template.go:59 触发空指针解引用 panic。
✅ 正确做法有两种（任选其一）：
方案一：统一模板名称（推荐）
让根模板名称与 HTML 文件名一致，确保 ParseFiles 解析结果直接挂载到可执行的根模板上：
package main
import (
"html/template"
"net/http"
)
// 名称必须与待解析文件名一致（或至少是目标执行模板名）
var sherrifTmpl = template.Must(
template.New("index.html").Delims("{[{", "}]}").ParseFiles("index.html"),
)
func serveHome(w http.ResponseWriter, r *http.Request) {
err := sherrifTmpl.Execute(w, r)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
}✅ 优势：语义清晰，Execute() 直接作用于已解析的主模板，无需额外指定名称。
方案二：显式执行指定子模板
保留 "test" 作为根模板名，但改用 ExecuteTemplate 并传入具体模板名：
func serveHome(w http.ResponseWriter, r *http.Request) {
t, err := sherrifTmpl.ParseFiles("index.html")
if err != nil {
http.Error(w, "Parse error: "+err.Error(), http.StatusInternalServerError)
return
}
// 显式执行名为 "index.html" 的子模板
err = t.ExecuteTemplate(w, "index.html", r)
if err != nil {
http.Error(w, err.Error(), http.StatusInternalServerError)
return
}
}⚠️ 注意：ExecuteTemplate 的第二个参数必须是模板树中存在的确切名称（即文件名，不含路径），例如 "index.html"，而非 "test"。
补充说明与最佳实践
- 不要混用 template.New() 和 template.ParseFiles() 的返回值：ParseFiles 返回的是 同一个模板对象（链式调用），但它只是将新模板加入树中，并不改变当前接收者（"test"）的执行目标。
- Go 1.5+ 已修复此 panic：旧版本（如 Go 1.4）中 Execute() 对未解析模板的处理不健壮，新版已改为返回明确错误（如 "template: \"test\": nil data"），不再 panic。
-
调试建议：可通过 t.Templates() 查看当前模板树中所有命名模板，验证是否包含预期名称：
for _, t := range sherrifTmpl.Templates() { log.Printf("Loaded template: %q", t.Name()) }
遵循上述任一方案，即可安全启用自定义 delimiters，同时避免运行时崩溃。
