text/template 中必须用 eq 而非 ==，因为解析器不识别 == 为运算符，会报错“function "==" not defined”；所有比较需调用内置函数如 eq、ne、lt 等，且不自动处理 nil，须用 with 或分层判断规避 panic。
text/template 里为什么不能用 == 而必须用 eq？
因为 text/template 解析器压根不认识 == 这种运算符——它不是语法的一部分。模板解析阶段就会报错：function "==" not defined。这不是限制，而是设计选择：Go 模板坚持函数式表达，所有逻辑都得显式调用内置函数。
这意味着你写 {{if .Status == "active"}} 会直接 panic，而 {{if eq .Status "active"}} 才是唯一合法写法。
-
eq支持多参数比较（{{if eq .A .B .C}}表示三者全等），但最常用的是二元形式 -
ne、lt、gt、le、ge同理，只接受可比较类型（数字、字符串、布尔、指针等） - 所有比较函数底层用
==或reflect.DeepEqual实现，行为和 Go 代码一致
嵌套字段比较时怎么避免 nil panic？
当你写 {{if eq .User.Profile.Role "admin"}}，如果 .User 是 nil 或 .User.Profile 是 nil，模板执行时会触发 invalid memory address or nil pointer dereference。
不能靠 eq 自动判空，它不处理路径安全。必须提前切断访问链：
立即学习“go语言免费学习笔记（深入）”；
- 用
{{with .User.Profile}}{{if eq .Role "admin"}}...{{end}}{{end}} - 或分层判断：
{{if .User}}{{if .User.Profile}}{{if eq .User.Profile.Role "admin"}}...{{end}}{{end}}{{end}} - 切片字段（如
.Orders）即使为nil，{{range .Orders}}也不会 panic，但eq .Orders nil无效——应改用{{if .Orders}}
and/or/eq 组合条件的常见陷阱
and 和 or 是短路求值，但它们的参数顺序和括号语义容易误读。比如 {{if and (eq .A "x") (eq .B "y") (eq .C "z")}} 看似清晰，但一旦中间某个表达式 panic（如 .B 是 nil），后续不会执行——但这不等于“安全”，只是没轮到它。
- 字符串字面量必须用双引号：
"active"✅，'active'❌（会被当 rune，类型不匹配） -
and的第一个 false 值即返回，不继续；or的第一个 true 值即返回 - 别试图写
{{if eq .A .B && eq .C .D}}——语法错误，&&不被识别 - 复杂条件建议拆成多个
with或提取到结构体方法中（如func (u User) IsAdmin() bool），再在模板里调用{{if .User.IsAdmin}}
渲染 XML 时比较函数要不要额外转义？
不需要。eq、ne 这类函数只做值比较，不碰输出内容，也不参与转义。XML 转义是另一条线：只有实际输出字段（如 {{.Content}}）才涉及是否逃逸。
所以你在 XML 模板里写 {{if eq .Type "article"}}<article>{{.Body}}</article>{{else}}<note>{{.Body}}</note>{{end}}，比较本身没问题，但 {{.Body}} 里的 、<code>& 会原样输出，破坏 XML 结构。
- 正确做法：把用户输入字段声明为
template.XML类型，或用xml.Marshal先序列化再注入 -
eq只管“是不是”，不管“输出来安不安全”——这是两个正交问题 - 别在模板里用
{{.Content | html}}，那是 HTML 转义，XML 解析器不认识<
真正容易被忽略的是：比较函数不解决数据安全，只解决逻辑分支；而 XML/HTML 安全得靠类型标记或预处理，不是靠 if 条件兜底。
