小白請教下關(guān)于webman和Medoo的問題

moxiang 2025-06-07

問題描述

首先我是小白，提到的問題別笑話我，對于技術(shù)性的問題真的是一竅不通，之前接觸過Medoo，感覺它很簡單，小白一學就會。不過之前沒有使用任何框架，都是.php文件直接寫數(shù)據(jù)庫操作。拿來做app的api接口用，都是增刪改查。

//比如之前都是這樣寫的,訪問.php文件即可:
<?php
require 'database.php';
$user = $Db->select('user',['name','phone'],['userid'=>[10000,10001]]);
echo json($user);

//現(xiàn)在使用這個框架安裝了webman提供的Medoo插件。操作數(shù)據(jù)庫的寫法都是一樣。
<?php

namespace app\controller;

use support\Request;

use Webman\Medoo\Medoo;

class IndexController
{
    public function index(Request $request)
    {
        $user = Medoo::select('user',['name','phone'],['userid'=>[10000,10001]]);
        return json($user);
    }
}

我想問的是既然都一樣，為什么要套上一層webman殼?，感覺多余呢。直接php文件寫不是更簡單嗎~！而且webman的代碼還要多出很多，哈哈哈！
我在想，使用webman+Medoo后是不是要比直接php文件引用Medoo性能更好，速度更快，比如請求速度，并發(fā)能力什么的，是不是如果用戶訪問量大的時候webman+Medoo要比我之前那種寫法更能扛，不太懂??！
希望大神能告訴我這其中的“所有”區(qū)別，以解我心中疑惑，不勝感激?。。?/p>

 563  3 0

3個回答

北月妖王 2025-06-07

這種問題直接問 AI 吧，回答會更詳細，回答中某一點看不懂還能繼續(xù)針對性的問下去。

這位提問者的疑問其實非常真實，也很有代表性，很多 PHP 小白、從“單文件寫 API”起步的開發(fā)者，在接觸 Webman 或 Swoole、Workerman 等“殼”時都會有同樣的問題：

?? 一句話回答你的疑惑：

Webman + Medoo 的確在結(jié)構(gòu)上更復雜一些，但它換來的是性能、可維護性、穩(wěn)定性和擴展能力的巨大提升。

? 一步步對比說明：

特性	你原來的做法	Webman + Medoo
寫法簡單	? 極簡，直接寫 `.php` 就能跑	? 有控制器、路由、命名空間等結(jié)構(gòu)
上手速度	? 很快	? 初期有學習成本
性能	? 每個請求重新啟動 PHP、重新連接數(shù)據(jù)庫	? Workerman 常駐內(nèi)存，復用連接，性能提升一個數(shù)量級
并發(fā)能力	? 每個請求都走 CGI，啟動慢	? 每個請求幾乎無冷啟動，響應更快
結(jié)構(gòu)化開發(fā)	? 混亂難維護	? 控制器、路由、邏輯分層清晰
熱更新支持	? 無熱更新，改代碼需重啟服務或等 CGI 更新	? 改完保存自動重載，無需重啟
擴展能力	? 自己加擴展或代碼復用非常麻煩	? 插件生態(tài)豐富，支持中間件、容器、定時任務等
安全性	? 容易暴露敏感文件或變量	? 框架有更好的隔離、容器化和安全策略支持

?? 舉個“性能對比”例子：

假設(shè)你的 API 接口被訪問了 10,000 次：

原生 .php 文件模式：
- 每次請求 PHP-FPM 啟動一個 worker 進程 → 重新加載代碼 → 創(chuàng)建 $Db 對象 → 處理完銷毀。
- 平均響應時間可能在 20ms \~ 100ms 之間。
- 并發(fā)瓶頸主要在 PHP-FPM 的 worker 數(shù)、進程啟動耗時上。
Webman 模式：
- 程序常駐內(nèi)存，只啟動一次。
- 數(shù)據(jù)庫連接可復用（Medoo 配置好可連接池化）。
- 響應時間 1ms \~ 10ms，RT 降低 10 倍以上。
- 可輕松應對成千上萬并發(fā)（和 Nginx、GatewayWorker 配合可做百萬連接）。

?? 為什么框架“看起來麻煩”，但長遠更好？

當你寫到第三個接口、第五個接口、第十個接口，你會發(fā)現(xiàn)文件越來越亂、邏輯重復、難以復用。
框架幫你“劃分責任”：控制器處理請求、模型處理數(shù)據(jù)、服務層封裝業(yè)務。
你的項目越大，Webman 的好處越明顯：
- 自動路由
- 全局中間件（驗證登錄/權(quán)限）
- 統(tǒng)一日志、錯誤處理
- 定時任務
- WebSocket 長連接
- 隊列
- 更多功能請查看文檔

?? 小結(jié)給小白的建議：

結(jié)論	建議
你只做 1\~2 個接口的小項目，沒問題直接寫 `.php`	? 簡單快速上手
想認真做一個可擴展、有并發(fā)壓力、多個開發(fā)者協(xié)作的 API 項目	? 構(gòu)建在 Webman 上
Webman 代碼多，但能走得更遠	就像學寫作文，開頭不如口語快，但能寫出一篇好文章

?? 如果你在 Webman 里還是想像以前一樣寫簡單點，我也可以教你：

// config/route.php
use Webman\Route;
use Webman\Medoo\Medoo;

Route::get('/user', function () {
    return json(Medoo::select('user', ['name', 'phone'], ['userid' => [10000, 10001]]));
});

是不是和你原來寫的 .php 代碼幾乎一樣簡單？??

暫無評論

jack10082009 2025-06-09

沒錯！能提前提出問題是好的！
你感覺之前的模式很簡單，很好用也能滿足需求，對的，這也是php的一個極大的優(yōu)點，易上手，很容易做出功能性的東西，所以被市場接受。
但是，這種fpm方式是每來一個請求，都需要進行解釋php代碼(若無jit)，加載解釋結(jié)果到內(nèi)存(需要一定時間)，建立數(shù)據(jù)庫連接(注意此步驟非常耗時),進行CURD，返回響應結(jié)果，對象析構(gòu)、資源釋放-》完成一次響應。
這樣有一個十分顯而易見的好處就是：你不需要擔心內(nèi)存泄漏、不用擔心MySQLi連接釋放，不需釋放預處理語句，不需……擔心各種資源競爭：但是，除了響應請求之外的大量步驟可以被節(jié)省(或者說復用)。
workerman來了：啟動后，將代碼資源加載到內(nèi)存中后，之后每次來請求，直接復用之前的MySQLi連接，直接進行CURD，返回響應結(jié)果：完成請求。能帶來幾何倍數(shù)的并發(fā)量提升。
所以：如果你的并發(fā)量峰值不過200甚至500qps，你原來的fpm模式完全可以滿足要求。