原生 PHP 还是 Laravel？小项目到底要不要上框架

这是一个几乎每个 PHP 开发者都会纠结的问题，而且越纠结越容易踩坑：

小项目上 Laravel，结果服务器 2G 内存跑满，composer install 都卡
小项目用原生 PHP，结果写到第三个月，自己都看不懂自己写的路由和 SQL
或者反过来：大项目硬上原生，最后变成一坨无法维护的意大利面条

这篇文章不站队，只讲怎么判断、怎么选、选完怎么少踩坑。

一、先把问题拆清楚：你在纠结的到底是什么

"原生 PHP vs Laravel" 这个选择题，背后其实藏着 4 个不同维度的问题：

维度	本质问题
性能	框架开销能不能接受？
开发效率	一个人多久能交付？
可维护性	三个月后谁来维护、能不能维护？
学习成本	团队能不能 hold 住？

很多人的错误在于：拿一个维度做决定，却用另一个维度来验证。

比如：因为"Laravel 太重"选了原生，结果三个月后因为"代码太乱"后悔。

或者：因为"Laravel 开发快"选了框架，结果部署到 1C2G 服务器上直接 OOM。

二、原生 PHP 的真实面貌：没你想的那么轻，也没那么自由

原生 PHP 的"轻"，轻在哪？

没有 composer 依赖树
没有 bootstrap 加载链
一次请求，执行的文件少
内存占用低（一个简单请求 5~15MB）

但代价是什么？

你得自己造：

你需要的东西	框架给你	原生你要
路由	现成的	自己写 `.htaccess` / `Router` 类
请求校验	FormRequest / 规则	每个接口手写 `if empty()`
ORM / 查询构造器	Eloquent	手写 PDO + SQL
认证 / 鉴权	中间件 + Guard	自己管 session / token
配置管理	`.env` + config	`define()` 或 `require 'config.php'`
日志	Monolog 集成	`error_log()` 或自己封装
错误处理	异常 handler	`set_exception_handler` 自己写
CSRF / XSS 防护	内置	自己记得 `htmlspecialchars` / token
迁移 / 种子	现成	手写 SQL 文件 + 手动执行
测试	PHPUnit 集成	自己搭

关键问题不是"能不能写"，是"你愿不愿意每次都写"。

小项目前两周你写得很爽：直接 index.php 里 SELECT * FROM user，一气呵成。

第三周加了个管理后台，第四周要登录，第五周要权限，第六周发现：

我花了 60% 的时间在写"基础设施"，只有 40% 在写业务逻辑。

原生 PHP 适合什么场景

✅ 适合：

纯展示型页面（公司官网、落地页）
单个 API 接口（支付回调、Webhook 接收）
一次性脚本 / 数据迁移 / 定时任务
服务器资源极度受限（512M~1G 内存）
你就是想完全掌控每一行代码
学习和理解 PHP 底层机制

❌ 不适合：

有用户系统（登录/注册/权限）
超过 10 个页面或接口
多人协作
预期会迭代超过 3 个月
需要对接第三方 API（支付、短信、OAuth）

三、Laravel 的真实面貌：没你想的那么重，也没那么慢

Laravel 的"重"，重在哪？

每个请求 Laravel 要做的：

加载 Composer autoload（几千个文件映射）
加载 bootstrap/app.php
创建 Application 容器
注册 Service Providers（默认 15+ 个）
启动中间件栈
解析路由
实例化 Controller
执行请求 → 返回响应

一个 "Hello World" 请求：

加载文件数：500~800 个
内存占用：15~30MB
耗时：10~30ms（无 OPcache）

对比原生 PHP：

加载文件数：1~3 个
内存占用：2~5MB
耗时：1~3ms

差距确实存在，但你要问自己：这重要吗？

Laravel 给你的真正价值

不是"优雅的语法糖"，是这 5 件事：

1. 约束

