php布尔字段应使用tinyint(1) unsigned存储，注释说明语义；php层显式类型转换，orm中声明boolean映射；命名用is_/has_/can_前缀，避免enum/varchar。
PHP 中数据库布尔字段的设计，核心是避免直接使用 MySQL 的 TINYINT(1) 或 BIT 类型来模拟布尔逻辑，而应结合数据库实际支持、ORM 行为、PHP 类型安全与可读性统一考虑。
优先使用 TINYINT(1) 存储，但明确语义而非依赖“自动布尔转换”
MySQL 本身没有原生 BOOLEAN 类型（仅是 TINYINT(1) 的别名），且其值 0/1 并不等价于 PHP 的 true/false。很多开发者误以为插入 true 就存成 1、查出来自动变 true，但实际：
- PHP PDO 默认以字符串返回所有字段（如 "1" 或 "0"），不是布尔值；
- 即使启用
PDO::ATTR_EMULATE_PREPARES = false和PDO::ATTR_STRINGIFY_FETCHES = false，TINYINT(1) 仍常被返回为整数，需手动 cast； - 某些 MySQL 驱动或配置下，TINYINT(1) 可能被客户端当作“布尔显示”，但底层仍是数值，不可靠。
✅ 建议：字段类型用 TINYINT(1) UNSIGNED，默认 DEFAULT 0，注释标明含义（如 COMMENT '是否已审核：0=否，1=是'）；PHP 层统一用 (bool) $row['is_approved'] 或访问器封装，不依赖数据库隐式转换。
避免使用 ENUM('0','1') 或 VARCHAR 存布尔值
这类设计看似“直观”，实则带来明显问题：
立即学习“PHP免费学习笔记（深入）”；
- ENUM 本质是字符串枚举，排序、索引、迁移、ORM 映射都易出错；
- VARCHAR 浪费空间，无法约束取值范围，且 SQL 查询时需写
WHERE status = '1'，易拼错或混淆类型； - 违反三范式中“原子性”原则，也增加应用层判断负担（比如要兼容 'true'/'false'/'yes'/'no' 等）。
❌ 不推荐：status ENUM('0','1')、active VARCHAR(5)。
在 Laravel / Doctrine 等 ORM 中主动声明布尔映射
现代 PHP 框架通常提供类型转换机制，应显式启用：
- Laravel Eloquent：在 Model 中定义
protected $casts = ['is_published' => 'boolean'];，框架会自动将 0/1 转为 false/true，并在保存时反向处理； - Doctrine：用
@Column(type="boolean")，它默认将 boolean 映射为 TINYINT(1)，并负责 PHP ↔ DB 类型转换； - 自建 DAO 或使用 PDO 时，可在 fetch 后统一做
array_map(fn($v) => ['is_active'] => (bool)$v, $row)，或封装 getBoolean() 方法。
⚠️ 注意：Laravel 的 'boolean' cast 会把 '0'、'false'、''、null 都转为 false，把其余非空字符串转为 true——因此数据库必须只存 0/1，不能混入字符串。
命名清晰，拒绝模糊字段名
布尔字段名应表达正向状态，用 is_、has_、can_ 开头，避免否定形式或歧义词：
- ✅ 推荐：
is_deleted、has_avatar、can_comment； - ❌ 避免：
deleted（语义不明，是时间戳？标识？）、not_active（双重否定难理解）、flag（完全无意义）。
字段注释同步说明业务含义和取值逻辑，例如：is_locked COMMENT '账号是否被锁定：1=是（禁止登录），0=否'。
不复杂但容易忽略：布尔字段的价值在于快速判断与索引优化，设计时守住“单一语义 + 确定取值 + 显式转换”三条线，就能兼顾健壮性与可维护性。
