该怎么设计布尔字段

设计布尔（Boolean）字段看似简单，但其实有很多细节和“坑”需要注意。下面从数据库设计、代码建模、API 设计、业务语义几个层面系统讲一下。

一、数据库层面的布尔字段设计

1. 类型选择

不同数据库布尔类型不同：

• MySQL：没有真正的 BOOL，常用 TINYINT(1)（0 / 1）
• PostgreSQL：BOOLEAN
• SQL Server：BIT

✅ 建议：

is_deleted BOOLEAN NOT NULL DEFAULT FALSE

2. 是否允许 NULL

尽量不用 NULL，除非业务真的“未知”。

❌ 不推荐：

is_active BOOLEAN

✅ 推荐：

is_active BOOLEAN NOT NULL DEFAULT TRUE

原因：

• NULL 会让逻辑判断变复杂
• 三态（true/false/null）容易出 bug

二、命名规范（非常重要）

1. 使用 is_ / has_ / can_ 前缀

布尔字段要“读起来像判断句”。

✅ 好命名：

• is_deleted
• has_paid
• can_edit
• enabled

❌ 差命名：

• delete
• status（这是状态，不是布尔）
• flag

三、避免“布尔爆炸”（重点）

问题场景

用户有很多开关：

is_email_enabled
is_sms_enabled
is_push_enabled
is_admin
is_vip

→ 字段越来越多，表越来越宽

更好方案 1：状态枚举代替布尔

user_status ENUM('normal','vip','banned')

更好方案 2：位掩码 / 权限表

permissions INT  -- 位运算

或

user_setting (
  user_id,
  setting_key,
  setting_value
)

四、代码层（Java / TS / Python 示例）

Java

private boolean deleted;

⚠️ 注意：

• 不用 Boolean 除非允许 null
• getter 用 isDeleted()

TypeScript

interface User {
  isDeleted: boolean;
}

Python

is_active: bool = True

五、API 设计建议

JSON 中

{
  "isVip": true,
  "canEdit": false
}

❌ 避免：

"status": 1

六、常见反模式（避坑）

❌ 用 0/1 字符串

status = '0'

❌ 用布尔表示多状态

is_error   -- 其实有 10 种错误

❌ 布尔字段语义模糊

is_done

（done 是什么？支付？发货？）

七、什么时候不该用布尔

八、一个“最佳实践”模板

is_deleted BOOLEAN NOT NULL DEFAULT FALSE
created_at TIMESTAMP NOT NULL
deleted_at TIMESTAMP NULL

✅ 逻辑删除优于物理删除

如果你愿意，可以告诉我：

• 用的是哪种数据库？
• 是用户系统 / 订单系统 / 配置系统？
• 还是前端表单里的布尔开关？

我可以直接帮你设计具体字段表。