Laravel 强制你用 MVC、用迁移、用环境变量、用依赖注入。

这些约束让三个月后的你、或者另一个人，能看懂代码在哪。

原生 PHP 的"自由"，在单人短期项目里是效率；在多人长期项目里是灾难。

2. 生态

composer require 一下就有：

支付：laravel-cashier、omnipay
管理后台：filament、nova
队列：自带 queue + horizon
实时：laravel-echo + websocket
测试：pest / phpunit 开箱即用
部署：envoyer、forge、laravel-deploy

原生 PHP 你也能用这些库，但集成成本你自己算。

3. 安全

Laravel 默认帮你做了：

SQL 注入防护（参数绑定）
XSS 防护（blade 自动转义）
CSRF token
密码哈希（bcrypt/argon2）
签名 URL
速率限制

原生 PHP 里这些全是"你得记得做"的事。

安全漏洞不是因为你不会，是因为你忘了。

4. 数据库迁移

go 复制代码

php artisan make:migration create_orders_table
php artisan migrate

三个月后加字段、改索引，一条命令搞定。

原生 PHP 项目里，数据库结构靠口口相传或者一个过期的 SQL 文件。

5. 队列 / 异步

小项目后期几乎一定会需要：

发邮件
生成报表
调用第三方 API（慢）
图片处理

Laravel 队列一行代码：

css 复制代码

SendEmail::dispatch($user);

原生 PHP 你要自己搞 crontab + 锁文件 + 失败重试 + 监控。

Laravel 适合什么场景

✅ 适合：

有用户系统的项目（哪怕只是 admin 后台）
预期生命周期 > 3 个月
需要对接第三方服务（支付、短信、OAuth）
多人协作
你希望"写业务"而不是"写轮子"
服务器 ≥ 2C4G

❌ 不适合：

512M 内存的 VPS
纯静态 + 极少量动态
对延迟极度敏感（高频交易、实时游戏）
你或团队完全不懂框架概念（容器、中间件、ORM）
一次性活动页面（活两周就扔）

四、那"小项目"到底怎么定义？

这是关键。同样是"小项目"，差别巨大：

类型 A：工具型小项目

内部工具、数据导入导出、定时报表、Webhook 接收器

页面 < 5 个
无用户系统或只有简单密码
生命周期短（< 3 个月）
就你一个人用或就几个人用

→ 原生 PHP 或微框架（Slim / Lumen）

类型 B：业务型小项目

客户管理系统、预约系统、小型电商、博客+会员、小程序后端

页面 10~50 个
有用户/权限/数据关系
生命周期长（> 1 年）
可能要加功能、改需求

→ Laravel（或 ThinkPHP / Hyperf，看你技术栈）

类型 C：展示型小项目

官网、落地页、活动页

纯展示为主
可能有个留言/报名表单
访问量不大

→ 静态生成器 / 原生 PHP 模板，别上框架

五、折中方案：不想上 Laravel 全家桶，但又不想纯原生

方案 1：微框架

框架	特点
Slim	极简，只有路由 + 中间件，PSR-7
Lumen	Laravel 的轻量版，兼容 Laravel 语法
Flight	单文件框架，< 1MB
Webman	常驻内存，性能炸裂，适合 API

适合：API 服务、小程序后端、不想学 Laravel 全套但想要路由和中间件。

方案 2：只借 Laravel 的组件

不装整个 Laravel，只 composer require 你需要的：

bash 复制代码

composer require illuminate/database    # 只要 Eloquent ORM
composer require illuminate/validation  # 只要验证器
composer require monolog/monolog        # 只要日志
composer require vlucas/phpdotenv       # 只要 .env

自己写个 bootstrap.php 组装起来，轻量又现代。

方案 3：ThinkPHP

如果你在国内、团队偏传统 PHP：

文档全中文
学习曲线比 Laravel 低
性能比 Laravel 好
社区活跃

小项目用 ThinkPHP 8，体验其实很好。

