我一直在用slim 3，最后终于明白了psr-7。现在使用laravel，我看到开箱即用，psr-7不支持。
现在…是否有强烈的理由遵循psr-7或laravel请求样式?
例如，个人偏好并不是一个强有力的理由。
我只是不想用laravel请求类编写整个应用程序，这是IlluminateHttpRequest，只是在一年内发现我真的应该遵循psr-7标准。
短答: 没有
长答:
考虑PSR (PHP标准建议)的目的，以及你选择的框架的每个方面都遵循这些标准对你来说意味着什么。
Laravel没有提供开箱即用的PSR-7支持，因为构建其请求/响应系统的Symfony组件也不兼容PSR-7。事实上，这个组件经常出现在许多框架的核心，并且是在PSR概念流行之前编写的。
为了让Laravel——或者任何其他依赖于这个组件的框架——成为PSR-7兼容，它将不得不改变对Symfony HTTP基础组件的依赖，或者甚至可能推出自己的实现。
记住，所有的PSR建议都只是建议。
它们都不是必需的。
它们的唯一目的是帮助将PHP编写统一为更可预测的格式，以便所有至少熟悉这些标准的PHP开发人员能够遵循并更容易理解遵守的每个代码库。
没有令人信服的理由重构任何代码库或框架的合理复杂性，使其符合psr
就像你自己说的，个人偏好不足以成为彻底检查代码库的理由。
对于您的用例，您需要问自己一个符合PSR-7的框架比一个不符合PSR-7的框架能为您实现什么。问题不在于可维护性，因为遵循psr的代码并不比不遵循psr的代码更可维护性。
如果您正在编写一个API，其中需要完全控制请求/响应生命周期，那么可能最好使用PSR-7兼容的框架，例如Slim。如果你正在编写一个通用的应用程序，在这个应用程序中，你唯一关心的请求和响应是一些AJAX和JSON路由，那么你可能会对Laravel或Lumen感到满意。
不要过于纠结于给定的框架是否符合图，只要做你的研究，并确保你选择的工具集最适合你的需要。