直接运行php artisan tinker即可进入交互环境，无需额外配置或安装；它是laravel默认内置的psysh封装，非自研工具。常见user::first()返回null的原因包括未use模型、命名空间错误、表名/主键不匹配、软删除干扰及类型转换失败；默认事务机制导致修改退出即回滚，需db::commit()或事务闭包持久化。
直接运行 php artisan tinker 就能进，别折腾配置或重装——只要项目能跑 artisan 命令，tinker 就在那儿。它不是“额外工具”，而是 Laravel 默认加载的交互环境，本质是 psysh 的封装，不是 Laravel 自研的壳。
为什么 User::first() 返回 null，但数据库里明明有数据？
常见错误现象：模型类没 use、命名空间写错、表名/主键不匹配、软删除字段干扰。
- 必须显式引入模型：
use App\Models\User;（Laravel 8+ 默认路径，旧版可能是App\User） - 检查模型里是否误设了
$table或$primaryKey，比如写成'user_id'而非'id' - 软删除启用时，
User::first()默认不查deleted_at IS NOT NULL的记录；要查全部，得用User::withTrashed()->first() - 如果模型启用了强制类型转换（如
$casts = ['active' => 'boolean']），而数据库存的是字符串'0'，可能触发转换失败导致查询无声失败
DB::table('users')->first() 和 User::first() 查出来字段名大小写不一致？
这是设计差异，不是 bug。Eloquent 返回的对象自动处理访问器、强制类型、日期格式、JSON 解析；而 DB::table() 返回纯数组，字段名完全取决于数据库驱动返回的原始键名（MySQL 默认小写，PostgreSQL 默认小写但带引号时保留大小写）。
- 想保持字段一致性，统一走模型：
User::first()->toArray()比DB::table('users')->first()更可靠 - 若真要用
DB::table()，注意它不走模型事件、不触发访问器、不自动格式化created_at（返回的是字符串，不是Carbon实例） - 关联查询必须用 Eloquent：
User::with('posts')->first()，DB::table()不支持嵌套关系加载
执行 User::factory()->count(100)->create() 报唯一约束冲突？
Faker 的 unique() 默认只在单次调用内去重，跨 count(100) 批次不保证全局唯一，尤其对 email 这类字段。
- 修复方式：加
true参数启用全局缓存：$this->faker->unique(true)->safeEmail - 时间字段精度陷阱：数据库是
TIMESTAMP，但 Faker 生成带微秒的DateTime，MySQL 5.6+ 会截断报错；改用$this->faker->dateTimeThisYear()或模型里显式 cast 为'datetime' -
->make()不入库，->create()才真正写库；漏掉create()是最常被忽略的拼写错误 - 批量插入超 1000 条时，建议禁用模型事件：
User::withoutEvents(fn () => User::factory()->count(2000)->create())，否则每个模型都会触发creating等事件，拖慢速度甚至爆内存
tinker 里改了数据，关掉终端后发现没生效？
Laravel 7.0+ 开始，tinker 默认开启事务包裹所有操作。退出会话即回滚，这是防误操作的安全机制，不是 bug。
- 想让修改持久化，手动提交：
DB::commit() - 更稳妥的做法是把逻辑包进事务闭包：
DB::transaction(fn () => User::find(1)->update(['name' => 'test'])) - 别在 tinker 里调
Artisan::call('queue:work')或DB::select('SELECT SLEEP(5)')—— REPL 会卡死，无超时机制，只能强杀进程 - 修改模型类后，tinker 不会自动重载；用
reload命令（psysh 提供）或require_once重新载入文件；单例类需重启整个 tinker 会话
最易被忽略的一点：tinker 是调试工具，不是生产环境操作入口。它加载全部服务提供者，可能意外触发队列监听、缓存预热、事件广播等副作用——哪怕你只是敲了一行 User::count()。
