使用Laravel Cashier实现用户单服务器对应单订阅的多订阅方案咨询

方案选型对比 #

方案1：User模型挂载Billable，订阅metadata存储server_id #

• 你提到的将server_id写入Stripe订阅metadata字段的方案完全可行，Stripe对metadata的存储限制完全满足该场景的需求
• 实现要点：
  • 订阅创建时必须携带对应服务器ID，参考写法：

    $server = auth()->user()->servers()->create([
        'title' => $title,
        'username' => $username,
        // 其他服务器配置字段
    ]);
    
    return auth()->user()->newSubscription('default', $对应套餐价格ID)
        ->metadata(['server_id' => $server->id])
        ->checkout();
    

  • 可以在本地的subscriptions表中冗余添加server_id字段，避免每次都要解析Stripe返回的metadata，提升关联查询效率
  • 统一账单门户可以直接使用Cashier原生的billingPortalUrl()方法，用户可以在同一个门户内看到名下所有订阅，直接对对应服务器的订阅执行续费、取消、更换套餐等操作
• 优势：原生适配Cashier的账单门户逻辑，不需要额外做适配开发，维护成本更低

方案2：Server模型挂载Billable #

• 该方案同样可落地，只需要给Server模型引入Billable trait，同时在Server模型中添加user_id外键关联对应用户即可
• 你提到的链式调用写法基本可行，调整后参考：

  return auth()->user()->servers()->create($服务器参数数组)
      ->newSubscription('server-sub', $对应套餐价格ID)
      ->checkout();
  

• 统一账单门户需要额外开发：由于Cashier原生账单门户是针对Billable模型生成的，你需要在用户中心页面聚合所有属于该用户的Server的账单入口，或者自定义账单门户路由，通过Stripe API拉取所有归属该用户的订阅聚合展示即可
• 优势：订阅和服务器的绑定关系更直接，逻辑上更贴合一对一绑定的业务场景

选型建议 #

如果优先追求开发效率、不想额外自定义账单门户逻辑，选方案1更合适；如果希望订阅和服务器的关联逻辑更内聚，后续针对单服务器的订阅操作更简单，选方案2即可，两个方案都满足生产环境使用要求。

内容的提问来源于stack exchange，提问作者tews-nees