Composer如何安装Laravel Cashier支付_Composer安装Laravel Cashier实践

搞定Lara vel Cashier支付：从安装到避坑的完整指南

在Lara vel项目里集成Stripe支付，composer require lara vel/cashier 这条命令只是起点。真正让支付流程跑起来，往往卡在后续几个关键步骤上：模型没引入Billable特质、数据库迁移没执行、STRIPE_SECRET环境变量配置有误，或者版本压根没对齐。这些环节任何一个出岔子，都会让整个支付功能“趴窝”。

安装命令与版本对齐

首先得明确一个原则：Cashier的主版本号与Lara vel框架的主版本是严格绑定的。如果你在2026年维护一个Lara vel 11.x的项目，那么必须指定安装Cashier v15或更高版本。

• 最稳妥的安装命令是：composer require lara vel/cashier:^15.0。显式指定版本可以避免Composer自动解析到不兼容的旧版本。
• 如果你的项目仍在使用Lara vel 10.x，则应安装lara vel/cashier:^14.0；对于Lara vel 9项目，请使用^13.0。
• 另外，不必手动去require stripe/stripe-php包。Cashier已经将其声明为依赖，重复安装反而可能引起自动加载冲突。
• 一个小提示：如果之前手动安装过旧版的Stripe SDK，最好先删除vendor/stripe/stripe-php目录，再执行Cashier的安装，以绝后患。

迁移没跑 = createAsStripeCustomer() 直接报错

当你兴致勃勃地调用$user->createAsStripeCustomer()，却遭遇一个Call to undefined method错误时，先别急着怀疑自己的代码。十有八九，问题出在数据库里——Cashier运行所必需的字段压根不存在。

• 对于Lara vel 11及更新版本，最省事的办法是直接运行php artisan cashier:install。这个命令会一次性完成迁移文件的发布和执行。
• 如果是Lara vel 10或更早的版本，则需要两步走：先执行php artisan vendor:publish --tag="cashier-migrations"发布迁移文件，再运行php artisan migrate来执行它们。
• 这些迁移会创建subscriptions、subscription_items、payment_methods等表。但关键在于，你的users表里必须要有stripe_id等字段。Cashier默认不会直接修改你的users表，要么自己手动添加字段，要么依赖cashier:install命令来自动处理。
• 如果项目已经上线并有用户数据，记得使用php artisan cashier:install --force命令来强制添加这些字段，避免数据丢失。

STRIPE_SECRET 配错或没生效，Webhook 和支付全挂

环境变量配置看似简单，却是“事故”高发区。.env文件里写了STRIPE_SECRET，但实际运行时它却是空的，这会导致一连串的失败：客户创建返回401、Webhook签名验证不通过，甚至在本地测试时Stripe SDK直接抛出未捕获的异常。

• 在.env文件中，务必确保格式正确：STRIPE_SECRET=sk_test_...。这里填的是以sk_开头的Secret Key，千万别误用了Publishable Key。
• 接着，检查config/services.php配置文件。确保stripe配置数组存在，并且key的拼写准确无误：'secret' => env('STRIPE_SECRET')。常见的笔误包括写成stripe_secret或STRIPE_API_SECRET。
• 修改.env后，一个容易被遗忘的步骤是清理配置缓存：php artisan config:clear。否则，config()函数读取的可能还是旧值。
• 最后，Webhook路由需要手动注册。如果忘记在路由文件中添加类似Route::post('/webhook/stripe', [\App\Http\Controllers\StripeWebhookController::class, 'handleWebhook']);的条目，那么Stripe发送的事件将永远触发404错误。

Billable trait 没加，所有订阅方法都不可用

即使数据库字段齐全、Stripe密钥也正确，当你调用$user->subscription('monthly')->create($paymentMethod)时仍然报错，那么问题很可能出在模型本身——它还没有被“赋能”为可支付对象。

• 你的User模型（或者任何你打算用来处理支付的模型），必须在类定义中引入Lara vel\Cashier\Billable这个Trait。具体来说，就是在文件顶部添加use Lara vel\Cashier\Billable;，然后在类内部使用use Billable;。
• 注意别漏了第一步。只写use Billable;而忘记引入对应的类，PHP会找不到这个Trait。
• 如果你使用了自定义的用户模型（例如App\Models\Customer），还需要在config/services.php的stripe配置中明确指定：'model' => \App\Models\Customer::class。
• 最后，检查一下你的模型是否继承了Illuminate\Foundation\Auth\User，或者至少实现了Authenticatable契约。否则，Cashier内部的一些守卫（Guard）检查可能会失败。

总而言之，Cashier的设计哲学是“非侵入式”的。它不会自动注册路由，不会自动给你的users表添加字段，也不会主动校验你的Stripe密钥格式是否正确。它只在第一次需要与Stripe API交互时（比如创建客户）才会真正发起连接。这意味着，如果你在线上环境错误地配置了密钥，问题可能一直潜伏，直到第一个用户点击“订阅”按钮时才突然爆发。因此，事前的完整检查和测试至关重要。