为何Laravel Fortify未采用MVC架构编写？开发者困惑

首先要明确：Laravel推崇MVC是针对业务应用开发的最佳实践，但官方工具类包（比如Fortify）会根据自身定位选择更适合的架构，这并非违背MVC核心，而是对职责分离的另一种实现。具体原因如下：

• Fortify的定位是底层认证组件，而非业务MVC实现
  Fortify的核心是提供原子化的认证操作（注册、登录、密码重置等），它不是直接给你一套完整的业务控制器，而是让你可以灵活调用这些操作。把逻辑放在Actions目录下而非控制器，是为了让这些认证逻辑可以在多个场景复用——比如你不仅可以在web路由里用，还能在API、控制台命令甚至队列任务里调用，这比把逻辑硬塞在控制器里更符合单一职责原则。

• Laravel的MVC是推荐范式而非强制约束
  MVC是Laravel给业务开发者的通用指导，但框架本身非常灵活。官方包会根据功能需求选择最适合的架构：比如Fortify专注于独立的认证逻辑，用Action模式（属于命令模式的一种）能更好地封装单一操作，避免控制器臃肿；而业务开发时，你依然可以遵循MVC，把请求接收、响应返回交给控制器，把数据库操作交给模型，同时调用Fortify的Actions完成认证逻辑。

• Fortify完全兼容MVC架构
  你完全可以把Fortify和传统MVC结合起来：比如在web.php里定义自己的认证路由，指向自定义的控制器，然后在控制器中调用Fortify的CreateNewUser、AttemptToAuthenticate等Action类来处理核心逻辑，最后由控制器返回视图或响应。这种方式既利用了Fortify的成熟认证逻辑，又保持了你熟悉的MVC代码结构。

• Action模式是对MVC职责分离的补充
  传统MVC里，控制器很容易变成“万能处理中心”，塞了太多业务逻辑。Fortify用Action模式把复杂的业务操作拆分成独立的类，其实是更严格的关注点分离——控制器只负责处理请求的入口和响应的输出，具体的业务逻辑（比如验证用户输入、创建用户）交给专门的Action类，这和MVC“控制器不处理核心业务”的原则是一致的，很多资深Laravel开发者也会在自己的项目中用这种模式来优化MVC结构。

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