Laravel 的核心优势在于统一约定降低协作成本：Artisan 命令确保结构与命名规范，Eloquent 以链式语法表达 SQL 意图并防注入，Blade 和中间件默认堵住 XSS、CSRF 等漏洞。
Laravel 的优势不在“功能多”，而在“所有功能都按同一套逻辑长出来”——它用约定代替配置，用一致性降低协作成本。2026 年还在选框架的 PHP 团队，基本不是在比谁更“快”，而是在比谁更“省心”。
Artisan 命令为什么能真正提升日常开发效率？
不是因为能生成代码，而是它把重复决策压缩成一条命令，且所有生成物天然符合项目结构和命名规范。
-
php artisan make:controller PostController --resource --api：直接生成 RESTful 资源控制器，不带视图逻辑，适合 API 项目；漏掉--api就会多出create/edit方法，后续要手动删 -
php artisan make:migration create_posts_table：生成带时间戳前缀的迁移文件，路径固定为database/migrations/，Laravel 自动识别并排序执行；手写迁移文件名若格式错（如缺时间戳或后缀不对），php artisan migrate会静默跳过 - 所有
make:命令生成的类，自动注册命名空间、use 语句、继承关系——比如控制器默认extends Controller，模型默认extends Model，改错一个就可能引发Class 'App\Http\Controllers\Controller' not found
Eloquent ORM 怎么避免“写 SQL 才放心”的惯性？
它不是屏蔽 SQL，而是让 PHP 语法能表达 SQL 意图，同时保留随时切回原生查询的出口。
- 链式调用可读性高：
Post::where('published', true)->with('author')->orderByDesc('created_at')->take(10)->get()对应清晰的 SQL 逻辑，且自动参数绑定防注入 - 关联预加载（
with）必须显式调用，否则 N+1 查询问题照旧发生；但只要写了，Eloquent 就会合并为 2 条 SQL（主表 + 关联表），而不是靠开发者手写 JOIN - 真要写原生 SQL？
DB::select("SELECT * FROM posts WHERE id = ?", [$id])或Post::whereRaw("json_contains(tags, ?)", ['"laravel"'])都支持，且仍走 PDO 预处理
Blade 模板和中间件如何协同解决“安全总得自己补”问题？
不是靠文档提醒你“记得 XSS 过滤”，而是默认行为就堵住常见漏洞入口。
立即学习“PHP免费学习笔记（深入）”；
- Blade 中
{{ $content }}自动 HTML 转义，{!! $content !!}才输出原始 HTML——这个双大括号约定，让团队新人也能一眼看出风险点 - CSRF 保护由
VerifyCsrfToken中间件全局启用，所有POST/PUT/PATCH/DELETE表单必须带@csrf指令；漏写会直接返回 419 状态码，不给“侥幸运行”的机会 - 中间件可堆叠：
auth+verified+throttle:60,1可以一行写完，顺序即执行顺序；但若把throttle放在auth前面，未登录用户也会被限流计数，影响体验
真正难的是把“优雅”坚持到底——比如一个自定义 Artisan 命令，如果没在 app/Console/Commands/ 下注册到 app/Providers/AppServiceProvider.php 的 $this->commands() 中，它就不会出现在 php artisan list 里；这种“看不见的约定”，恰恰是 Laravel 省心又容易踩坑的地方。
