1.1 一条龙工地：Laravel 全景与版本演进

1.1 一条龙工地：Laravel 全景与版本演进

本节摘要：Laravel 是一套约定清晰、组件齐全的 PHP 全栈框架。本节先给出一幅"工地一条龙"全景图，说清路由、中间件、控制器、模型、视图、队列这些工位各自负责什么；再沿版本演进的时间线，看它如何从当年的 Laravel 4 走到今天的 Laravel 11，帮你把新旧知识对上号。它是全册的总纲，后面八章都会回到这张图上找位置。

本节在工地地图上的位置

上一节导读里我们把 Laravel 比作包工工程，本节负责把这座工地的平面图真正挂出来：先认识每个工位的职责，再看工地这些年的扩建史。看完本节你会知道全书各章在讲哪个工位；下一节我们再去把开工的工棚搭起来。

工地全景：一个请求的完整旅程

浏览器里敲下一个网址，到页面出现，中间发生了什么？把 Laravel 工地想象成一条流水线，请求就是那张流动的工单：

• 路由（进件窗口）：核对工单编号，也就是 URI 和请求方法，决定这张单子由谁处理。登记不全的请求直接退回 404。
• 中间件（门卫）：请求进入车间前的安检口，做登录校验、权限检查、请求日志。不合格的工单在门口就被拦下。
• 控制器（工头）：真正接单的人。它读工单内容，调用施工队干活，把结果整理成交付物。
• 模型与 ORM（施工队）：负责和数据库打交道。Eloquent 把数据表映射成对象，让"查订单"变成"找一个订单对象"。
• 视图 Blade（装修队）：把毛坯数据装修成 HTML 页面，模板继承让全站共用同一套户型。
• 队列（幕后车间）：发邮件、生成报表这类慢活，先记单、后台再干，用户不用等。

图上没有画出来的还有服务容器——它是全工地的物资调度中心，任何工位要工具，找它领就行。第二章我们会专门打开这台调度机器。

图 1-1：Laravel 工地一条龙全景

版本演进：工地这些年的扩建史

Laravel 的版本号不只是数字，每个大版本都在回应当时 PHP 生态的变化。挑几个影响深远的节点说：

• Laravel 4（2013）：框架拆成一组 Composer 组件再组装起来，Illuminate 这一名字从此和框架绑定。这也是"PHP 依赖管理现代化"的起点，今天你写 composer require 的习惯就是那时定下的。
• Laravel 5（2015）：目录结构和约定大幅定型，引入了 contracts（契约接口）与环境文件 .env 的规范用法，服务提供者的概念被强调到台前。
• Laravel 6（2019）：开始按语义化版本独立发布，框架进入"每半年一个大版本"的节奏，不再让升级变成洪水。
• Laravel 8（2020）：类名属性（PHP 8 Attributes 的前身思想）、Jetstream 脚手架、动态迁移关系等特性进场，工厂（Factory）重写成基于类的新写法——老教程里 factory 的旧语法从这里开始过时。
• Laravel 9/10（2022–2023）：底座全面转向 PHP 8，原生枚举、构造器属性提升这些语言特性被框架大量利用，测试与进程交互能力增强。
• Laravel 11（2024）：骨架瘦身。新项目不再默认生成 Http Kernel 和 Console Kernel 文件，中间件配置挪进了 bootstrap/app.php，路由结构文件数量减少，默认开箱配置更少但约定更强。

理解这条时间线的实用价值在于：你接手老项目时，看到 Kernel 文件还在，就知道是 10 及以前的骨架；看到 bootstrap/app.php 里用流式方法配置中间件和异常，就是 11 的新写法。本册代码统一按 Laravel 11 风格书写，遇到新旧差异会随手标注。

设计哲学：工地为什么这样排班

• 约定优于配置：模型叫 Order 就默认对应 orders 表，控制器放对目录就能被自动发现。约定的意义不是省打字，而是让任何人接手项目时，都能按同一张地图找到代码。
• 组件化：框架内核由一组松耦合组件拼成，队列、通知、验证都可以单独拿出来用，也可以整体协作。
• 依赖注入优先：工位需要的工具都从服务容器领取，而不是自己 new。这让换工具（比如把文件存储换成云存储）不用改动车间内部。

<?php
// 一段最能体现"约定+注入"的最小控制器（Laravel 11）
// 只需要声明类型，容器会自动把 Request 和模型相关的依赖送进来
namespace App\Http\Controllers;

use Illuminate\Http\Request;

class OrderController extends Controller
{
    // 方法注入：类型写清楚，框架负责找齐材料
    public function show(Request $request, int $id)
    {
        // 假设 Order 模型已存在，这里先假装查到了一条数据
        $order = ['id' => $id, 'status' => '施工中', 'total' => 199.00];

        // 返回 JSON：工头整理好交付物，交给窗口发货
        return response()->json($order);
    }
}
​

这段代码里没有任何一行在"找工具"：Request 是容器送来的，response() 是助手函数从容器里取的。你只写了业务判断本身，这就是 Laravel 的日常体感。

应用场景与适用边界

Laravel 适合内容站点、SaaS 后台、中小型业务系统、API 服务这类"业务逻辑密集"的场景，一站式程度高，从建表到上线都有配套。它不是所有工地都合适：极端性能敏感、需要常驻内存微服务化的场景，得靠 Octane 或 Swoole 这类方案改造（第九章会提）；纯静态站点用它属于高射炮打蚊子。选型时先看团队语言栈和业务形态，再看框架特性。

本节要点回顾

• 一条龙主线：路由进件、中间件安检、控制器派工、模型施工、视图装修、响应交付，全册九章都挂在这条流水线上。
• 版本脉络：4 组件化、5 约定定型、6 语义化版本、8 工厂重写、9 与 10 拥抱 PHP 8、11 骨架瘦身，认出写法年代是接手老项目的第一技能。
• 设计哲学：约定优于配置、组件化、依赖注入，三者共同指向同一个目标——让接手的人看得懂、改得动。
• 边界感：业务密集型项目选它很顺，极端性能或常驻内存场景需要额外方案加持。

下一节我们把工棚搭起来：PHP 和 Composer 装到位，让第一个 Laravel 页面在你机器上真正跑起来。