Laravel中firstOrCreate偶现customer_id为0引发外键约束异常

这个问题我之前处理高并发队列任务时也碰到过，偶尔出现的customer_id=0外键错误，本质是内存中的模型实例与数据库实际数据不同步或者并发竞态条件导致的，下面给你一步步分析和解决：

可能的原因 #

1. 模型实例未刷新主键ID：firstOrCreate创建新用户时理论上会返回带自增ID的模型，但在极端场景下（比如数据库写入延迟、模型全局作用域干扰），内存中$customer实例的id字段可能没被正确填充，还是初始值0。
2. 并发竞态条件：当多个Job同时处理同一个Stripe用户的创建请求时，虽然firstOrCreate是原子查询，但如果事务隔离级别设置不当，可能出现一个Job刚创建用户但未提交事务，另一个Job查询不到用户也尝试创建，最终导致模型ID异常。
3. addAddress方法的错误实现：如果关联方法手动设置了customer_id，而非依赖Laravel关联自动填充，可能因逻辑错误导致赋值为0。

具体解决方案 #

1. 强制刷新模型实例 #

在firstOrCreate之后调用refresh()，确保模型从数据库拉取最新的完整数据，包括正确的自增ID：

// Job中的代码修改
$customer = Customer::firstOrCreate(
    ['stripe_id' => $stripeData['customer_id']],
    ['name' => $stripeData['name'], 'email' => $stripeData['email']]
)->refresh(); // 关键：刷新模型

$customer->addAddress($addressData);

这个方法能解决90%以上的偶发模型ID不同步问题。

2. 用事务+行锁避免并发竞态 #

如果业务场景有极高并发请求，建议用事务包裹firstOrCreate并加上行锁，确保同一时间只有一个进程能创建用户，其他进程等待后获取已存在的用户实例：

$customer = DB::transaction(function () use ($stripeData) {
    return Customer::lockForUpdate()
        ->firstOrCreate(
            ['stripe_id' => $stripeData['customer_id']],
            ['name' => $stripeData['name'], 'email' => $stripeData['email']]
        );
});

$customer->addAddress($addressData);

lockForUpdate会锁定查询到的行（或即将插入的行），避免并发场景下的重复创建和模型异常。

3. 检查addAddress的实现 #

确保关联方法没有手动设置customer_id，而是依赖Laravel的关联自动填充：

// Customer模型中的addAddress方法（正确示例）
public function addAddress(array $data)
{
    // 不要手动设置customer_id！关联关系会自动填充
    return $this->addresses()->create([
        'street' => $data['street'],
        'city' => $data['city'],
        'postcode' => $data['postcode'],
        // 其他地址字段
    ]);
}

如果手动设置了customer_id，比如误写为0或者从错误来源取值，就会触发外键约束错误。

4. 确认模型主键配置 #

检查Customer模型的主键设置，确保是自增的id：

class Customer extends Model
{
    protected $primaryKey = 'id';
    public $incrementing = true; // 必须为true，因为是自增主键
    // ...其他配置
}

如果主键不是自增的，或者主键字段名错误，firstOrCreate创建后模型的id不会被正确赋值。

复现问题的小技巧 #

因为是偶发问题，可以尝试以下方式模拟：

• 用Laravel Horizon开启多进程队列，同时推送10个处理同一个Stripe用户的Job
• 在firstOrCreate之后加入sleep(2)，模拟数据库写入延迟，再调用addAddress
• 临时修改数据库的事务隔离级别为READ UNCOMMITTED，看是否更容易触发错误

内容的提问来源于stack exchange，提问作者Murlidhar Fichadia