ThinkPHP处理JSON数据类型强转错误_序列化自动检测方案-ThinkPHP-PHP中文网

thinkphp 6 默认不自动反序列化 json 字段，需在模型中声明 protected $json = ['config', 'extra']; 才能将数据库 json 字符串转为 php 数组/对象，否则直接访问会报错；$json 仅对模型查询生效，不支持点号嵌套字段，且与 withattr 冲突时应避免共用。

thinkphp处理json数据类型强转错误_序列化自动检测方案

ThinkPHP 6 的 `json` 字段自动转数组/对象失效？

不是框架坏了，是它默认不自动反序列化 json 字段——哪怕你数据库字段类型是 JSON，TP6 仍当它是字符串返回。这导致你直接 foreach 报错、->name 访问报错，本质是没触发反序列化。

解决方式很简单：在模型里显式声明该字段为 json 类型，让 TP 知道“这里存的是 JSON，读出来得给我转成 PHP 结构”：

protected $json = ['config', 'extra'];

注意：$json 是模型属性，不是数据库字段名列表，值必须是字段名（字符串），且仅对 select / find 等查询结果生效；写入时 TP 会自动 json_encode，无需手动处理。

如果字段名含点号（如 user.profile），不支持，TP 不解析嵌套路径
$json 对 toArray() 有效，但对 getAttr() 自定义获取器不自动叠加——你要自己在获取器里 json_decode
MySQL 5.7+ 的 JSON 类型字段和普通 TEXT 字段在此配置下行为一致，TP 不区分底层存储类型

强转失败报 `Cannot use object as array` 怎么定位？

典型场景：查出数据后直接 $data->info['id']，但 info 其实还是 JSON 字符串，没被解包。错误不是发生在数据库层，而是在 PHP 运行时。

快速验证方法：在出错行前加一句 var_dump(gettype($data->info), $data->info);。如果输出 string 和一串带引号的 JSON，说明 $json 没配对，或字段名拼错了。

常见拼写错误：$json = ['Info'] 但数据库字段是 info（大小写敏感）
使用了 withAttr 但忘了删掉 $json，两者冲突会导致重复 decode 或跳过处理
从 Db::table() 直接查，绕过了模型，$json 完全不生效——必须用模型实例查询

`withAttr` 和 `$json` 能不能一起用？

能，但没必要，而且容易互相覆盖。两者都用于字段类型转换，但机制不同：$json 是模型级全局声明，走 TP 内置 JSON 处理流程；withAttr 是查询时动态绑定的获取器，优先级更高，会直接接管字段值。

如果你写了：

protected $json = ['setting'];<br>protected $withAttr = [<br>    'setting' => 'json_decode'<br>];

结果是：TP 先按 $json 解一次，再进 withAttr 又解一次——第二次 json_decode 作用在数组上，返回 null，数据就丢了。

推荐只选一种：$json 更轻量、更符合 TP 设计意图；withAttr 适合需要定制逻辑的场景（比如兼容旧格式、带默认值 fallback）
若必须用 withAttr，请确保字段不在 $json 列表里，避免双重处理
withAttr 的回调函数接收原始字符串，返回值将直接作为最终属性值，不经过任何后续转换

MySQL 8.0 的 JSON 函数在 TP 里怎么安全用？

TP 自身不解析 SQL 中的 JSON_EXTRACT、JSON_CONTAINS 等函数返回值，它们只是字符串。也就是说，你在 field 里写 JSON_EXTRACT(data, "$.name") as name，查出来 $data->name 仍是字符串，不是 PHP 数组。

这时候别指望 $json 自动生效——它只对原始字段名起作用，不识别 SQL 别名或表达式。