Tinker 是 Laravel 自带的 REPL 工具，本质是基于 psysh 的增强版 PHP 交互式终端，启动即注入完整应用上下文，支持直接调用 Eloquent、Facade、Config、容器绑定类等；它不加载于 php -a，也无需反复启停，但不支持多行函数定义，需注意命名空间、事务安全及环境隔离。
Tinker 是 Laravel 自带的 REPL 工具，本质就是个增强版的 PHP 交互式终端，能直接调用 Eloquent、Service、Config 等所有 Laravel 运行时上下文里的东西——只要项目能正常启动，tinker 就能访问到几乎全部应用逻辑。
为什么 tinker 比 php -a 或手动写测试文件更高效
因为 php -a 不加载 Laravel 的服务容器、不初始化数据库连接、不读取配置；而写临时测试文件又得反复 php artisan tinker → exit → 改文件 → 再进，效率极低。tinker 启动即注入完整 App 实例，AppModelsUser::first()、config('app.debug')、resolve(AppServicesPaymentService::class) 全部开箱可用。
- 执行一次
php artisan tinker后，所有 Facade、模型、门面、绑定在容器里的类都可直接调用 - 支持命令历史（上下键翻阅）、语法高亮（依赖 psysh）、自动补全（按 Tab）
- 不支持运行多行函数定义或 class 声明（会报
SyntaxError: unexpected 'function'），但支持闭包和链式调用 - 若项目启用了 Horizon 或队列监听，tinker 会继承当前环境的配置（比如
QUEUE_CONNECTION=redis会影响dispatch()行为）
tinker 报错 “Class 'App\Models\xxx' not found” 怎么办
这是最常见的路径/命名空间问题，不是 tinker 本身故障。Laravel 8+ 默认启用模型目录迁移，但 composer.json 的 autoload 配置可能没同步更新。
- 检查模型文件是否真在
app/Models/下，且命名空间是namespace AppModels; - 运行
composer dump-autoload强制重载自动加载映射（尤其改过文件位置或命名空间后） - 如果模型用了自定义命名空间（如
AppEntitiesUser），必须用完整命名空间调用：AppEntitiesUser::count()，不能只写User::count() - 别在 tinker 里用
use AppModelsUser;—— psysh 不支持交互式 use 声明，会直接报错
如何在 tinker 中安全执行修改数据库的操作
tinker 默认没有事务保护，User::where('id', 1)->delete() 是立刻生效的。开发环境可接受，但连着生产数据库调试等于裸奔。
- 进 tinker 前先确认当前环境：
app()->environment()，输出"production"就该立刻退出 - 敏感操作前加一层手动事务：
DB::transaction(function () { User::where('active', 0)->delete(); });，出错会自动回滚 - 批量更新建议先用
->toSql()看生成的 SQL：User::where('status', 'pending')->update(['status' => 'processed'])->toSql()（注意：update()方法本身不返回 Builder，要写成User::where(...)->getQuery()->toSql()） - 避免在 tinker 中调用含事件监听的删除（如
$user->delete()），容易触发未预期的 Observer 或队列任务
真正麻烦的不是怎么进 tinker，而是忘记它默认共享整个应用生命周期——缓存、队列连接、HTTP 客户端实例、甚至 session（如果用了 file 驱动）都会被复用。一次 Cache::put('test', 'x') 可能在下次请求里还存在，别当成“临时沙盒”来用。
