Go模板不支持直接算术运算，需通过SetFuncMap注册add/sub/mul/div等float64函数并在模板中调用，且必须在LoadHTMLGlob前完成；复杂计算应前置到handler中。
Go 的 html/template 引擎本身不支持算术表达式，比如 {{ .A + .B }} 会直接报错：template: index.html:12: unexpected "+" in operand。这不是 Gin 的 bug，而是 Go 模板的设计原则：计算逻辑必须前置到 handler，模板只负责展示。真要算，得靠 SetFuncMap 注入函数，且必须在加载模板前完成。
必须在 r.LoadHTMLGlob() 之前调用 r.SetFuncMap()
顺序错了，函数在模板里就不可见——这是最常踩的坑。Gin 的模板引擎是 lazy 初始化的，LoadHTMLGlob 内部会创建并缓存 *template.Template 实例，之后再注册函数已无效。
-
SetFuncMap必须放在LoadHTMLGlob或LoadHTMLFiles之前 - 函数名首字母必须大写（Go 模板只识别导出函数）
- 参数和返回值类型要明确，推荐统一用
float64避免整数除法截断或类型不匹配 - 不要在函数里
panic或log，模板执行失败通常静默渲染为空值，很难调试
add/sub/mul/div 函数怎么写才安全
别用 int 或 interface{} 做参数类型，Go 模板传参时类型擦除严重，容易 panic。稳妥做法是全部收为 float64，让调用方自己做类型转换（比如 float64(.Score)）。
func add(a, b float64) float64 { return a + b }
func sub(a, b float64) float64 { return a - b }
func mul(a, b float64) float64 { return a * b }
func div(a, b float64) float64 {
if b == 0 {
return 0 // 不 panic，返回兜底值
}
return a / b
}
- 模板中调用：
{{ add (float64 .Price) (float64 .Tax) }} - 如果数据源是整型字段（如
Score int），必须显式转成float64，否则模板解析失败 -
div函数要处理除零，返回 0 比 panic 更友好
为什么复杂计算不该塞进模板里
模板里调用函数只是“取值”，不是“运算调度”。一旦涉及条件分支、循环聚合、数据库查询或外部 API 调用，性能和可维护性立刻崩坏。
- 比如「计算用户订单总金额」：应该在 handler 里用
for累加好，传TotalAmount float64进模板，而不是把切片和sum函数一起塞进去 - 模板函数无法访问
*gin.Context，拿不到 request header、session、db 实例等上下文 - 单元测试困难：你没法 mock 一个模板函数去验证它是否正确调用了 DB
- 同一份模板在不同 handler 复用时，计算逻辑可能不一致，导致视图行为飘忽
真正该塞进模板的，只有纯函数式、无副作用、输入确定输出就确定的操作，比如格式化时间、拼接字符串、四则运算。其余一律前置——这不是限制，是让代码边界更清晰的约束。
