模型事件不负责数据转换，仅提供钩子；类型转换应前置到请求层（param）或模型定义层（$type+$json），避免在事件中硬编码intval等操作，以防逻辑错位和维护困难。
ThinkPHP 的模型事件本身不负责数据转换，它只提供钩子时机；真正做转换得靠字段类型声明、$json 配置、param() 过滤或手动 cast——事件里硬写 intval() 或 json_decode() 属于逻辑错位，后期难维护。
模型事件里别直接做类型转换
很多人在 beforeInsert 或 beforeUpdate 里写 $this->status = intval($this->status)，以为能“统一转类型”。这看似可行，但会破坏数据源头的可追溯性：原始参数在哪？谁改的？有没有被其他中间件/验证器动过？调试时根本分不清是事件改的，还是数据库写入前又被 ORM 自动处理了一次。
- 事件适合做“业务逻辑增强”，比如自动生成
sn、同步更新关联表、记录操作人，不是做格式清洗 - 类型转换应该前置到请求层（
param('id/d')）或模型定义层（$type+$json），保证入口一致 - 如果非要在事件里调整字段，只做“值映射”（如
'enable' => 1→'status' => 'active'），不做基础类型强转
$type 和 $json 必须成对出现才生效
MySQL 的 JSON 字段想让 ThinkPHP 自动 json_encode/json_decode，光写 protected $json = ['config'] 没用。必须同时配 protected $type = ['config' => 'json']，否则读出来仍是字符串，写进去也不会自动编码。
-
$type告诉 ORM “这个字段要按什么规则处理”，$json是“哪些字段走 JSON 流程”的白名单，二者缺一不可 - 字段名必须严格匹配数据库列名，比如数据库是
user_profile，你就得写'user_profile' => 'json'，写成'userProfile'或漏掉下划线，转换静默失效 - 别用
'array'类型替代'json'——TP6 对 MySQL 5.7+ 的原生 JSON 类型支持良好，'array'反而绕过底层优化，还可能出兼容问题
批量查询结果转纯数组，别只调 toArray()
$users = User::with('posts')->select()->toArray() 看似干净，但返回的每个 posts 仍是 Collection 对象，不是数组。深层嵌套时，toArray() 不递归穿透模型的访问器、日期对象（Carbon）、自定义属性（getFullNameAttr）。
- 真要“全转成 array”，最稳的是走 JSON 序列化通道：
json_decode(json_encode($users), true) - 注意性能代价：大数据量（如上千条带复杂关联）时，两次序列化开销明显，建议只在导出、日志、跨服务传参等必要场景用
- 如果只是想隐藏某些字段，优先用
hidden或visible，而不是靠toArray()后再unset()
请求参数类型转换日志，别混用 input() 和 param()
想记录“前端传了什么”和“业务拿到什么”，最容易踩的坑是日志里记 $request->input('id')，代码里却用 $request->param('id/d')。前者是原始输入（可能还是 JSON 字符串），后者已走过滤规则，两者根本对不上。
- 统一源头：日志固定用
$request->input()记原始值，再用$request->param("key/type")记目标值，比如['id' => ['raw' => '1', 'cast' => 1, 'type' => 'd']] - 别在中间件里反复调
param('x/d')多次——TP6 内部有缓存，但若规则不一致（比如某处用了/d，某处用了/s），结果可能意外 - 生产环境关掉全量转换日志，按 IP 或路由开关，避免每请求都深拷贝+遍历+写磁盘
真正麻烦的从来不是“怎么转”，而是“在哪转”和“谁负责转”。模型事件只管“什么时候做”，类型转换的归属权必须提前划清——否则上线后查 bug，一半时间花在理清数据到底被谁改过第几遍。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
