laravel 的优势在于约定优于配置，如 php artisan make:controller 自动生成符合 psr-4 和框架规范的代码，auth::user() 由中间件预加载用户实例，user::create() 与 save() 语义明确且事件行为可预期，blade 的 @include 与 @component 职责分离，所有操作默认就绪、不卡壳、不翻文档。
Laravel 的优势不是靠堆砌功能列表体现的，而是当你在写 Route::get、User::create、php artisan migrate 这些操作时，发现它默认就做了该做的事——不卡壳、不报错、不翻文档十次才配对一个中间件。
为什么 php artisan make:controller 能直接跑起来
因为 Laravel 在生成控制器时，已经预设了命名空间、继承 Controller 基类、引入了 use IlluminateHttpRequest，连构造函数里该绑定哪些依赖都留好了钩子。你不用手动补 __construct() 或查 PSR-4 自动加载规则。
常见错误现象：Class AppHttpControllersUserController does not exist —— 很可能只是文件名是 usercontroller.php（缺大写 C）或没放在 app/Http/Controllers/ 下；Laravel 不会自动猜路径，它只认约定位置。
- 生成带资源路由的控制器：用
php artisan make:controller UserController --resource - 想跳过
__invoke方法模板？加--invokable参数 - 如果项目启用了 PSR-4 自定义命名空间（比如改了
"App\"为"Domain\"），那make:controller仍按默认路径生成，需手动调整命名空间和composer.json
Auth::user() 为什么不用自己写 session 判断
Laravel 把认证逻辑下沉到中间件层，auth 中间件会在每次请求时检查 session 或 token，并把用户实例塞进 Request 对象和门面（Facade）里。你调 Auth::user() 实际是调 AuthManager 从容器里取已解析好的实例，不是每次都查数据库。
使用场景差异：
- Web 请求走 session，默认用
web中间件组，Auth::user()返回当前登录用户 - API 请求走 token（如 Sanctum），得用
auth:sanctum中间件，否则Auth::user()永远为 null - 在命令行（Artisan）里调用
Auth::user()？不行——没有 HTTP 上下文，session 或 token 都不存在
Eloquent 的 save() 和 create() 到底差在哪
create() 是静态方法，内部调了 new static + fill() + save()；save() 是实例方法，只做插入或更新，不处理批量赋值白名单（$fillable）校验以外的逻辑。
容易踩的坑：
-
User::create(['name' => 'A', 'email' => 'a@b.c'])会忽略模型里未列入$fillable的字段，但不会报错——静默丢弃 -
$user = new User; $user->name = 'A'; $user->save();如果$user->email是数据库非空字段且没设值，会触发数据库层面的Integrity constraint violation错误，而不是 Eloquent 的验证异常 -
create()不触发creating事件，但save()会——如果你依赖事件做日志或同步，这点必须确认
Blade 模板里 @include 和 @component 别混用
@include 就是简单引入另一个 Blade 文件，传参靠第二个数组参数；@component 是面向组件的封装，支持 slot、属性绑定、甚至可复用的生命周期钩子（比如 __construct 接收参数）。
性能影响很小，但语义差别很大：
- 用
@include('partials.nav')：适合纯展示型片段，比如页头、分页器，不需要状态管理 - 用
@component('components.alert')：适合带行为的 UI 单元，比如一个可关闭、带 type 属性的提示框，它的逻辑应封装在resources/views/components/alert.blade.php里 - 别在
@component里写业务查询——组件不该碰User::all()，数据该由父视图传入
真正难的不是记住这些 API，而是判断什么时候该用 make:policy 而不是手写 if 判断权限，或者什么时候该把 AppServiceProvider 里的 bind 拆成独立的服务提供者——这些边界，Laravel 不会替你决定，它只确保你选的路能走通。
