审核状态应使用独立字段（如status）存储，取值0=待审核、1=已通过、2=已驳回、3=已撤回；避免单布尔字段；建议搭配approved_at、approved_by、reject_reason等元信息字段，并为完整留痕增设audit_log表。
审核状态用独立字段存储最直观
在SQL内容审核类表中，建议直接增加一个 status 字段（如 TINYINT 或 VARCHAR），用于明确标识当前记录的审核状态。常见取值如：0=待审核、1=已通过、2=已驳回、3=已撤回。这种方式查询高效、逻辑清晰，应用层和数据库层都容易理解和维护。
避免用布尔字段硬编码审核逻辑
不要只用一个 is_approved（BOOLEAN）字段来表示“是否通过”。它无法区分“未提交审核”“审核中”“驳回后修改重提”等关键状态。实际业务中常需追踪全流程，单布尔值会迫使你在代码里加大量判断或额外字段补漏，反而增加复杂度。
必要时搭配审核元信息字段
除状态外，建议同步记录审核相关时间与人员，例如：
- approved_at DATETIME NULL —— 通过/驳回时间
- approved_by BIGINT NULL —— 审核人ID
- reject_reason TEXT NULL —— 驳回原因（仅驳回时填充）
这些字段不强制非空，按需填写，既保持主表轻量，又支持审计追溯。
状态变更建议走专用审核日志表
若需完整留痕（比如谁在什么时候把状态从“待审”改成“驳回”，再改成“重新提交”），可另建一张 content_audit_log 表，记录每次状态变更。主表只存最新状态，日志表负责还原过程。这样兼顾查询性能与合规要求，也方便做状态机校验或告警触发。
基本上就这些。状态设计不复杂但容易忽略业务细节，先想清楚流转场景，再选字段粒度。
