Gin 模板中多个 {{if}} 按书写顺序从上到下依次求值，彼此独立；需用嵌套 {{if}} 实现条件依赖，且数据必须在传入前就绪，否则 panic。
template 本身不控制逻辑顺序——Gin 的 HTML 模板（基于 Go html/template）是纯渲染层，没有“条件执行顺序”的概念。你真正想控制的，是**模板中多个 {{if}} 块的求值时机、嵌套关系，以及它们依赖的数据是否已就绪**。
下面分几个真实场景说明怎么做、为什么、容易踩什么坑。
模板里写多个 {{if}}，谁先谁后？
按书写顺序从上到下依次求值，但它们彼此独立，不构成链式依赖。比如：
{{if .User}}<p>欢迎 {{.User.Name}}</p>{{end}}
{{if .Admin}}<p>管理员入口</p>{{end}}
{{if .FeatureFlag}}<p>新功能已开启</p>{{end}}
这三段只是顺序渲染，不会因为第一个 {{if}} 为 false 就跳过后面两个。但要注意：.User、.Admin、.FeatureFlag 必须在传入模板前已赋值，否则会 panic 或静默失败（取决于字段是否存在且可导出）。
常见错误现象：template: xxx:23:25: executing "xxx" at —— 根本原因是 {{if .User.Name}}: can't evaluate field Name in type nil.User 是 nil，却直接访问了 .Name。
- 安全写法：用
{{if .User}}{{.User.Name}}{{end}}或更稳妥的{{with .User}}{{.Name}}{{end}} - 别在模板里做复杂判断，比如
{{if and .User .Admin .FeatureFlag}}，可读性差、难调试、无法单元测试
需要“条件 A 成立才检查 B”，该怎么写？
必须用嵌套 {{if}}，不能靠并列顺序模拟依赖：
{{if .User}}
{{if .User.IsAdmin}}
{{if .User.FeatureFlags.EnableNewDashboard}}
<div>显示新版仪表盘</div>
{{else}}
<div>显示旧版仪表盘</div>
{{end}}
{{else}}
<div>普通用户界面</div>
{{end}}
{{else}}
<div>请登录</div>
{{end}}
这里外层 {{if .User}} 不成立，内层所有判断根本不会执行——这才是真正的“先后依赖”。Go 模板的 {{if}} 是短路求值，和 Go 代码里的 if 语义一致。
性能影响：嵌套层级过深会让模板难以维护，且每次渲染都要逐层判断；建议把组合逻辑提前收口到结构体方法里，例如：
type PageData struct {
User *User
}
func (p *PageData) ShouldShowNewDashboard() bool {
return p.User != nil && p.User.IsAdmin && p.User.FeatureFlags.EnableNewDashboard
}
然后模板里只写 {{if .ShouldShowNewDashboard}}，干净又可控。
为什么路由中间件顺序会影响模板变量可用性？
这不是模板的问题，而是数据注入时机问题。比如你写了：
r.Use(AuthMiddleware) // 设置 c.Set("user", u)
r.Use(FeatureFlagMiddleware) // 依赖 c.Get("user") 来查 flag
r.GET("/dashboard", func(c *gin.Context) {
c.HTML(200, "dashboard.html", gin.H{
"User": c.MustGet("user").(*User),
"FeatureFlag": c.MustGet("feature_flag"),
})
})
如果 FeatureFlagMiddleware 漏掉 c.Next()，或 AuthMiddleware 调用了 c.Abort() 且没设默认值，那 c.MustGet("user") 就 panic，根本到不了 c.HTML 这一步。
容易踩的坑：
- 中间件注册顺序写反了：比如
FeatureFlagMiddleware在AuthMiddleware前注册，c.Get("user")就是nil - 模板里直接调
{{.User.Name}}，但中间件没成功 set，也没 fallback 处理 - 用
c.MustGet却没确保 key 一定存在，线上直接 500
动态条件渲染时，要不要用 {{template}} 分块？
要。当多个并列条件对应不同 UI 片段（比如 tab 栏、权限按钮组），用 {{template}} + {{define}} 拆分比堆砌 {{if}} 更清晰：
{{template "header" .}}
{{template "sidebar" .}}
{{template "main" .}}
{{define "sidebar"}}
{{if .User.IsAdmin}}
{{template "admin-menu" .}}
{{else}}
{{template "user-menu" .}}
{{end}}
{{end}}
这样每个 {{template}} 是独立作用域，变量传递明确，也方便复用和测试。但注意：{{template}} 不会改变执行顺序，它只是把定义好的块插入当前位置——所以 {{define "admin-menu"}} 必须出现在使用它的 {{template}} 之前，否则报错 template: "admin-menu" is undefined。
关键点：模板解析是一次性的，{{define}} 必须前置声明；而 {{template}} 的执行顺序仍由其在主模板中的位置决定。
真正难的不是语法，是厘清「数据在哪一层准备好」——中间件负责注入，handler 负责裁剪，模板只负责忠实呈现。一旦把业务判断塞进模板，就等于放弃了编译期检查和可测试性。