六、决策树：30 秒判断你该选什么

复制代码

你的项目有用户登录/权限吗？
├── 没有 → 页面少于 5 个？
│         ├── 是 → 原生 PHP / 静态
│         └── 否 → 微框架（Slim / Flight）
├── 有 → 预期活多久？
│         ├── < 3 个月 → 微框架 / Lumen
│         └── > 3 个月 → 服务器多大？
│               ├── < 2C4G → ThinkPHP / 微框架
│               └── ≥ 2C4G → Laravel ✅

七、如果你选了 Laravel，怎么不让它"重"

1. 关掉不用的 Service Provider

config/app.php：

dart 复制代码

'providers' => [
    // 不用 API 认证？关掉
    // App\Providers\AuthServiceProvider::class,
    
    // 不用广播？关掉
    // Illuminate\Broadcasting\BroadcastServiceProvider::class,
    
    // 不用 Cookie 加密？关掉
    // Illuminate\Cookie\CookieServiceProvider::class,
],

2. 用路由缓存

复制代码

php artisan route:cache

生产环境必开，路由解析从 ~10ms 降到 < 1ms。

3. 用配置缓存

arduino 复制代码

php artisan config:cache

4. OPcache 必须开

前面文章讲过了，Laravel 没 OPcache 等于裸奔。

5. 选对 PHP 版本

PHP 8.2 / 8.3 比 7.4 快 20~30%，Laravel 10/11 跑得飞起。

6. 别用 sync 队列驱动

小项目容易犯：队列用 sync（同步执行），结果发邮件卡了整个请求。

哪怕用 database 驱动 + crontab 也比 sync 强。

八、如果你选了原生 PHP，怎么不让它烂

1. 至少做这 4 件事

php 复制代码

// 1. 统一入口
// index.php
require 'bootstrap.php';
$router->dispatch($_SERVER['REQUEST_URI']);

// 2. .env 管理配置
require_once __DIR__ . '/vendor/autoload.php';
$dotenv = Dotenv\Dotenv::createImmutable(__DIR__);
$dotenv->load();

// 3. 统一错误处理
set_exception_handler(function ($e) {
    error_log($e);
    http_response_code(500);
    echo json_encode(['error' => 'server error']);
});

// 4. 统一 DB 访问层（哪怕只是个简单封装）
class DB {
    private static $pdo;
    public static function pdo() {
        if (!self::$pdo) {
            self::$pdo = new PDO(
                $_ENV['DB_DSN'],
                $_ENV['DB_USER'],
                $_ENV['DB_PASS'],
                [PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION]
            );
        }
        return self::$pdo;
    }
}

2. 目录结构别乱

arduino 复制代码

project/
├── public/          # 唯一对外入口
│   └── index.php
├── src/
│   ├── Controller/
│   ├── Model/
│   ├── Middleware/
│   └── Utils/
├── config/
├── templates/
├── vendor/
├── .env
└── composer.json

3. 用 composer 管理依赖

哪怕只有 3 个依赖，也用 composer。

别 require 'vendor/PHPMailer/PHPMailer.php' 手动引。

九、终极建议

给个人开发者

如果你会 Laravel，小项目也上 Laravel。

开发效率的差距远大于性能差距。

你的时间比服务器贵。

给团队

统一技术栈比技术选型更重要。

团队都熟 ThinkPHP → 用 ThinkPHP。

团队都熟 Laravel → 用 Laravel。

别为了"小项目"引入第三种方案，维护成本翻倍。

给初学者

先学原生 PHP，再学框架。

不懂 $_GET $_POST session_start() PDO 就上 Laravel，

你不是在学框架，你是在背咒语。

十、一句话总结

原生 PHP 给你自由，Laravel 给你纪律。

小项目要的是"快上线"，不是"快执行"。

除非资源真的受限，否则框架省下的时间远大于它吃掉的内存。