ThinkPHP中滥用JSON字段易导致查询慢、更新不原子、索引缺失、内存溢出及调试困难；应仅用于不参与查询且结构松散的小数据，否则须拆表或改用EAV模式。
ThinkPHP 里把大量数据塞进 JSON 字段（比如 extra、config、data）不是不能用，而是很容易在查询、更新、索引、调试几个环节翻车。尤其当字段内容超过 1KB、且需要按内部键查或改时，问题会集中爆发。
JSON 字段被当成“万能筐”，结果查不出也改不动
MySQL 的 JSON 类型本身不支持原生索引（5.7+ 支持生成列 + 普通索引，但 ThinkPHP 默认不帮你建）。你在 TP 里写 where('extra->$.status', 'paid')，表面能跑，实际执行的是全表扫描 + JSON 解析，数据一过万条就明显变慢。
更常见的是用 json_decode($model->extra) 在 PHP 层处理，然后改完再 json_encode() 回存——这等于绕开数据库的原子性，高并发下极易覆盖他人修改。
- TP6/8 的
Db::json()或模型的json类型转换只做自动编解码，不提供字段级更新能力 - 想局部更新 JSON 内某个 key？必须用原生 SQL：
JSON_SET(extra, '$.status', 'shipped')，TP 不封装这个 - 如果字段里存了数组，还要按数组元素过滤（比如
extra->$.tags contains 'vip'），MySQL 8.0+ 才支持JSON_CONTAINS，旧版本只能全量取出 PHP 处理
大 JSON 字段拖垮 ORM 查询和内存
ThinkPHP 的 select() 或 find() 默认取全部字段。一旦某张表有个 2MB 的 log_data JSON 字段，哪怕你只想要 id 和 title，TP 也会把它一起捞出来，徒增网络传输、PHP 内存占用、GC 压力。
立即学习“PHP免费学习笔记（深入）”；
这个问题在分页、关联、导出场景下特别致命：比如 Order::with('user')->paginate(20)，若每个订单带一个 500KB 的操作日志 JSON，20 条就是 10MB 内存，FPM 进程直接 OOM。
- 强制指定字段：用
field('id,title,created_at')显式排除 JSON 字段，别依赖__auto__ - 关联查询时，模型的
hidden属性对 JSON 字段无效，得靠field()或视图层过滤 - 导出 CSV/Excel 时，绝对不要
toArray()整行转，应手动生成精简数组
调试时 JSON 字段变成“黑洞”，日志和 dump 都失真
TP 的调试栏、dump()、Log::info() 对超长 JSON 默认截断或转成 string(1024)，你看不到真实结构；而 var_dump() 又容易把终端撑爆。更麻烦的是，JSON 里嵌套 HTML、Base64 图片、错误堆栈时，直接输出会破坏页面结构或触发 XSS 渲染。
另外，TP 的模型事件（如 afterWrite）拿到的是已解码的 PHP 数组，但数据库里存的是原始字符串——你想记录变更前后差异？得手动重 json_encode() 对比，极易漏掉浮点精度、空数组/对象差异等细节。
- 调试前先限长：
substr($model->extra, 0, 500)+…，或用json_encode(json_decode($model->extra), JSON_UNESCAPED_UNICODE | JSON_PRETTY_PRINT)格式化 - 日志中避免直接写
$model->extra，改用mb_strimwidth($model->extra, 0, 200, '…') - 敏感字段（如含 token、密码）必须在
hidden或append里显式控制，TP 不会自动识别 JSON 内容是否敏感
真正该存 JSON 的，只有那些完全不参与查询、不需索引、结构松散且体积可控的数据，比如用户界面偏好、第三方回调原始 payload、临时表单草稿。一旦出现“按 JSON 里的 status 筛选”“统计 JSON 里 tags 出现次数”“前端要实时编辑 JSON 某个子字段”，就该立刻拆成独立表或用 EAV 模式——别让 JSON 字段成为技术债的温床。
