资源方法必须严格使用index、show、store、update、destroy标准CRUD名称，因Route::resource()仅识别这组固定名；改名将导致模型注入失败、Request对象丢失；非资源查询方法应采用getRecentActiveUsers等动词+名词结构，避免getData等模糊命名。
资源方法必须用标准 CRUD 名字
只要控制器是通过 php artisan make:controller --resource 生成的，就该严格使用 index、show、store、update、destroy 这五个名字。别写成 list、view 或 delete —— Laravel 的资源路由（Route::resource()）只认这组固定名称，改了就断掉绑定，show 方法收不到模型实例注入，store 也拿不到自动验证的 Request 对象。
查询方法用动词+名词结构
非资源方法，比如查“最近三天活跃用户”，名字得让人一眼看懂意图，而不是猜逻辑。推荐格式：getRecentActiveUsers、findUnverifiedEmails、searchByTag。避免模糊命名如 getData、handle、process —— 它们在控制器里几乎等于没写注释。
常见错误现象：
- 多个类似方法都叫 getData，靠参数区分，结果 IDE 跳转失效，grep 搜不到上下文
- 方法名带下划线（get_user_list），违反 Laravel 默认的驼峰约定，和框架其他方法风格割裂
业务动作方法要体现“谁在做什么”
控制器不该写业务逻辑，但若临时需要一个入口点（比如后台触发重发邮件），方法名应明确主体和动作：resendVerificationEmail、forceApproveApplication。不建议：doAction、runTask、exec。
容易踩的坑：
- 把复杂流程塞进控制器方法，比如 syncUserWithExternalApiAndNotifyAdmin —— 这名字太长，说明它该拆到服务类里
- 名字含条件分支信息，如 getProfileForAdminOrUser —— 控制器职责是分发，不是判断，这种逻辑应交给中间件或策略类
访问器和修改器必须严格按 Laravel 规则命名
模型里的访问器/修改器不是控制器方法，但常被误放在控制器里。如果真要在控制器暴露格式化字段，必须用视图 composer 或响应 DTO，而不是手写 getFullName 这类方法。真要定义访问器，只能写在模型中，且格式固定：getFullNameAttribute（访问器）、setPasswordAttribute（修改器）。控制器里出现这类命名，基本等于架构错位。
性能影响：在控制器里手动拼接字符串（如 return $user->first_name . ' ' . $user->last_name）看似简单，但重复出现在多个方法中时，会失去复用性和测试覆盖点；而模型访问器会被 Eloquent 自动缓存，且可被 API 资源类统一调用。
