Gin的BindJSON返回400错误主因是结构体字段未导出（首字母小写）或缺失json标签，而非JSON格式问题；需确保字段大写、带json:"xxx"标签，数字类型直接定义为float64/int，避免string中转。
为什么 Gin 的 BindJSON 在资产入库时总返回 400 错误
多数情况下不是数据格式问题，而是结构体字段没加 JSON 标签或类型不匹配。Gin 默认用 json.Unmarshal 解析，但会严格校验字段可导出性与标签一致性。
- 确保结构体字段首字母大写（否则不可导出，
BindJSON无法赋值） - 所有需要解析的字段必须带
json:"field_name"标签，例如AssetName string `json:"asset_name"` - 数字型字段（如资产价格、数量）别用
string接收再转——前端传"1200"会解包失败；直接定义为float64或int更稳妥 - 时间字段推荐用
time.Time+ 自定义绑定，或统一接收为字符串后手动解析，避免时区/格式歧义
如何用 gin.Context 安全获取并校验资产编号（唯一键）
资产编号（如 ASSET-2024-0089）常作为业务主键，但不能只靠数据库唯一约束兜底——接口层就要拦截重复提交和非法格式。
- 在路由 handler 中先调
c.Param("id")或c.Query("asset_id")提取，再用正则快速过滤明显非法值：^ASSET-\d{4}-\d{4,6}$ - 查库前加缓存预检（如 Redis），键为
asset:id:ASSET-2024-0089，存在即拒绝，降低 DB 压力 - 注意：不要在
GET /assets/:id中直接用c.Param后就查库返回——得先校验该 ID 是否属于当前租户（多租户场景下极易漏掉）
gorm.Model 和手写 SQL 在资产状态批量更新时怎么选
固定资产管理中常有“批量报废”“统一转移部门”等操作，性能和事务安全是关键分歧点。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 用
db.Model(&Asset{}).Where("status = ? AND dept_id = ?", "in_use", 123).Updates(map[string]interface{}{"status": "scrapped", "updated_at": time.Now()})简单直接，但无法获取影响行数用于日志审计 - 手写原生 SQL（
db.Exec）可控性更强，比如加RETURNING id（PostgreSQL）或用ROW_COUNT()（MySQL），但要自己拼接条件防注入 - 更稳的做法是：小批量（500 条）改用分页 + 原生 SQL，且每批加
context.WithTimeout防止长事务锁表
为什么资产导出 Excel 接口响应慢还常超内存
不是因为用了 github.com/xuri/excelize/v2，而是默认把全部资产查出来再构建 Sheet——10 万条记录轻松吃光 1GB 内存。
立即学习“go语言免费学习笔记（深入）”；
- 必须流式处理：用
db.FindInBatches分批查（如每次 500 条），每批生成一行写入f.SetRow，然后f.WriteToBuffer直接 flush 到c.Writer - 禁止在内存里拼完整文件再
c.Data返回——Gin 的c.Header("Content-Disposition", "attachment; filename=assets.xlsx")配合流写才能压低延迟 - 额外提醒：Excel 单列宽度、日期格式、数字精度这些样式设置要在写入前一次性配置好，别边写边设，否则性能断崖下跌
