beego 中需手动实现软删除：定义 int8 类型的 isdeleted 字段并正确映射，封装 queryseter 默认过滤 is_deleted=0，软删除/恢复均用 update 修改字段值，注意唯一索引冲突及历史数据初始化。
Beego 中如何定义软删除字段
Beego 本身不内置软删除机制，但通过 ORM 的 CreatedAt、UpdatedAt 和自定义字段可手动实现。关键是要在模型中显式声明一个逻辑删除标记字段（如 IsDeleted），并确保它被 ORM 正确识别为数据库列，而非忽略。
常见错误是直接用 bool 类型加 orm:"-" 标签跳过映射，导致查询时无法过滤；或者用 int 但未在 QuerySeter 中统一处理条件。
- 字段类型建议用
int8或int（MySQL 中对应TINYINT(1)或INT），避免 Go 的bool在部分驱动中映射异常 - 必须去掉
orm:"-"，改用orm:"column(is_deleted);type(tinyint);default(0)" - 如果使用时间戳标记删除（如
DeletedAt），字段类型应为*time.Time，且不要设auto_now_add或auto_now
Beego ORM 查询时自动排除已删除记录
Beego 没有全局作用域（scope）概念，所以“自动过滤”只能靠封装共用的 QuerySeter 构建逻辑。不能依赖中间件或钩子拦截所有 Read/QueryTable 调用——ORM 层不提供该钩子。
实际做法是：所有业务查询都应基于一个带默认条件的 QuerySeter 实例，而不是裸调 orm.QueryTable("user")。
- 定义一个封装函数，如
ActiveUsers() orm.QuerySeter，内部返回o.QueryTable(&User{}).Filter("is_deleted", 0) - 对关联查询（如
LoadRelated）也要单独处理，它不会继承主表的Filter条件 - 慎用
Raw查询：手写 SQL 时必须显式加WHERE is_deleted = 0，否则绕过软删除逻辑
Beego 中执行软删除和恢复操作
软删除不是 Delete，而是 Update；恢复也不是插入新记录，而是把标记改回未删除状态。Beego ORM 不提供类似 Laravel 的 restore() 方法，必须手动控制字段值。
典型错误是调用 o.Delete(&u) 后发现数据真没了——因为没重写删除逻辑，ORM 默认走物理删除。
- 软删除：用
o.Update(&u, "is_deleted")，前提是u.IsDeleted = 1已赋值 - 恢复删除：同理，设
u.IsDeleted = 0后调o.Update(&u, "is_deleted") - 批量操作需用
o.QueryTable("user").Filter("id__in", ids).Update(orm.Params{"is_deleted": 1})，避免 N+1 - 注意事务：若软删除需同步更新关联状态（如订单下商品库存释放），需用
o.Begin()包裹
Beego 软删除与原生 SQL / 数据库约束的冲突点
当数据库表已有唯一索引（如 UNIQUE(email)），软删除后重复插入同邮箱用户会报错——因为数据库仍视原记录为“存在”。这是应用层软删除无法绕开的底层限制。
解决思路不是 ORM 配置，而是调整数据库设计或应用逻辑：
- 将唯一约束改为联合索引：
UNIQUE(email, is_deleted)，允许同一邮箱多条记录，只要其中一条is_deleted=0 - 或在插入前先查
email是否存在且is_deleted = 0，而非依赖数据库报错兜底 - 如果用
DeletedAt *time.Time字段，可建函数索引（PostgreSQL）或生成列（MySQL 5.7+）来替代布尔标记，但 Beego ORM 对生成列支持有限，需手动管理
最易被忽略的是迁移脚本：新增 is_deleted 字段后，必须补全历史数据的默认值（UPDATE user SET is_deleted = 0 WHERE is_deleted IS NULL），否则 ORM 查询可能因 NULL 值不匹配 = 0 条件而漏数据。
