Go中string是值类型，永不为nil，仅可能为空字符串""；模板中{{if .Name}}等价于.Name != ""，而与nil比较会出错。
模板里直接判 "" 就行，别碰 nil
Go 的 string 是值类型，永远不可能是 nil，只可能是空字符串 ""。Gin 模板拿到的字段（比如 .Name）如果来自结构体绑定成功后的值，那它一定是合法的 string，最多为空。所以模板里写 {{if .Name}} 实际上是在判断是否非空——这没问题；但写 {{if ne .Name nil}} 或类似逻辑会报错或始终为 true，因为 nil 在模板中不适用于字符串。
{{if}} 对 string 的行为就是“非空即真”
Gin 使用的 Go html/template 对基本类型有明确规则：string、int、bool 等零值在 {{if}} 中自动视为 false，其余为 true。所以：
-
{{if .Name}}→ 等价于.Name != "" -
{{if not .Email}}→ 等价于.Email == "" -
{{if eq .Role "admin"}}→ 安全，无需担心.Role是nil
注意：前提是传入模板的数据结构字段是导出的（首字母大写），且不是 nil 指针。例如 type User struct { Name string } 没问题；但 Name *string 就可能为 nil，此时 {{if .Name}} 判的是指针是否非空，不是字符串内容。
需要区分“未提供”和“提供了空字符串”？别在模板里硬扛
模板层无法可靠分辨一个 string 字段是“没传”还是“传了空字符串”，因为 Gin 的 Bind 成功后，缺失字段会导致绑定失败并返回 error，根本不会走到模板渲染这步。所以：
- 若 API 设计允许空字符串，就用
string类型 +{{if .Field}}判非空 - 若必须区分“未提供”和“显式为空”，结构体字段得改用
*string，并在 handler 中显式检查nil后注入布尔标记（如.FieldProvided = field != nil），再传给模板 - 别指望在模板里调
reflect或自定义函数来绕过这个限制——既不可靠又难维护
容易踩的坑：传了 nil 指针进模板
最常见翻车点是 handler 里传了 nil 结构体指针给 c.HTML，比如：
var u *User c.HTML(200, "page.html", u)
这时模板里访问 {{.Name}} 会 panic：invalid memory address or nil pointer dereference。正确做法是确保传入非 nil 值：
- 用
&User{}而不是(*User)(nil) - 或提前判空：
if u == nil { u = &User{} } - 模板内防御性写法：
{{if .}}...{{end}}可防顶层nil，但不推荐依赖它掩盖数据准备问题
真正该花力气的地方，是 handler 中把数据准备好、校验好、补全默认值，而不是让模板承担类型安全和空值兜底的职责。
