控制器仅负责请求分发与数据流转，不处理业务逻辑；方法命名须遵循restful规范；校验须前置且解耦；响应构造须通过框架机制统一管理。
控制器只做请求分发和数据流转，不处理业务逻辑
PHP MVC 中的控制器（Controller）本质是「胶水层」——它不该包含数据库操作、算法计算、第三方 API 封装或状态校验规则。这些都该下沉到 Model 或 Service 层。常见错误是把 getUserById()、validateForm()、sendEmail() 直接写在控制器里，结果导致测试难、复用差、改动牵一发而动全身。
正确做法是控制器只做三件事：接收请求参数、调用对应服务/模型方法、返回响应（视图或 JSON）。比如用户登录请求，控制器只负责：$credentials = $request->only('email', 'password'); → $user = $authService->login($credentials); → return response()->json($user);
方法命名必须映射 HTTP 动词 + 资源动作
控制器方法名不是随便起的，它直接反映 RESTful 路由语义和前端调用意图。Laravel 默认约定、CodeIgniter 扩展、或自研框架都应遵守这个逻辑，否则路由配置和团队协作会混乱。
-
index()对应GET /users（列表） -
show($id)对应GET /users/{id}（单条） -
store(Request $request)对应POST /users（创建） -
update(Request $request, $id)对应PUT/PATCH /users/{id}（更新） -
destroy($id)对应DELETE /users/{id}（删除）
避免出现 handleLogin()、doExport() 这类模糊命名；也不要为一个接口写多个方法（如 getUsersByStatus() 和 getUsersByDate()），应统一走 index() + 查询参数过滤。
立即学习“PHP免费学习笔记（深入）”；
输入校验必须前置，且与业务逻辑解耦
控制器里的校验不是用 if (!isset($_POST['email'])) 手动判断，而是交由框架机制完成：Laravel 用 FormRequest 类，ThinkPHP 用验证器类，原生可封装 Validator::make()。关键点在于——校验失败必须中断执行并返回明确错误，不能让无效数据流入后续流程。
常见坑：
• 把校验逻辑混在控制器方法体内，导致重复代码
• 校验通过后又手动改写 $_POST 或 $request 数据，破坏原始输入可信度
• 使用 filter_var() 做业务级校验（比如“密码必须含大小写字母”），这属于领域规则，该进 Service
class StoreUserRequest extends FormRequest
{
public function rules()
{
return [
'name' => ['required', 'string', 'max:255'],
'email' => ['required', 'email', 'unique:users'],
'password' => ['required', 'confirmed', 'min:8'],
];
}
}
响应构造要收敛，禁止在控制器拼 HTML 或 JSON 字符串
控制器不该出现 echo json_encode([...]) 或 include 'user_list.php'。所有输出必须经由框架响应机制：Laravel 的 response()、view()、redirect()；ThinkPHP 的 $this->success() / $this->fetch()；原生可封装 JsonResponse 类。否则会导致 Content-Type 错误、HTTP 状态码丢失、缓存头缺失等问题。
特别注意：
• AJAX 请求返回 JSON 时，确保设置了 Content-Type: application/json
• 表单提交成功后重定向（PRG 模式），避免刷新重复提交
• 错误响应统一用 4xx/5xx 状态码，不要全用 200 + { "code": 1 } 模拟
最易被忽略的是响应头控制——比如文件下载需设置 Content-Disposition，API 需加 Access-Control-Allow-Origin，这些都在响应对象上配，不在控制器里 echo。
