分层架构实践：Controller层该做参数校验还是业务校验？

最近重构老项目时发现，团队对Controller层的职责划分特别混乱。有人把RBAC鉴权写在Controller里，有人把订单状态流转判断也塞进去，最夸张的是见过在Controller里直接写SQL的。今天结合实战案例聊聊我的分层心得。

1. 参数校验必须死在Controller层 表单验证、必填字段检查、参数类型转换这些就该在Controller层解决。用框架自带的验证器或者单独写校验逻辑都行，但千万别让非法参数溜进Service层。上周就因为一个没做intval的ID参数，导致整个库存查询接口被刷爆。

2. 业务规则校验必须下沉 像「用户余额是否充足」「商品是否下架」这类业务规则判断，一定要放到Service层。Controller只关心「要检查什么」，Service负责「怎么检查」。这样做单元测试时才能Mock服务层，否则Controller里一堆业务逻辑根本没法测。

3. 跨模块调用要用事件解耦 遇到需要更新用户积分又要发通知的情况，不要在Controller里连续调用两个Service。正确的做法是Controller触发「订单创建」事件，让积分服务和通知服务各自监听。这样改活动规则时就不用动Controller代码了。

实际项目中，我习惯在Controller方法里不超过20行代码。超过这个数就要考虑是不是把业务逻辑泄露到上层了。你们团队的分层规范是怎样的？欢迎交流踩坑经验。