我目前正在对我的角色、权限和路线进行一次小型重构，并问自己同样的问题。
从表面上看，真正的中间件和策略似乎执行相同的总体思路。检查用户是否可以做他们正在做的事情。
作为参考，这里是 laravel 文档...
中间件“我可以看看这个吗？我可以去这里吗？”
HTTP中间件提供了一种便捷的HTTP过滤机制
请求输入您的应用程序。例如，Laravel 包括
验证应用程序用户的中间件是
已验证。如果用户未通过身份验证，中间件将
将用户重定向到登录屏幕。但是，如果用户是
经过身份验证后，中间件将允许请求继续进行
进一步进入应用程序。
当然，可以编写额外的中间件来执行各种操作
除了身份验证之外的任务。 CORS 中间件可能是
负责为所有离开的响应添加正确的标头
你的申请。日志中间件可能会记录所有传入请求
到您的应用程序。
https://laravel.com/docs/master/middleware#introduction https://laravel.com/docs/master/middleware#introduction
在我的阅读中，中间件是关于在请求级别进行操作的。在“这个用户可以see页面？”，或“该用户可以在这里执行某些操作吗？”
如果是这样，它将转到与该页面关联的控制器方法。有趣的是，中间件可能会说：“是的，你可以去那里，但我会写下你要去的地方。” ETC。
一旦完成。它不再控制或说明用户正在做什么。我将其视为中间人的另一种方式。
Policies“我可以这样做吗？我可以改变这个吗？”
除了提供开箱即用的身份验证服务之外，
Laravel 还提供了一种简单的方法来组织授权逻辑和
控制对资源的访问。有多种方法和方法
帮助您组织授权逻辑的助手，以及
我们将在本文档中介绍它们中的每一个。
https://laravel.com/docs/master/authorization#introduction https://laravel.com/docs/master/authorization#introduction
然而，政策似乎更关心doing。用户可以更新任何条目，还是只能更新自己的条目？
这些问题似乎适合控制器方法，其中组织了对资源的所有操作调用。检索该对象、存储或更新文章。
As tjbb 提到 https://stackoverflow.com/a/35028244/723255/，中间件会使路由变得非常混乱并且难以管理。这是我的路线文件中的示例：
问题
Route::group(['middleware' =>'role:person_type,person_type2',], function () {
Route::get('download-thing/{thing}', [
'as' => 'download-thing',
'uses' => 'ThingController@download'
]);
});
这在我的路线文件中很难阅读！
另一种政策方法
//ThingController
public function download(Thing $thing)
{
//Policy method and controller method match, no need to name it
$this->authorize($thing);
//download logic here....
}
