直接在模型中声明protected $table = ‘表名’即可覆盖laravel默认的复数推导逻辑，注意属性名必须为$table且值为字符串；统一规则可重写gettable()方法；动态切表慎用settable()，避免连接池污染。
直接在模型里改 $table 属性就行
Laravel 默认按模型类名的复数形式推导表名（比如 User → users），但实际项目中经常要对接旧库或命名不规范的表。最简单、最常用的方式就是显式声明 $table 属性。
常见错误是写成 $tableName 或 $table_name —— Laravel 只认 $table 这个固定属性名，拼错就无效，依然走默认推导逻辑。
class UserProfile extends Model { protected $table = 'user_profiles'; }- 值必须是字符串，不能是变量或表达式（比如
env('USER_TABLE')会报错，得用构造函数或静态方法处理） - 如果表名带数据库前缀（如
prefix_users），这里也得写全，Laravel 不会自动拼接DB_PREFIX
想让多个模型共用一套表名规则？重写 getTable() 方法
当项目里有十几张表都按 wp_ 开头，或者全部加 _archive 后缀时，一个个改 $table 太重复。这时候可以覆盖模型的 getTable() 方法，统一干预生成逻辑。
注意：这个方法在模型实例化早期就会被调用，所以别在里面做耗时操作（比如查配置表）。也别依赖未初始化的属性（比如 $this->connection 可能还为 NULL）。
- 在基类模型里重写：
public function getTable() { return 'wp_' . parent::getTable(); } - 如果只对某类模型生效，加判断：
if (str_starts_with($this->getModel(), 'Log')) { return $this->getModel() . '_history'; } - 返回值必须是字符串，返回
null会导致后续 sql 报错SQLSTATE[42S02]: Base table or view not found
迁移文件和模型表名不一致？先确认是否真需要改模型
有时候你发现迁移建的是 user_settings，但模型叫 UserPreference，下意识就想改 $table。其实更可能是命名没对齐，而不是技术问题。
真正该改模型表名的场景只有三种：对接遗留系统、多租户分表、读写分离的从表。其他情况建议优先调整模型命名或迁移文件，避免后续查文档、协作、ide 跳转都变别扭。
- 检查迁移里是否用了
Schema::create('user_preferences', ...)，但模型却叫UserSetting—— 这属于语义错位，不是技术限制 - 如果只是想“看起来顺眼”，别动
$table；如果业务上这张表确实承担了UserPreference的职责，那就该改迁移，而不是迁就模型 - 改完
$table后记得跑一遍php artisan tinker，执行UserPreference::first()看日志里生成的 SQL 是否真用了你写的表名
使用 setTable() 动态切表？小心作用域和连接池污染
$model->setTable('logs_202410') 确实能临时换表，但它是实例级操作，只影响当前对象。很多人误以为设一次就能全局生效，结果在循环里反复 new 模型却忘了设，或者在队列任务里拿到复用的模型实例，表名还是上一次的。
更隐蔽的问题是：Eloquent 内部缓存了表名到连接的映射，动态改表后如果连接没切换，可能复用旧连接的 prepared statement，导致字段不匹配或权限错误。
- 适合场景极少：比如单次导出历史分表数据，且明确知道不会复用该模型实例
- 千万别在作用域（
globalScopes）或观察者里调用setTable()，会污染整个请求生命周期 - 如果真要分表，优先考虑封装一个工厂方法：
LogModel::forMonth('2024-10')，每次返回新实例
模型表名看着小，但改错位置、改错时机、改错范围，都会让查询悄无声息地落到别的表上——尤其是线上环境没有明显报错，只丢数据。