ThinkPHP 6.0+ 通过设置 protected $convertName = true 可自动将下划线字段（如 user_name）映射为驼峰属性（userName），读写双向转换，但需配合 $type 或 $schema 使用，且查询条件、排序等 SQL 相关操作仍须用原始字段名。
模型里怎么写字段别名映射
ThinkPHP 的模型默认按数据库字段原名映射，但旧表常用 user_name、create_time 这类下划线命名，而 PHP 属性习惯 userName、createTime。要让查询结果自动转成驼峰，不是靠手动 ->toArray() 后遍历改键，而是靠模型配置。
在模型类里加 protected $convertName = true; 就行——这是 ThinkPHP 6.0+ 的开关，默认是 false。它会把下划线字段（如 user_name）自动映射为驼峰属性（userName），同时写入时也能反向转换。
- 必须配合
protected $type = [];或字段定义使用，否则只影响读取不保证写入转换 - 如果字段名本身含数字或大写字母（如
user_ID），$convertName = true会转成userId，不是userI d，这点容易误判 - 开启后，
Db::name('user')->field('user_name')->find()返回的数组键仍是user_name，只有模型实例的属性才是userName
字段别名冲突时谁优先
当数据库字段名和你自定义的属性名撞车，比如字段叫 status，你又在模型里写了 public $status = 1;，ThinkPHP 会以字段映射为准，你的属性会被覆盖。更常见的是用 protected $schema = []; 显式声明字段时，和 $convertName 逻辑打架。
-
$schema里写的字段名（如'user_name' => 'string'）必须是数据库真实字段名，不能写'userName' => 'string' - 如果同时开了
$convertName又在$schema里漏写某个字段，该字段不会被自动转换，读出来还是user_name键 - 用
__set()或setAttribute()手动设值时，传userName能生效，但传user_name也会被接受——底层做了双路兼容，但不建议混用
关联查询中别名映射还生效吗
关联查出来的子模型字段，一样走各自模型的 $convertName 配置。但主模型查关联数据时，with(['profile']) 返回的 profile 子对象属性是驼峰的，前提是 ProfileModel 自己开了 $convertName = true。
- 主模型没开
$convertName，子模型开了：主模型字段仍是下划线，子模型字段是驼峰——不会错乱，但风格不统一 - 用
join手写关联时，字段别名得自己写清楚，比如user.user_name AS userName，否则数据库返回的键还是user_name，模型不识别这个别名 - 聚合字段（如
COUNT(*) AS count）不会被$convertName处理，返回键就是你写的count，不是countNum之类
兼容旧代码时最常踩的坑
老项目从 TP5 升到 TP6，或者字段命名混乱（部分驼峰、部分下划线），最容易出问题的地方不在映射本身，而在「哪里用了原始字段名」。
- 查询条件里写
where('userName', ...)会报错，必须写where('user_name', ...)—— 条件字段名不走别名映射 -
order('userName')同样无效，数据库不认识这个字段，得写order('user_name') - 用
save(['userName' => 'xxx'])是可以的，但save(['user_name' => 'xxx'])也行；两者都接受，但混着用容易在调试时漏看实际执行的 SQL 字段 - 导出 Excel 或 API 返回时，如果直接
json($model->toArray())，得到的是下划线键；要用json($model->toExpressArray())或手动getAttr()才能确保驼峰
字段映射看着是自动的，其实只管“模型属性访问”这一层，SQL 构建、条件拼接、原始数组输出全都不受控——这点最容易被忽略。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
