$casts 不能解决字符串长度标准化问题，因其仅在读取时做类型转换，不干预写入前的数据整形；必须用 mutator（如 setcodeattribute）在写入时通过 str_pad 等函数统一处理长度。
为什么 $casts 不能解决字符串长度标准化问题
很多人看到“字符串长度统一”第一反应是往 $casts 里加 'name' => 'string'，但这个只是类型转换，不控制长度。Eloquent 不会在写入前自动截断、补空格或填充零——它连 trim 都不做，原样存进数据库。如果你的字段是 VARCHAR(10)，而传入了 15 个字符的字符串，MySQL 可能报 SQLSTATE[22001]: String data, right truncated，也可能静默截断（取决于 SQL mode），结果不可控。
-
$casts只影响属性读取时的类型转换，不影响写入前的数据整形 - 数据库层面的
CHAR(8)字段会自动右补空格，但 PHP 读出来仍是带空格字符串，后续比较、JSON 序列化、API 输出都可能出问题 - 用
mutator是唯一可靠且可控的入口点
用 setAttribute mutator 做左补零或右补空格
在 Model 中定义 mutator，比如要让 code 字段恒为 6 位数字（不足左补 0），就写 setCodeAttribute。注意：必须和数据库字段名完全一致，且方法名格式固定为 set + 字段名首字母大写 + Attribute。
protected function setCodeAttribute($value)
{
$this->attributes['code'] = str_pad((string) $value, 6, '0', STR_PAD_LEFT);
}
- 一定要先转成
(string)，否则null或整数传入时str_pad行为异常 - 第三个参数是填充字符，第四个是方向：
STR_PAD_LEFT、STR_PAD_RIGHT、STR_PAD_BOTH - 别在 mutator 里调用
$this->code = ...，会触发无限递归 - 如果字段允许
null，建议先判断：if ($value === null) { $this->attributes['code'] = null; return; }
批量填充时怎么避免重复处理
用 create() 或 fill() 批量赋值时，mutator 依然生效，但要注意：如果数据已经过前端或中间件预处理（比如 API 请求体里 "code": "001"），mutator 还会再跑一遍。更危险的是，有些同学在 mutator 里直接调用 $this->setAttribute('code', ...)，导致死循环。
- 不要在 mutator 内部再次调用
setAttribute或给$this->code赋值 - 如果业务需要“仅首次填充”，应把逻辑提到 Service 层，在调用
create()前统一处理原始数组 - 测试时用
make()比create()更安全，避免误写库 - 对敏感字段（如密码、token），务必确认填充逻辑不会覆盖真实值
从数据库读出后要不要反向 trim / unpad
一般不需要。Eloquent 的 accessor 是读取时触发的，如果你写入时用了 str_pad，读出来就是带填充的结果，这是符合预期的。强行在 accessor 里 trim() 或 rtrim($value, '0') 会导致「写入和读出不一致」，下游代码无法信任模型属性值。
- 除非业务明确要求对外暴露“原始值”，才加 accessor，比如
getRawCodeAttribute() - JSON 序列化时，填充后的值会如实输出，如果前端不需要前导零，应在 API 层做映射，而不是破坏模型一致性
- 数据库查询中用
WHERE code = '000001'能正常命中，因为写入和索引都是填充后的值
真正容易被忽略的是迁移文件里的字段定义：别用 CHAR 依赖数据库补空格，坚持用 VARCHAR + mutator 控制逻辑层行为；还有就是测试时记得覆盖 null、空字符串、超长字符串这三种边界输入。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
