Eloquent模型属性值自动转义实为MySQL连接层或PDO隐式转义叠加Laravel casts/访问器所致，典型表现为café存为café；需用bin2hex()查原始字节定位问题环节，常见原因包括MySQL全局编码配置未覆盖、AppServiceProvider硬编码SET NAMES、访问器误调utf8_encode()等。
PHP中Eloquent模型的属性值自动转义是怎么发生的
不是Eloquent主动“编码”，而是MySQL连接层或PDO在特定配置下对字符串做了隐式转义，再叠加Laravel的casts或访问器（accessor）手动处理，才导致重复编码。典型现象是数据库存的是café，查出来变成café或caf%u00e9。
关键判断点：先确认问题出在入库前、查询后，还是模板渲染时。用bin2hex()检查原始字节最可靠：
dd(bin2hex($model->name)); // 查看实际存储的字节序列
- 如果是
636166c3a9（UTF-8的café），说明存储正确，问题在读取或显示环节 - 如果是
636166e9（Latin-1的café），说明写入时被错误转码过
Laravel 10+默认配置下仍出现乱码的三个常见原因
即使DB_CHARSET设为utf8mb4、DB_COLLATION为utf8mb4_unicode_ci，以下情况仍会触发编码错乱：
- MySQL服务器全局
character_set_client或collation_connection被运维改过，且未在Laravel的database.php里显式覆盖 —— 必须在mysql配置的options里加PDO::MYSQL_ATTR_INIT_COMMAND => "SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci" -
AppServiceProvider里用了DB::statement("SET NAMES latin1")这类硬编码（常见于老项目迁移） - 模型里定义了
getXXXAttribute访问器，但内部调用了utf8_encode()或mb_convert_encoding($value, 'UTF-8', 'GBK')等转换逻辑，而原始值本就是UTF-8
用casts避免手动编码处理的实操要点
把字符编码逻辑从业务代码里剥离，交给Eloquent的casts统一管理，是最少出错的方式。但要注意：
立即学习“PHP免费学习笔记（深入）”；
-
'content' => 'string'只是类型断言，不改变编码 —— 它只确保值是PHP string类型，不负责转码 - 真正起作用的是
'content' => 'json'或'content' => 'array'这类cast，因为它们会经过json_encode()（强制UTF-8）和json_decode()（默认返回UTF-8字符串） - 若必须做编码转换（如对接旧系统要求GBK字段），应自定义cast类，在
get方法里用mb_convert_encoding($value, 'UTF-8', 'GBK')，set方法反向转换，并确保数据库字段实际是GBK编码（这本身违背Laravel最佳实践）
调试时别忽略MySQL连接的实际编码状态
运行php artisan tinker，执行以下命令，比看配置文件更真实：
DB::select("SHOW VARIABLES LIKE 'character_set%'");
重点关注三行：
-
character_set_client：客户端发请求时声称自己用的编码（必须是utf8mb4） -
character_set_connection：连接层转换用的编码（必须是utf8mb4） -
character_set_database：数据库默认编码（应为utf8mb4）
只要其中任意一项不是utf8mb4，DB::raw("HEX(name)")查出来的十六进制值就可能异常。这时候改Laravel代码没用，得调MySQL配置或PDO连接参数。
多字符编码问题从来不是单点故障，它横跨PHP字符串处理、PDO传输、MySQL服务端解析、甚至前端HTTP头声明。最容易被忽略的是——你以为修复了PHP层，其实数据库连接正在默默把UTF-8当Latin-1解码。
