ThinkPHP字段映射失败主因是驼峰与下划线转换逻辑被绕过：默认开启$convertName=true将last_login_time映射为lastLoginTime，直接访问$user->last_login_time因属性不存在而失败，但getData()可读原始键；field(true)、Db::table()、联表同名字段、未设$table或$pk、大写字段（如APIKey）等均会导致转换失效。
ThinkPHP 字段自动转换（驼峰 ↔ 下划线）不是“开个开关就全局生效”的功能，它受模型配置、数据库连接设置、方法调用路径三重影响；多数失败不是配置没开，而是某一层绕过了转换逻辑。
为什么 $user->last_login_time 取不到值，但 getData('last_login_time') 能拿到
这是字段映射被静默跳过的典型表现。ThinkPHP 默认开启 $convertName = true（TP6），会把数据库字段 last_login_time 自动映射为模型属性 lastLoginTime。如果你直接写 $user->last_login_time，框架会去找一个叫 last_login_time 的属性（不存在），而不是触发反向映射。
- 模型中未显式声明
protected $convertName = true时，TP6.3+ 默认启用，但某些场景（如调用field(true)或Db::table()）会跳过模型层，导致转换不生效 -
getData()绕过属性访问器，直接读原始数据数组，所以能命中last_login_time - 联表查询时若两张表都有
id字段，且未用别名区分，last_login_time可能被覆盖或丢弃，看起来像“取不到”
Db::table() 查询正常，但 UserModel::select() 返回空或字段丢失
根本区别在于：前者走原生查询，不经过模型字段转换；后者走模型实例化流程，依赖 $table、$pk 和 $convertName 三者协同。只要其中一环断开，字段就“消失”。
- 没设
protected $table = 'user'，模型会按类名推导表名（UserModel→user_model），查错表自然没数据 - 主键不是
id却没设protected $pk = 'user_id'，find()生成的 WHERE 条件可能为空或错写成WHERE id = ? - 数据库字段含大写字母（如
APIKey），默认正则无法识别，lastLoginTime映射失败，需手动用setAttr()补充规则
关闭自动转换后，$type 和 $readonly 仍导致更新失败
关掉字段名转换（protected $convertName = false）只解决“名字对不上”，但 $type 类型定义和 $readonly 只读字段控制的是“值能不能写进去”，这两者独立生效，常被误认为是转换问题。
-
'status' => 'integer'定义下，传入字符串'1'会被过滤掉，UPDATE 语句里直接没有status字段 -
protected $readonly = ['create_time']会让该字段永远不出现在 INSERT/UPDATE 的 SET 子句中，哪怕你显式赋值 -
$type中写'datetime'但没配格式化器（如'Y-m-d H:i:s'），入库时转成0000-00-00 00:00:00，MySQL 拒绝写入，SQL 报错却显示“影响 0 行”
API 响应要驼峰，数据库字段用下划线，怎么避免每处都手动 Str::camel()
不要改 app.json_encode 全局配置——它会影响错误页、调试信息等所有 JSON 输出，极易误伤。统一收口在 Response 层才是安全做法。
- 继承
think\Response写一个JsonCamelResponse，在send()前对$this->data递归调用Str::camel() - 在 API 基础控制器里重写
success()方法，内部先做键名转换再调用json() - 切记：输入端（
input()、验证器）仍要用Str::snake()解析请求体，验证器字段名必须保持下划线，否则验证规则不匹配
最易被忽略的是：字段映射只发生在模型实例化和序列化阶段，中间任何一次 toArray()、json_encode() 或手动构造数组，都会脱离框架控制。别指望“设了 convertName 就万事大吉”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
