Laravel中非基于用户身份的业务操作权限控制最佳方案咨询

针对你遇到的场景——权限校验基于业务规则而非用户身份，Laravel 其实有几种灵活的实现方式，下面逐一分析并给出推荐方案：

方案一：直接将校验逻辑写入服务类 #

这是最直接的方式，因为业务规则本身属于业务逻辑的一部分，放在服务类里能保证逻辑内聚。比如在 EventService 的 cancelEvent 方法中：

namespace App\Services;

use App\Models\Event;
use App\Exceptions\BusinessRuleViolationException;

class EventService
{
    public function cancelEvent(Event $event)
    {
        $registeredCount = $event->registrations()->count();
        if ($registeredCount > 0) {
            throw new BusinessRuleViolationException("该事件已有{$registeredCount}名用户报名，无法取消");
        }

        // 执行取消事件的逻辑
        $event->update(['status' => 'cancelled']);
    }
}

然后在控制器中调用服务类，通过捕获异常返回响应：

namespace App\Http\Controllers;

use App\Models\Event;
use App\Services\EventService;
use App\Exceptions\BusinessRuleViolationException;
use Illuminate\Http\JsonResponse;

class EventController extends Controller
{
    public function cancel(Event $event, EventService $service): JsonResponse
    {
        try {
            $service->cancelEvent($event);
            return response()->json(['message' => '事件已取消']);
        } catch (BusinessRuleViolationException $e) {
            return response()->json(['error' => $e->getMessage()], 403);
        }
    }
}

优点：业务逻辑闭环，无需额外分层；缺点：如果多个控制器/场景需要调用取消逻辑，重复的异常捕获代码可能冗余，且无法在请求入口提前拦截。

方案二：创建不依赖用户的 Policies #

Laravel 的 Policies 并非强制要求接收用户参数，你可以定义不依赖用户的授权规则，在控制器层提前校验。比如创建 EventPolicy：

namespace App\Policies;

use App\Models\Event;

class EventPolicy
{
    public function cancel(?\Illuminate\Contracts\Auth\Authenticatable $user, Event $event): bool
    {
        // 忽略用户参数，仅校验业务规则
        return $event->registrations()->count() === 0;
    }
}

然后在控制器中调用 authorize 方法，同时自定义错误提示：

namespace App\Http\Controllers;

use App\Models\Event;
use App\Services\EventService;
use Illuminate\Http\JsonResponse;

class EventController extends Controller
{
    public function cancel(Event $event, EventService $service): JsonResponse
    {
        // 自定义授权失败的提示信息
        $this->authorize('cancel', $event, function () use ($event) {
            return "该事件已有{$event->registrations()->count()}名用户报名，无法取消";
        });

        $service->cancelEvent($event);
        return response()->json(['message' => '事件已取消']);
    }
}

需要注意的是，默认的授权失败会抛出 AuthorizationException，你可以在 app/Exceptions/Handler.php 中统一处理该异常，将自定义提示返回给前端：

use Illuminate\Auth\Access\AuthorizationException;

public function register(): void
{
    $this->renderable(function (AuthorizationException $e, $request) {
        if ($request->is('api/*')) {
            return response()->json(['error' => $e->getMessage()], 403);
        }
    });
}

优点：授权逻辑集中管理，控制器层代码更简洁；缺点：业务规则和授权逻辑分离，若规则复杂，可能需要在Policy和Service中重复校验（避免数据竞态）。

方案三：使用 FormRequest 做请求层校验 #

对于API场景，你可以自定义请求类，在请求层提前完成业务规则校验，这样能更早拦截非法请求：

namespace App\Http\Requests;

use App\Models\Event;
use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Validation\ValidationException;

class CancelEventRequest extends FormRequest
{
    public function authorize(): bool
    {
        // 若无需用户身份校验，直接返回true，或在这里加入业务规则校验
        return true;
    }

    public function rules(): array
    {
        return [];
    }

    public function withValidator($validator)
    {
        $event = $this->route('event');
        $registeredCount = $event->registrations()->count();
        if ($registeredCount > 0) {
            throw ValidationException::withMessages([
                'event' => ["该事件已有{$registeredCount}名用户报名，无法取消"]
            ])->status(403);
        }
    }
}

然后在控制器中使用该请求类：

namespace App\Http\Controllers;

use App\Models\Event;
use App\Services\EventService;
use App\Http\Requests\CancelEventRequest;
use Illuminate\Http\JsonResponse;

class EventController extends Controller
{
    public function cancel(CancelEventRequest $request, Event $event, EventService $service): JsonResponse
    {
        $service->cancelEvent($event);
        return response()->json(['message' => '事件已取消']);
    }
}

优点：请求层直接拦截，服务类只需专注核心业务；缺点：仅适用于HTTP请求场景，若服务类被其他非HTTP代码调用（比如命令行任务），则无法触发校验。

推荐实践 #

综合来看，服务类+自定义异常是最通用的方案，确保业务规则的权威性（即使被非HTTP场景调用也能触发校验）；同时可以结合Policy或FormRequest在入口层做前置校验，提升API的响应效率。

核心原则是：业务规则的最终校验必须放在服务类中（避免数据竞态，比如校验后到执行前的间隙有用户报名），入口层的校验只是为了提前返回友好提示。

内容的提问来源于stack exchange，提问作者charliefortune