Laravel 默认用自增整型ID而非UUID，是因权衡查询性能、索引大小、分页稳定性与外键成本；UUID虽防曝号、适配分布式，但增大索引、拖慢JOIN和范围查询。
为什么 Laravel 默认不用 UUID 作主键
Laravel 默认用自增整型 id，不是因为设计懒，而是权衡了查询性能、索引大小、分页稳定性与外键关联成本。UUID 或 Snowflake 类 ID 虽能避免暴露业务量、支持分布式写入，但会显著增大索引体积，拖慢 JOIN 和范围查询（比如 WHERE id > 1000）。如果你没遇到分库分表、多中心写入或安全曝号问题，强行换 UUID 反而增加维护负担。
在 Migration 中启用 UUID 主键的实操要点
使用 uuid 类型需配合数据库驱动支持：MySQL 5.7+ 推荐用 CHAR(36) 或 BINARY(16) 存储；PostgreSQL 直接用 UUID 类型更稳妥。Laravel 9+ 内置了 uuids() 方法，但要注意它默认不设为主键，也不加索引：
Schema::create('posts', function (Blueprint $table) {
$table->uuid('id')->primary(); // 必须显式声明 primary()
$table->string('title');
$table->timestamps();
});
常见错误包括：$table->uuid('id')->primary()->unique() 多余加 unique()（主键已唯一）；或漏掉 ->primary() 导致迁移成功但模型插入失败（报错 SQLSTATE[HY000]: General error: 1364 Field 'id' doesn't have a default value）。
模型中如何让 create() 自动生成 UUID
只需在模型里设置 $keyType = 'string' 并重写 boot()，用 static::creating() 拦截新建逻辑。不要依赖构造函数或访问器——它们不参与批量插入或工厂创建：
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
class Post extends Model
{
protected $keyType = 'string';
public $incrementing = false;
protected static function boot()
{
parent::boot();
static::creating(function ($model) {
if (empty($model->{$model->getKeyName()})) {
$model->{$model->getKeyName()} = (string) Str::uuid();
}
});
}
}
注意点：Str::uuid() 返回的是 Illuminate\Support\Stringable 对象，必须转成 (string)；若用 ramsey/uuid 库的 Uuid::uuid4()->toString()，也得确保类型是字符串；否则 MySQL 可能截断或报错 Data too long for column 'id'。
用 Snowflake 替代 UUID？Laravel 原生不支持，但可轻量接入
Laravel 没内置 Snowflake 生成器，但可通过包（如 spatie/laravel-snowflake）或自己封装一个 SnowflakeIdGenerator 类。关键不是“能不能用”，而是你是否真的需要毫秒级有序性 + 机器位隔离。大多数中小项目用 UUID 完全够用；真上 Snowflake，就得自己处理时钟回拨、节点 ID 分配、以及迁移历史中旧 ID 的兼容逻辑——比如已有 100 万条自增 ID 数据，新记录混用 Snowflake，ORDER BY id DESC 就不再天然按时间倒序。
真正容易被忽略的，是软删除字段（deleted_at）和 UUID 主键组合时，全局作用域或 withTrashed() 查询不会出错，但如果你写了 whereRaw('id IN (?)', [$ids]) 却传入整数数组，就会静默失败——因为 UUID 是字符串，类型不匹配不报错，只查不到结果。
