在 laravel 中，重复的控制器逻辑（如通用 store 方法）应通过抽象基类、依赖注入与策略化请求验证来消除冗余，而非复制粘贴；本文提供可落地的 dry 实现方案，兼顾类型安全、请求验证隔离与扩展性。
为真正践行 DRY（Don’t Repeat Yourself）原则，控制器中高度相似的 CRUD 逻辑不应简单复制，而应通过泛型化基类 + 运行时绑定模型 + 动态请求解析实现复用。你提出的 MainController 思路方向正确，但原始实现存在关键缺陷：无法静态指定请求类（导致 IDE 无提示、类型检查失效）、$this-youjiankuohaophpcnmodel 赋值时机不安全（构造函数中实例化模型违反依赖倒置），且缺乏对请求验证契约的统一支持。
✅ 推荐方案：使用 抽象资源控制器 + 模型绑定 + 请求类反射解析
首先，定义一个泛型基类，强制子类声明模型类名与对应表单请求类：
<?php
// app/Http/Controllers/ResourceController.php
namespace App\Http\Controllers;
use Illuminate\Foundation\Auth\Access\AuthorizesRequests;
use Illuminate\Foundation\Bus\DispatchesJobs;
use Illuminate\Foundation\Validation\ValidatesRequests;
use Illuminate\Http\Request;
use Illuminate\Routing\Controller as BaseController;
abstract class ResourceController extends BaseController
{
use AuthorizesRequests, DispatchesJobs, ValidatesRequests;
/**
* @return string 模型完整命名空间，如 'App\Models\Post'
*/
abstract protected function modelClass(): string;
/**
* @return string 对应的 Form Request 类名，如 'App\Http\Requests\StorePostRequest'
*/
abstract protected function requestClass(): string;
public function store(Request $request)
{
$requestClass = $this->requestClass();
$validated = app($requestClass)->validated();
$model = app($this->modelClass())->create($validated);
return response()->json(['message' => 'Successfully created'], 201);
}
}然后，在具体控制器中精准声明契约：
<?php
// app/Http/Controllers/FirstController.php
namespace App\Http\Controllers;
use App\Http\Requests\StoreFirstRequest;
use App\Models\First;
class FirstController extends ResourceController
{
protected function modelClass(): string
{
return First::class;
}
protected function requestClass(): string
{
return StoreFirstRequest::class;
}
}<?php
// app/Http/Controllers/SecondController.php
namespace App\Http\Controllers;
use App\Http\Requests\StoreSecondRequest;
use App\Models\Second;
class SecondController extends ResourceController
{
protected function modelClass(): string
{
return Second::class;
}
protected function requestClass(): string
{
return StoreSecondRequest::class;
}
}? 关键优势说明：
- ✅ 类型安全 & IDE 友好：modelClass() 和 requestClass() 返回 string，配合 PHPStan/PHPStorm 可精准推导模型与请求类；
- ✅ 请求验证解耦：每个控制器仍使用专属 FormRequest，保留独立规则、消息与授权逻辑（如 authorize() 方法）；
- ✅ 符合 Laravel 习惯：不破坏路由模型绑定、中间件、资源控制器等生态；
- ✅ 可扩展性强：后续可轻松添加 index()、update() 等通用方法，并支持 withTrashed()、withoutEvents() 等策略钩子。
⚠️ 注意事项：
- 避免在基类中硬编码响应结构。如需统一响应格式（如 {"data": {}, "meta": {}}），建议封装为 ApiResourceResponse 类（如答案中提到的 YourCustomResponse::success()），并在基类中调用，而非直接写死 response()->json(...)；
- 若模型需特殊创建逻辑（如关联赋值、状态机流转），应在模型自身 create() 或 fill() 后置钩子中处理，而非污染控制器；
- 不推荐用 __construct() 注入模型实例（如 $this->model = new First()），这会阻碍测试 Mock 和依赖注入容器管理——始终优先使用 app($class) 或构造器注入。
总结：DRY 不等于“写一次、到处继承”，而是在抽象层级上识别稳定契约（模型+请求），将变化点（业务规则、权限、响应形态）保留在具体子类或独立服务中。上述方案既消除了 90% 的模板代码，又为未来演进（如增加审计日志、事件广播）预留了清晰的扩展入口。
