查不到数据却没报错，需先确认模型中是否显式声明$table（TP6）或$name（TP5.1+）及$pk；字段映射异常时检查下划线转驼峰设置；更新失败需排查$type类型定义与$readonly只读字段；联表查询须避免字段名冲突。
查不到数据却没报错？先确认 __table 和 __pk 是否显式声明
ThinkPHP 默认按模型名（如 UserModel）转小写下划线（user_model）找表，但实际表名常为 user 或 tp_user。不显式指定 __table，查询会静默命中错误表，返回空结果集，且无任何提示。
主键同理：id 是常见命名，但若表用 user_id 或复合主键，不设 __pk 会导致 find()、save() 等方法内部 SQL 拼接失败（例如 WHERE 条件漏掉或错写成 WHERE id = ?）。
- 在模型类中加
protected $table = 'user';（TP6）或protected $name = 'user';（TP5.1+） - 主键非
id时，必须设protected $pk = 'user_id'; - TP6 中若用
__table静态属性，需确保它在initialize()前已存在，否则被忽略
Db::table() 能查出数据，但模型 select() 返回空？检查字段映射是否被自动转换
ThinkPHP 默认开启字段下划线转驼峰（如数据库字段 last_login_time → 模型属性 lastLoginTime）。若关闭了 db.fields_strict 或手动调用 field(true)，又或字段名含大写字母（如 APIKey），映射极易断裂。
典型表现：数据库有值，$user->last_login_time 取不到，但 $user->getData('last_login_time') 能拿到——说明字段被“转换”后丢失了原始键。
立即学习“PHP免费学习笔记（深入）”；
- 临时验证：在模型中加
protected $autoWriteTimestamp = false;并禁用所有自动转换，再用toArray()打印原始结果 - 长期方案：统一用小写下划线命名数据库字段，并在模型中设
protected $convertName = true;（TP6）或保持默认 - 调试时可强制关闭转换：
UserModel::withoutFieldConvert()->select()（TP6.3+）
更新失败且 getLastSql() 显示 SET 字段为空？重点看 protected $type 和 protected $readonly
字段类型定义（$type）不仅影响自动类型转换，还会干预写入逻辑。例如将 status 定义为 'status' => 'integer'，但传入字符串 '1'，TP 可能因类型校验失败而跳过该字段；更隐蔽的是，若字段在 $readonly 数组中，无论是否赋值，都不会出现在 UPDATE 的 SET 子句里。
常见陷阱：create_time 被误加进 $readonly，导致新增后无法再次更新；或 $type 写成 'datetime' 却未配格式化器，入库时转成 0000-00-00 00:00:00 被 MySQL 拒绝。
- 用
UserModel::get(1)->toArray()查看当前实例的原始数据与转换后数据差异 - 执行更新前，打印
$model->getChangedData()—— 若为空，说明字段根本没被识别为“已变更” - 检查
$readonly是否包含本应可写的字段；$type中的字段名必须与数据库字段名完全一致（区分大小写）
联表查询中字段别名冲突导致模型属性覆盖？用 withField() 或显式 field() 控制输出
使用 join() 或 view() 时，若关联表也有 id、name 等通用字段，ThinkPHP 默认把所有 SELECT 字段映射到主模型，造成属性值被覆盖（比如订单表的 user_id 覆盖了用户表的 id）。
这不是映射错误，而是字段“撞名”后模型无法区分归属。TP 不会警告，只取最后出现的同名字段值。
- 避免
field('*')，改用field('user.id,user.name,order.status')显式列出所需字段 - TP6.3+ 可用
withField(['order.status' => 'order_status'])重命名关联字段，再通过$user->order_status访问 - 调试阶段可在查询后立刻调用
getLastSql()，确认 SELECT 列是否含歧义别名
字段映射问题最难缠的不是报错，而是“看起来正常却逻辑错位”。建议每次建模后，用 getData() 和 getOriginData() 对比输出，再结合 getLastSql() 看最终 SQL —— 多数时候，问题不在模型配置，而在你没看见 SQL 里到底写了什么字段。
