PHP 枚举怎样给数据库值提供安全映射

如果数据库里的状态字段经常被字符串常量散落在各处，PHP backed enum 是一条更稳的映射边界：数据库继续保存简单的 string，业务代码拿到的是明确的枚举 case，写回数据库时再取这个 case 的 value。读取外部数据时优先用 tryFrom()，把未知值交给业务分支；只有已经确认符合值域的不变量数据，才适合用 from()。

官方文档：https://www.php.net/manual/en/language.enumerations.php

最实用的落地方式是：定义 string backed enum；仓储读取后用 Status::tryFrom() 做边界转换；写入前先得到合法的 Status，SQL 参数只绑定 $status->value。这样既保留数据库字段的可读性，也不会让未知历史值悄悄变成一个错误的业务状态。

先让枚举值与数据库字段一一对应

数据库状态字段通常是 draft、published、archived 这类短字符串。枚举不要依赖 case 名称自动生成值，而应把真正落库的字符串显式写出来。PHP 手册说明，backed enum 只能选择一种标量类型，所有 case 都要有唯一的 int 或 string 值；case 的 value 是只读属性。

这里的关键不是把数据库字段“变成对象”，而是把字符串到业务状态的转换集中在一个值域里。以后新增 reviewing，可以同时考虑数据库历史数据、接口返回和展示文案，而不是在几十个 if 里搜索字符串。

读取数据库时用 tryFrom 转成枚举

数据库是外部边界：旧数据、手工修复记录或尚未完成迁移的数据，都可能出现当前枚举没有的值。读取时用 tryFrom()，合法字符串得到对应的 ArticleStatus，未知字符串得到 null。这比直接把所有数据交给 from() 更适合在线请求，因为单条脏记录不会无提示地把整条读取链变成异常。

value;

tryFrom() 返回空值并不等于“自动修复”。如果业务选择默认成 Draft，应该在代码中写出这个决定，并配合日志或数据修复计划；不要让未知状态静默回退，导致读者误以为文章真的处于草稿状态。

区分 tryFrom 与 from 的使用边界

两者都根据 backed value 找到枚举 case，但失败语义不同：from() 找不到值会抛出 ValueError，tryFrom() 找不到值返回 null。因此，来自数据库、HTTP 请求或表单的值优先走 tryFrom()；只有经过前置约束、迁移或内部不变量保证的数据，才可以用 from() 把不可能情况快速暴露出来。

不要用捕获 ValueError 来替代所有输入校验。对不可信值，tryFrom() 让分支更直观；对内部必须成立的条件，from() 让错误尽早暴露。

写入数据库时只保存 value

写入方向相反：业务层应先获得合法的 ArticleStatus，持久化层只拿它的 value。PDO 仍然要使用预处理语句和参数绑定；枚举只负责约束值域，不能替代 SQL 参数化。

prepare($sql);
    $statement->execute([
        // 预处理参数仍是 SQL 安全边界，value 只是业务值转换结果。
        'status' => $status->value,
        'id' => $articleId,
    ]);
}

如果状态来自表单，先把表单字符串转成枚举，再调用这个函数：

把转换放进仓储边界

实际项目里，最容易失控的是业务层、控制器和 SQL 都各写一遍映射。可以让仓储负责“行数据 ↔ 枚举”的边界，让业务服务只接收 ArticleStatus。下面的示例保留了一个明确的未知值策略，便于后续接入日志或监控。

pdo->prepare(
            'SELECT status FROM articles WHERE id = :id'
        );
        $statement->execute(['id' => $articleId]);
        $row = $statement->fetch(PDO::FETCH_ASSOC);

        if ($row === false) {
            throw new RuntimeException('文章不存在');
        }

        $status = ArticleStatus::tryFrom((string) $row['status']);
        if ($status === null) {
            // 未知值不要伪装成合法状态，交给上层做兼容处理。
            throw new UnexpectedValueException('数据库包含未知文章状态');
        }

        return $status;
    }
}

仓储抛异常还是返回一个结果对象，要按项目的错误处理约定决定。重要的是边界固定：SQL 结果在这里变成枚举，服务层不再到处判断 'published' 这种裸字符串。

新增状态与历史脏值怎样处理

枚举本身不能替你完成数据迁移。新增 case 时，先决定数据库是否允许新值，再同步服务端读取、写入和展示逻辑；如果旧版本服务仍在线，还要考虑旧服务读到新值时会怎样处理。

还要记住，backed enum 的 case 值必须唯一，而且一个枚举只能使用一种 backed 类型。数据库列如果从整数改为字符串，不能只改 PHP 声明，还要把迁移、历史数据和接口契约一起安排好。

常见问题

数据库里可以直接保存枚举名称吗？

可以把名称当作业务约定，但更稳的是显式保存 backed value。case 名称适合代码阅读，value 适合持久化契约，二者不必被迫相同。

读取数据库为什么不建议总用 from？

数据库属于外部边界，历史记录可能包含当前代码未声明的值。总用 from() 会把这个数据问题直接变成 ValueError；如果需要兼容读取，先用 tryFrom()。

枚举能替代数据库 CHECK 约束吗？

不能完全替代。PHP 枚举约束应用层，数据库约束保护所有写入来源；重要状态字段可以同时考虑数据库约束、迁移策略和应用层映射。

枚举能防止 SQL 注入吗？

不能。枚举只限制业务值域，SQL 仍应使用 PDO 预处理和参数绑定，不能把 value 拼进 SQL 字符串。