资产表不应默认加软删除字段；应依业务选硬删除+归档表、status字段或deleted_at，GORM映射须用struct tag显式声明，主键、时间字段、关联查询、JSON字段均需按规范设计。
资产表该不该加软删除字段
绝大多数人一上来就加 deleted_at，结果后期查数据总漏掉已删除资产，连带影响折旧计算和导出报表。软删除不是默认选项，而是要权衡的取舍。
真实场景里，资产一旦报废或调拨出系统，后续绝少恢复；但审计要求保留完整生命周期记录。这时候硬删除+归档表更稳。
- 如果业务明确允许“误删恢复”，且前端频繁做“回收站”操作，才用
deleted_at+ 全局查询加WHERE deleted_at IS NULL - 否则直接用
status字段（值为"active"/"retired"/"transferred"），语义清晰、索引友好、JOIN 不易出错 - GORM 默认会把
deleted_at当成软删除标志，哪怕你没调用Unscoped()，Find()也会自动过滤——这点常被忽略，导致后台管理页查不到历史数据
用 struct tag 控制 GORM 映射比手写 SQL 更可靠
很多人图省事，在 CreateTable 时直接拼 SQL 建字段，结果字段名大小写、下划线规则和 Go struct 对不上，GORM 自动绑定就失效，Save() 后数据库没更新也不报错。
正确做法是统一靠 struct tag 管理映射，让 GORM 自己生成建表语句，省去手动同步成本。
立即学习“go语言免费学习笔记（深入）”；
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
gorm:"column:asset_code;type:varchar(32);not null"显式声明列名，避免 GORM 默认的asset_code→asset_code猜测逻辑出错 - 主键必须显式标注
gorm:"primaryKey"，尤其当字段名不是ID（比如用asset_id）时，否则 GORM 会建一个隐式自增id字段 - 时间字段用
gorm:"autoCreateTime;autoUpdateTime"，别自己写CreatedAt赋值逻辑，否则并发插入可能踩时区或精度坑
关联查询用 Preload 而不是 Joins，除非真要 WHERE 条件跨表
查一台服务器资产时顺带加载所属部门、管理员、采购订单，用 Joins 写法看似一条 SQL 解决，但实际极易翻车：重复数据、COUNT 错误、NULL 字段被覆盖。
Preload 是 GORM 推荐的 N+1 优化方案，它分两步走，语义干净、结果可控。
-
db.Preload("Department").Preload("Owner").First(&asset)会发两条 SQL，但结构体字段填充准确，Department.Name不会因 JOIN 为空而丢值 - 只有当你需要类似 “查所有归属研发部的服务器” 这种跨表过滤时，才用
Joins("JOIN departments ON assets.dept_id = departments.id").Where("departments.name = ?", "RD") - 别在
Preload里套Where做条件过滤（如Preload("Logs", func(db *gorm.DB) *gorm.DB { return db.Where("status = ?", "success") })），这在 GORM v1.24+ 才稳定支持，低版本会静默失效
JSON 字段存扩展属性，但别放高频查询字段
资产类型五花八门：服务器有 CPU 型号，显示器有分辨率，工位有电源插座数量。全拆成独立字段？维护爆炸。全塞 extra JSONB？查起来慢还难索引。
折中方案是：固定属性走常规字段，动态/稀疏/低频字段走 JSON，且只在 PostgreSQL 上用 JSONB，MySQL 的 JSON 类型不支持高效路径查询。
- PostgreSQL 示例：
extra jsonb gorm:"type:jsonb"，然后用db.Where("extra @> ?::jsonb", `{"os": "linux"}`)查 Linux 服务器 - MySQL 如果非用不可，至少把常用键抽出来建生成列 + 索引，比如
os_version VARCHAR(32) AS (JSON_UNQUOTE(JSON_EXTRACT(extra, '$.os'))) - 绝对不要把
purchase_date、price这类必查字段塞进 JSON，否则连ORDER BY都得写函数，性能直线下滑
模型不是越通用越好，字段粒度卡在“变更频率”和“查询强度”的交界上，才是最不容易返工的设计点。
