控制器负责请求处理与流程调度，应保持简洁，使用Form Request验证，调用模型或服务类并返回响应；模型专注数据操作与业务规则，封装访问器、查询作用域及实体相关逻辑；复杂跨模型逻辑应交由服务类协调，避免控制器臃肿和模型职责过载，实现清晰分层。
在Laravel开发中，控制器和模型之间的职责划分直接影响代码的可维护性和扩展性。很多开发者容易把所有逻辑塞进控制器，或者让模型变得臃肿不堪。正确的做法是明确各自角色：控制器负责流程控制与请求响应，模型专注数据逻辑与业务规则。
控制器：处理HTTP请求与流程调度
控制器的核心任务是接收请求、验证输入、调用合适的模型方法，并返回响应。它不应包含复杂的业务计算或数据库查询逻辑。
建议做法：- 使用Form Request类进行参数验证，保持控制器整洁
- 只调用模型或服务类的方法，不直接写SQL或处理复杂判断
- 返回视图、JSON或重定向等响应类型，不参与数据加工
例如，用户注册操作中，控制器应验证数据后调用User::register()，而不是自己处理密码加密、关联创建等细节。
模型：封装数据逻辑与业务规则
Eloquent模型不仅是数据库映射，更是业务逻辑的承载者。将与特定实体相关的操作放在对应模型中，能提升复用性和可读性。
适合放入模型的内容包括：注意避免让模型依赖HTTP相关功能（如session、request），否则会降低其通用性。
更复杂的场景：引入服务类
当逻辑涉及多个模型或外部API调用时，应创建专门的服务类来协调。这能防止控制器变胖，也避免模型承担跨领域职责。
典型适用情况：- 下单流程：扣库存、生成订单、发送通知
- 支付回调处理：验证签名、更新状态、触发后续动作
- 数据导入导出：解析文件、校验内容、批量保存
服务类通常放在app/Services目录下，通过依赖注入使用，保持单一职责原则。
总结：分层思维是关键
良好的架构不是靠框架决定的，而是由清晰的分层意识构建的。控制器像“指挥官”，决定做什么；模型是“专家”，知道怎么做；服务类则是“协调员”，处理跨部门事务。合理分配职责后，代码更容易测试、调试和迭代。
基本上就这些，不复杂但容易忽略。
