本文讲解如何在 laravel 中合理组织业务逻辑，通过模型访问器、队列任务与定时调度实现订阅过期提醒与自动续订功能，避免将业务规则硬编码在控制器或静态工具类中，提升可维护性与可测试性。
本文讲解如何在 laravel 中合理组织业务逻辑，通过模型访问器、队列任务与定时调度实现订阅过期提醒与自动续订功能，避免将业务规则硬编码在控制器或静态工具类中，提升可维护性与可测试性。
在 Laravel 项目中，“结构正确”不等于追求复杂分层，而是在清晰性、可复用性与框架约定之间取得平衡。针对订阅（Subscription）的过期提醒与自动续订这一典型业务场景，我们应将职责明确分离：数据状态判断交给模型（利用访问器），触发时机由调度器控制，执行动作交由队列任务处理。
✅ 推荐结构与实践
1. 模型层：用访问器封装状态逻辑
将“是否即将过期”这类基于属性的业务判断，移入 Subscription 模型中，使用 Eloquent 访问器（Attribute）配合 $appends 自动注入 JSON 响应，既保持语义清晰，又避免重复计算：
// app/Models/Subscription.php
use Illuminate\Database\Eloquent\Casts\Attribute;
use Illuminate\Database\Eloquent\Model;
class Subscription extends Model
{
protected $casts = [
'end_time' => 'datetime', // 自动转为 Carbon 实例，无需手动 new Carbon()
'created_at' => 'datetime',
'updated_at' => 'datetime',
];
protected $appends = ['is_expiring'];
protected function isExpiring(): Attribute
{
return Attribute::make(
get: fn () => $this->end_time->floatDiffInMonths(now()) <= 2
);
}
}⚠️ 注意：end_time 字段类型建议设为 DATETIME，$casts 中直接使用 'datetime' 即可获得完整 Carbon 实例（支持 floatDiffInMonths 等方法），无需指定格式；若数据库为 DATE 类型且无需时间精度，可用 'date'。
2. 任务层：用队列 Job 执行异步操作
创建专用 Job 处理批量检查与通知分发，符合“单一职责”原则，也便于失败重试与监控：
// app/Jobs/NotifyExpiringSubscriptions.php
<?php
namespace App\Jobs;
use App\Models\Subscription;
use App\Notifications\ExpiringSubscriptionNotification;
use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
class NotifyExpiringSubscriptions implements ShouldQueue
{
use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;
public function handle()
{
Subscription::where('status', 'active')
->chunkById(100, function ($subscriptions) {
foreach ($subscriptions as $subscription) {
if ($subscription->is_expiring) {
$subscription->notify(new ExpiringSubscriptionNotification());
}
}
});
}
}✅ 优化点：使用 chunkById() 替代 all()，避免内存溢出；添加 where('status', 'active') 过滤无效记录；通知类应继承 Notification 并实现 toMail() 等通道方法。
3. 调度层：用 Artisan Scheduler 定时触发
在 App\Console\Kernel 中定义每日执行策略，解耦时间控制与业务逻辑：
// app/Console/Kernel.php
protected function schedule(Schedule $schedule)
{
// 每天凌晨 2 点检查即将过期的订阅
$schedule->job(new NotifyExpiringSubscriptions)->dailyAt('02:00');
}运行 php artisan schedule:work（推荐配合 systemd 或 supervisor 后台守护），即可实现可靠、可追踪的定时任务。
❌ 应避免的做法
- 将 isExpiring() 写成静态辅助方法（如 SubscriptionHelper::isExpiring()）：破坏面向对象封装，难以 mock 测试，且无法享受模型生命周期钩子；
- 在控制器中直接调用 notifyExpiring() 或 renewExpired()：违反关注点分离，导致控制器臃肿且无法复用；
- 把续订逻辑（如扣款、更新状态）与通知混在同一 Job 中：应拆分为 RenewSubscription 和 NotifyExpiring 两个独立 Job，便于单独调试与重试。
✅ 总结
Laravel 的“正确结构”本质是让代码说清楚它该做什么、何时做、由谁做：
? 模型回答 “这个数据当前是什么状态？”（如 is_expiring）；
? Job 回答 “这件事该怎么一步步做？”（如查、判、通知、续订）；
? Scheduler 回答 “这件事什么时候该发生？”（如每天凌晨）。
这种分工天然支持单元测试（可单独测试访问器）、水平扩展（Job 可分发至多台 worker）和渐进演进（未来增加短信/站内信通道只需扩展 Notification 类）。
