laravel 项目重构核心是解耦与职责分离：将支付回调等业务逻辑移出 user 模型；用 action 类封装完整业务流程（如 upgradesubscriptionaction）；控制预加载深度与数量，禁用全局 with；验证逻辑统一交由 form request 处理；service 类须依赖契约/dto、无副作用、io 操作拆分；技术债需在每次 pr 前微调。
重构 Laravel 项目不是为了“看起来更现代”，而是防止某天 php artisan migrate 失败后，发现 User 模型里混着支付回调逻辑、Excel 导出和 Redis 清缓存三件事——这种耦合一旦形成，改一个字段就要 grep 全局、测五条路径、祈祷队列没卡住。
控制器暴肥：别让 update 方法承担决策责任
真实项目里，SubscriptionController@update 常干这些事：查用户余额、校验套餐变更规则、调 Stripe/Alipay、生成发票、发邮件、更新角色、触发 Webhook。这不是控制器该做的，是业务流程的完整切片。
拆解建议：
- 新建
UpgradeSubscriptionAction类，只接收User和Plan实例，返回Subscription或抛出明确异常（如InsufficientBalanceException） - 控制器里只剩 4–5 行：
$action->execute($user, $request->plan_id)+ try/catch + 响应构造 - 禁止在 Action 中直接调用
Auth::login()或request()->ip()；需要上下文就显式传参，或注入契约（如IpAddressResolver接口） - 测试时直接 new Action，mock 依赖服务，不用启动 HTTP 内核
Eloquent 查询失控：预加载不是加得越多越好
with(['user.profile', 'comments.user.avatar']) 看似优雅，但若 comments 平均每条带 3 个关联，100 条就是 300 次额外查询——预加载失效的本质是嵌套过深或未约束数量。
关键判断点：
PHP中文网提供Laravel 13.2.0版本下载，Laravel框架 是基于 PHP 8.3+ 的高性能框架，官方推荐通过 Composer 安装。它内置 AI SDK、JSON:API Resources 及原生向量搜索，支持属性驱动开发与队列路由，大幅提升开发效率。相比旧版，13.2.0 优化了缓存 TTL 管理与实时通信，无需 Redis 即可横向扩展。作为现代 Web 开发首选，它兼顾安全与极速体验，助您快速构建企业级应用。
- 用
withCount('comments')替代with('comments')，当只需要计数时 - 对列表页，用
limit()+with()组合，避免一次性拉取全部子集（如Post::with('user')->latest()->take(20)->get()） - 禁用模型级全局预加载（
protected $with = ['profile']），它会让每个User::find(1)都强制 JOIN 无关表 - 本地开发必开
barryvdh/laravel-debugbar，看到单页 >15 条查询就该停下手头功能，先查 N+1
验证裸奔：别在控制器里写 if (!filter_var(...))
把邮箱格式校验、手机号唯一性、密码强度规则全塞进 store() 方法里，等于把业务规则和 HTTP 协议细节焊死。下次加个「邀请码必填」就得改三处控制器、两处前端 JS、一个测试文件。
落地做法：
- 运行
php artisan make:request StoreUserRequest，在rules()里写['email' => 'required|email|unique:users'] - 复杂规则抽成自定义 Rule 类（如
ValidInvitationCode），复用到 API 和后台管理请求中 -
authorize()方法里做权限检查，比如return $this->user()->can('create', User::class)，非法请求根本进不了控制器 - 避免在 Request 类里调用
DB::table()或模型方法；验证逻辑必须无副作用、可独立单元测试
Service 类设计：别让它变成“第二个控制器”
很多团队提取了 UserCreationService，但里面仍调 request()->file('avatar')、Mail::to(...)->send()、Auth::user()——这没解决问题，只是把泥巴从锅里舀到碗里。
真正可维护的 Service 特征：
- 构造函数参数全是契约或 DTO（如
UserRegistrationDto $dto），不接受Request或Response - 文件上传、邮件发送、第三方 API 调用等 IO 操作，拆成独立小 Service（
AvatarUploader、WelcomeEmailSender），方便 stub 和替换 - 不直接操作 Session 或 Auth 门面；登录动作由控制器或专门的
LoginService完成，本类只返回User实例 - 所有方法返回值明确（
User、void、Result对象），不隐式修改全局状态
最常被忽略的一点：技术债不是等“重构周期”才处理的专项任务。它藏在每次 git commit -m "fix bug" 顺手加的三行 if 判断里，也藏在为赶上线而跳过的 phpunit 测试里。真正的清理节奏，是每次 PR 合并前，花 90 秒看一眼新增代码是否又把本该属于 Service 的逻辑塞进了控制器——这种微小的克制，比半年一次的大重构更有效。
