最稳妥方案是用 TINYINT 存位运算字段，因 BIT 在 PHP 中易引发类型错误；TINYINT(4) 更安全，支持 8 位标志，超限则升 SMALLINT 或 INT，全程保持整型上下文。
MySQL 建表时用 TINYINT 存位运算字段最稳妥
直接用 BIT 类型看似贴合语义，但 PHP 的 MySQL 扩展（尤其是 mysqli 和 PDO）对 BIT 返回的是二进制字符串或异常整数，容易引发隐式类型转换错误。比如 SELECT flag FROM t WHERE id=1 返回 "\x03" 而非 3，PHP 中做 & 运算会失败。
推荐方案是：TINYINT(1) 或 TINYINT(4)（后者更安全，避免无符号溢出干扰），配合 PHP 使用整型位操作。建表示例：
CREATE TABLE user_permissions ( id INT PRIMARY KEY, perms TINYINT NOT NULL DEFAULT 0 );
-
TINYINT占 1 字节，支持 -128～127（有符号）或 0～255（无符号），足够存 8 个布尔标志 - 别用
ENUM或SET——它们底层是字符串，无法直接参与位运算，且迁移和 ORM 映射麻烦 - 如果权限项超过 8 个，改用
SMALLINT（2 字节，16 位）或INT（4 字节，32 位），不要强行拼多个字段
PHP 中用常量 + 按位运算判断/设置权限
核心是定义清晰的位常量，并统一用整型参与运算。避免用字符串、数组模拟位，那不是位运算，是低效的查找。
示例（定义 + 判断 + 设置）：
立即学习“PHP免费学习笔记（深入）”；
const PERM_READ = 1 << 0; // 1
const PERM_WRITE = 1 << 1; // 2
const PERM_DELETE = 1 << 2; // 4
const PERM_ADMIN = 1 << 7; // 128
$perms = (int)$row['perms']; // 强制转 int，防字符串干扰
// 判断是否有写权限
if ($perms & PERM_WRITE) { ... }
// 添加删除权限
$perms |= PERM_DELETE;
// 移除读权限
$perms &= ~PERM_READ;
// 保存回数据库（确保是整数）
$stmt->execute([$perms, $id]);
- 务必对数据库读出的值做
(int)强转，尤其当 PDO 设置了PDO::ATTR_EMULATE_PREPARES = true时，TINYINT可能被当作字符串返回 - 用
|=添加、&= ~移除，比先查再改再存更原子（但注意并发场景仍需加锁或用 SQL 原子更新） - 不要用
in_array()或array_search()模拟位判断——失去位运算意义，且 O(n) 查找
SQL 层直接做位运算更新更高效
高频权限变更（如开关某权限）不建议“查 → PHP 算 → 写”，而应交给 MySQL 原子执行，减少网络往返和 PHP 解析开销。
例如开启用户 ID=123 的管理员权限：
UPDATE user_permissions SET perms = perms | 128 WHERE id = 123;
关闭写权限：
UPDATE user_permissions SET perms = perms & ~2 WHERE id = 123;
- MySQL 的
|和&是原生整型位运算，性能极高 - WHERE 条件必须精确，避免误更新；高并发下可加
FOR UPDATE（若用事务） - PHP 中执行这类语句时，无需取回旧值，
$pdo->exec()即可，省去一次查询
调试时用 decbin() 和 printf('%08b', $n) 看位状态
位运算出问题，90% 是因为没看清当前整数的二进制形态。别靠心算，用工具输出。
快速验证权限组合是否正确：
echo decbin(PERM_READ | PERM_WRITE | PERM_ADMIN); // 输出 "10000011"
printf('%08b', $dbValue); // 补零到 8 位，一眼看出哪几位被置 1
-
decbin()不补零，高位 0 会被省略，易误判；printf('%08b')更适合调试 - 数据库里存的是整数，不是“状态数组”，所以不要在 PHP 里维护一个冗余的
$permMap = [1=>'read', 2=>'write']数组来回映射——那是设计倒退 - 上线前用真实数据跑一遍所有权限组合的增删查，特别检查
0、255、-1（如果用了有符号）等边界值
SET 字段），都会让“高效”变成幻觉。 
