yii2模型中用类常量定义枚举值最稳妥，配合getstatuslist()返回键值对、rules()中引用array_keys(static::getstatuslist())、自定义message显示中文名，并在查询中使用user::status_published等常量确保语义一致。
Yii2 模型里怎么定义枚举值——用类常量最稳
直接用 const 定义枚举值，配合 rules() 和 attributeLabels()，是 Yii2 里最轻量、最可控的做法。框架本身不内置枚举类型，硬塞 myclabs/php-enum 反而容易在验证、序列化、AR 查询时掉链子。
常见错误：把枚举值写死在 rules() 的 in 规则里，比如 ['status', 'in', 'range' => [0, 1, 2]]，后续加状态要改两处（规则 + label），漏一处就出问题。
- 在模型类顶部统一定义：
const STATUS_DRAFT = 0;、const STATUS_PUBLISHED = 1;、const STATUS_ARCHIVED = 2; -
rules()中写成：['status', 'in', 'range' => array_keys(static::getStatusList())] -
getStatusList()返回[self::STATUS_DRAFT => '草稿', ...]，供下拉、label、API 展示复用 - 数据库字段用
TINYINT或SMALLINT，别用ENUM类型——MySQL 的ENUM字符串排序、ALTER 成本高，且 Yii2 不自动映射
验证失败时提示中文名而不是数字——靠 getMessage() 重写
默认 'in' 验证器报错是 “Status must be either 0, 1 or 2”，用户根本看不懂。得让错误信息显示 “Status must be either 草稿, 已发布 or 已归档”。
不能只靠 message 配置项硬编码，因为不同场景枚举含义可能不同（比如 type 在订单和用户模型里值域完全不同）。
- 在模型里覆盖
getValidationError()或直接在rules()中用闭包自定义 message：['status', 'in', 'range' => [...], 'message' => Yii::t('app', 'Status must be one of: {list}', ['list' => implode(', ', array_values($this->getStatusList()))])] - 更干净的做法：写个 trait，提供
getInErrorMessage($attribute)方法，自动读取对应getXxxList()并拼接 - 注意：别在 message 里调用未初始化的静态方法，会导致验证阶段 fatal error
数据库查询时按枚举语义筛选——避免手写魔法数字
写 User::find()->where(['status' => 1])->all() 是反模式。一旦常量值变更或团队新人接手，这行代码立刻失效，且 IDE 无法跳转、搜索不到上下文。
真实项目里，这类查询往往散落在控制器、服务类、甚至视图里，后期维护成本极高。
- 所有枚举查询必须走类常量：
User::find()->where(['status' => User::STATUS_PUBLISHED])->all() - 复杂条件用作用域（scopes）：
public function scopePublished($query) { return $query->andWhere(['status' => self::STATUS_PUBLISHED]); }，然后User::find()->published()->all() - 如果用到了
QueryInterface::andFilterWhere()动态条件，确保传入的是常量值，不是字符串'published'—— 后者需要额外映射层，容易漏处理
什么时候才考虑 myclabs/php-enum——它真没你想的那么省事
这个库在 Laravel 或纯 PHP CLI 场景里确实好用，但在 Yii2 里会和 AR 生命周期、表单绑定、验证器链深度耦合，带来一堆隐性成本。
典型翻车点：用 MyEnum::from($value) 做属性赋值后，save() 时没自动 cast 回整型，存进数据库的是对象字符串；或者 load() 表单数据时，原始 POST 值是字符串 "1"，但 enum 构造器要求 int，直接抛异常。
- 只有当你明确需要「枚举实例自带方法」（比如
$status->isPublished()）且整个项目已重度依赖该库时，才值得引入 - 必须重写模型的
beforeValidate()和afterFind()，手动做toValue()/from()转换 - JSON 序列化（比如 API 输出）需额外配置
JsonSerializable，否则返回空对象 - 绝大多数业务场景，一个带文档的
const+getXxxList()组合，已经覆盖 95% 需求
最常被忽略的一点：枚举值的语义一致性。比如 STATUS_ACTIVE = 1 在用户表表示“启用”，在订单表却表示“待支付”——这种跨模型复用常量名但含义错位的问题，比技术选型更致命。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
