应使用 {{ printf "%.2f" .Price }} 格式化浮点金额，确保两位小数且兼容负数；需在 handler 中校验 .Price 为有效 float64，避免 nil 或字符串导致 panic；金额宜用整数（分）存储以规避 float64 精度问题。
模板里用 printf 控制浮点数小数位数
Gin 默认使用 Go 的 html/template，不支持像 JavaScript 那样链式调用或内置货币过滤器，金额格式化得靠 printf。最常见需求是保留两位小数（如 199.90），但直接写 {{ .Price }} 可能输出 199.9 或科学计数法，尤其当值来自 float64 且精度丢失时。
实操建议：
- 用
{{ printf "%.2f" .Price }}强制保留两位小数，这是最直接、最可控的方式 - 如果金额可能为负，
%.2f仍能正确输出-199.90，无需额外判断符号 - 避免用
{{ .Price | printf "%.2f" }}—— 虽然语法合法，但 Gin 模板中管道符对函数调用支持有限，某些旧版本会 panic - 注意：如果
.Price是nil或非数值类型（比如 string），printf会报错can't print nil或invalid value for printf，务必在 handler 中确保传入的是有效 float64
需要千分位分隔符？得自己写 template func
Go 标准 printf 不支持 %,.2f 这类带逗号的格式（它只认 C 风格，不支持 locale 感知的分隔符）。想输出 1,234,567.89，必须注册自定义函数。
实操建议：
- 在 Gin 启动时注册：
func formatCurrency(v float64) string { return fmt.Sprintf("%d.%02d", int64(v), int64((v-float64(int64(v)))*100)%100) }——但这手动拆解易出错（比如负数、边界值0.999） - 更稳妥的做法是用
golang.org/x/text/message+Number，但需在 handler 中格式化好再传入模板，避免在模板里调用复杂逻辑 - 简单项目可接受近似方案：
{{ printf "%[1]d.%[2]02d" (int64 .Price) (int64 ((.Price - float64(int64 .Price)) * 100) % 100) }}，但仅适用于非负、小数部分稳定为两位的场景
为什么不能依赖前端 JS 补救？
有人想“后端随便传，JS 用 toLocaleString 格式化”，这在 SSR 场景下会出问题：Gin 模板渲染是服务端同步完成的，若金额字段被 JS 改写，SEO 抓取到的就是原始未格式化的数字（如 199.9），且首屏内容闪烁明显。
实操建议：
- SSR 页面必须在模板层完成基础格式化（至少
%.2f），保证 HTML 输出即正确 - 若需动态更新（如购物车实时计算），再用 JS 处理，但初始值仍应由后端提供已格式化的字符串字段（如
PriceFmt），而非原始Price - 注意 JSON API 和 HTML 模板分离：API 返回
price: 199.9是合理的，但模板渲染页不应依赖前端二次加工
容易忽略的精度陷阱
float64 本身无法精确表示 0.1 这类十进制小数，199.9 实际存储可能是 199.89999999999998，printf "%.2f" 会四舍五入成 199.90，看似正常，但若业务要求严格截断（如手续费计算），这个“四舍”就成 bug。
实操建议：
- 金额字段优先用整数（单位：分）存数据库和传结构体，模板里除以 100.0 再
printf "%.2f"，能彻底规避浮点误差 - 若必须用 float64，且需截断而非四舍，改用
math.Floor(.Price*100)/100计算后再传入模板，但该运算不能在模板里做（模板不支持math包） - 检查日志或 debug 输出
fmt.Printf("%b\n", .Price)，确认实际二进制值，比盲目调参更可靠
模板里格式化金额不是加个 printf 就完事，关键是选对数据类型、控制好四舍/截断逻辑、以及区分 SSR 和 CSR 的职责边界。最容易翻车的是把 float64 当精确小数用，又不在 handler 层做校验。
