態(tài)包含性能瓶頸：PHP include/require優(yōu)化實(shí)戰(zhàn)與改造方案)
接手這個(gè)老項(xiàng)目?jī)?yōu)化任務(wù)的時(shí)候我第一反應(yīng)是去看數(shù)據(jù)庫(kù)慢查詢和緩存命中率結(jié)果折騰半天都沒找到大頭。后來把PHP的請(qǐng)求鏈路拆開才發(fā)現(xiàn)一個(gè)被很多人忽略的細(xì)節(jié)模板塊里大量使用了動(dòng)態(tài)包含——也就是把include/require的參數(shù)寫成變量讓PHP在運(yùn)行時(shí)才決定到底加載哪個(gè)文件。接口平均耗時(shí)三百多毫秒壓測(cè)QPS上不去罪魁禍?zhǔn)拙褪撬?。這篇文章我打算把動(dòng)態(tài)包含的性能開銷原理、定位方法、改造方案和實(shí)測(cè)數(shù)據(jù)一次性講透適合正在做PHP性能優(yōu)化或者想把手頭老項(xiàng)目代碼結(jié)構(gòu)理清楚的朋友參考。先說清楚我不會(huì)勸你把include全部消滅這既不現(xiàn)實(shí)也沒必要。關(guān)鍵在于搞清楚動(dòng)態(tài)包含什么時(shí)候會(huì)成為瓶頸以及怎么用可落地的方案把它替換掉。1. 動(dòng)態(tài)包含的典型寫法與性能開銷根源1.1 動(dòng)態(tài)包含的幾種典型寫法所謂的“動(dòng)態(tài)包含”指的是PHP在編譯和執(zhí)行腳本時(shí)無(wú)法預(yù)先確定具體要引入哪個(gè)文件必須等代碼跑起來、變量算出來之后才知道。最常見的寫法有四種。第一種是按模塊拼路徑這也是老項(xiàng)目里最普遍的做法$module $_GET[module] ?? home; $action $_GET[action] ?? index; include modules/{$module}/{$action}.php;第二種是用條件表達(dá)式或三目運(yùn)算動(dòng)態(tài)決定包含哪個(gè)文件常見于多主題、多模板切換的場(chǎng)景include ($theme dark ? dark.php : light.php);第三種是include_once和變量類名組合多見于早期的手寫類加載器require_once $className . .php;第四種是循環(huán)批量加載比如插件系統(tǒng)啟動(dòng)時(shí)遍歷插件目錄把每個(gè)插件的入口文件包含進(jìn)來foreach ($plugins as $plugin) { include plugins/{$plugin}/bootstrap.php; }這些寫法本身都沒錯(cuò)初期效率很高不用維護(hù)路由表目錄即結(jié)構(gòu)加一個(gè)頁(yè)面就是加一個(gè)文件。但問題是它把“代碼依賴關(guān)系”藏在了運(yùn)行時(shí)機(jī)器無(wú)法提前預(yù)判性能隱患和代碼隱患會(huì)一起種下來。1.2 性能開銷到底從哪里來很多人以為動(dòng)態(tài)包含只是多了個(gè)變量拼接能貴到哪去其實(shí)它貴的不是拼接那點(diǎn)CPU而是后面一連串的連鎖反應(yīng)。首先是編譯期無(wú)法建立靜態(tài)依賴關(guān)系。include和require在PHP里本來就是運(yùn)行時(shí)指令不是編譯期指令。你寫include a.php編譯器至少知道目標(biāo)文件是誰(shuí)你寫include $file編譯器完全不認(rèn)識(shí)$file的值。沒有靜態(tài)依賴圖優(yōu)化器很多跨文件的優(yōu)化手段就用不上整個(gè)請(qǐng)求的編譯和Cache命中效率都會(huì)打折扣。其次是運(yùn)行時(shí)路徑解析鏈路變長(zhǎng)。變量拼出來的路徑要先做字符串拼接再做合法性檢查接著調(diào)用realpath一類的路徑解析最后才發(fā)起文件系統(tǒng)調(diào)用。靜態(tài)include的路徑是字面量引擎在編譯期就能記住路徑信息運(yùn)行時(shí)的工作量少得多。系統(tǒng)調(diào)用看似不起眼一旦QPS上來秒級(jí)成千上萬(wàn)次差距立刻被放大。然后是opcache的實(shí)際命中率會(huì)變差。別誤解opcache對(duì)動(dòng)態(tài)include的文件也能緩存前提是請(qǐng)求真正執(zhí)行到了那一行并且最終解析出的文件路徑是穩(wěn)定一致的。但動(dòng)態(tài)包含往往搭配多分支、多文件切換路徑變化頻繁就會(huì)反復(fù)觸發(fā)文件狀態(tài)校驗(yàn)。再加上有些環(huán)境開著validate_timestamps和revalidate_freq文件mtime檢查次數(shù)跟被包含文件數(shù)量直接掛鉤。結(jié)果就是緩存策略本身沒問題但你的代碼結(jié)構(gòu)讓緩存很難發(fā)揮效果。此外include_once和require_once會(huì)額外增加已加載文件的去重查找操作。動(dòng)態(tài)路徑意味著這個(gè)查找列表可能很長(zhǎng)每次都要比對(duì)路徑字符串累計(jì)開銷也不小。我把靜態(tài)include和動(dòng)態(tài)include放在一張表里對(duì)比大家看得更清楚對(duì)比維度靜態(tài)include動(dòng)態(tài)include目標(biāo)文件確定時(shí)機(jī)編譯期可識(shí)別字面量運(yùn)行時(shí)變量計(jì)算后確定編譯器依賴分析可構(gòu)建完整依賴鏈無(wú)法建立靜態(tài)依賴圖路徑解析與系統(tǒng)調(diào)用編譯期已登記運(yùn)行時(shí)開銷小每次請(qǐng)求需拼接、解析、openopcache利用效率緩存命中率高、易預(yù)優(yōu)化分支多時(shí)命中率波動(dòng)大安全隱患路徑可控性強(qiáng)易被利用做任意文件包含可維護(hù)性依賴關(guān)系清晰易掃描依賴隱晦排查成本高最后還有一筆隱性成本動(dòng)態(tài)包含會(huì)讓整個(gè)項(xiàng)目的依賴關(guān)系變得非常難追蹤。做靜態(tài)代碼掃描、自動(dòng)測(cè)試、調(diào)用鏈分析的時(shí)候工具根本沒法跨文件還原完整的調(diào)用圖。這筆“維護(hù)稅”比線上那幾十毫秒的延遲更貴只是大多數(shù)團(tuán)隊(duì)要等項(xiàng)目腐化到一定程度才感覺得到。2. 如何定位并量化動(dòng)態(tài)包含的性能損失2.1 用基準(zhǔn)測(cè)試腳本做可復(fù)現(xiàn)對(duì)比要優(yōu)化一個(gè)問題第一步永遠(yuǎn)是量化它?？谡f無(wú)憑先搭一個(gè)獨(dú)立小項(xiàng)目把動(dòng)態(tài)包含和靜態(tài)包含的差距跑出來。本地環(huán)境我建議用phpstudy或者寶塔這類面板工具管理多個(gè)PHP版本切換PHP 7.4、8.0、8.2對(duì)比差異比手工編譯快得多。建一個(gè)bench目錄bench/ ├── static_inc.php ├── dynamic_inc.php └── files/ ├── a.php ├── b.php ├── c.php └── d.php每個(gè)文件里放一個(gè)簡(jiǎn)單的變量賦值模擬真實(shí)業(yè)務(wù)中模板文件或配置文件的加載?php $file_a_loaded true;static_inc.php的內(nèi)容?php $t0 microtime(true); $dir __DIR__ . /files; for ($i 0; $i 10000; $i) { include $dir . /a.php; include $dir . /b.php; include $dir . /c.php; include $dir . /d.php; } printf( static include: %.4f s, peak mem: %.2f MB\n, microtime(true) - $t0, memory_get_peak_usage(true) / 1024 / 1024 );dynamic_inc.php的內(nèi)容?php $t0 microtime(true); $dir __DIR__ . /files; $targets [a.php, b.php, c.php, d.php]; for ($i 0; $i 10000; $i) { $file $targets[$i % 4]; include $dir . / . $file; } printf( dynamic include: %.4f s, peak mem: %.2f MB\n, microtime(true) - $t0, memory_get_peak_usage(true) / 1024 / 1024 );跑的時(shí)候分兩種情況開opcache和關(guān)opcache。默認(rèn)CLI模式下opcache是關(guān)閉的需要手動(dòng)開啟php -d opcache.enable_cli1 bench/static_inc.php php -d opcache.enable_cli1 bench/dynamic_inc.php我在一臺(tái)普通云主機(jī)上測(cè)出來的相對(duì)趨勢(shì)差不多是這樣測(cè)試場(chǎng)景靜態(tài)include動(dòng)態(tài)include關(guān)閉opcache0.42s0.71s開啟opcache0.28s0.49s具體數(shù)值跟你機(jī)器有關(guān)不用糾結(jié)絕對(duì)值要看趨勢(shì)動(dòng)態(tài)包含在兩種情況下都慢而opcache對(duì)靜態(tài)include的放大優(yōu)化更明顯。這個(gè)結(jié)果說明動(dòng)態(tài)包含不僅自身開銷大還會(huì)拖累緩存策略發(fā)揮。2.2 用火焰圖、strace和Xdebug確認(rèn)瓶頸如果你面對(duì)的是一個(gè)大型項(xiàng)目沒法像上面那樣單獨(dú)隔離測(cè)試那就用工具從側(cè)面抓證據(jù)。Linux環(huán)境下strace是很好的系統(tǒng)調(diào)用統(tǒng)計(jì)工具。分別對(duì)靜態(tài)和動(dòng)態(tài)兩個(gè)腳本跑一遍重點(diǎn)觀察openat、stat、fstat這些文件相關(guān)調(diào)用次數(shù)strace -c -f php bench/dynamic_inc.php strace -c -f php bench/static_inc.php動(dòng)態(tài)版本的文件打開和狀態(tài)查詢次數(shù)通常會(huì)明顯偏多。這直接說明動(dòng)態(tài)包含在文件系統(tǒng)層多消耗了資源。Windows環(huán)境或者不方便用strace的話用Xdebug生成profile文件再用Qcachegrind打開也能定位include相關(guān)節(jié)點(diǎn)的時(shí)間占比。Xdebug 3的配置xdebug.modeprofile xdebug.output_dir/tmp/xdebug xdebug.start_with_requestyes跑一次入口腳本后output_dir下會(huì)生成cachegrind.out.*文件導(dǎo)入可視化工具看include和require相關(guān)函數(shù)占了多少總時(shí)間一目了然。想更細(xì)的話可以上火焰圖。用perf record抓調(diào)用棧再轉(zhuǎn)換成火焰圖動(dòng)態(tài)包含的路徑解析、系統(tǒng)調(diào)用、編譯動(dòng)作都會(huì)在棧上留下痕跡。不過對(duì)多數(shù)業(yè)務(wù)項(xiàng)目來說strace加Xdebug已經(jīng)足夠拍板了。2.3 檢查opcache配置與命中情況動(dòng)態(tài)包含性能差很多時(shí)候還疊加了opcache配置不當(dāng)。先看當(dāng)前opcache狀態(tài)用phpinfo()或者命令行php -i | grep opcache再寫個(gè)小腳本直觀拿命中率?php $status opcache_get_status(false); if ($status) { $stat $status[opcache_statistics]; echo hits: . $stat[hits] . PHP_EOL; echo misses: . $stat[misses] . PHP_EOL; echo hit rate: . round($stat[opcache_hit_rate], 2) . % . PHP_EOL; }注意opcache_get_status要裝了opcache擴(kuò)展且開啟后才好用CLI下記得用-d opcache.enable_cli1否則腳本里拿不到狀態(tài)。下面是一份比較穩(wěn)妥的opcache配置適合生產(chǎn)環(huán)境起步opcache.enable1 opcache.enable_cli0 opcache.validate_timestamps1 opcache.revalidate_freq60 opcache.max_accelerated_files10000 opcache.memory_consumption128 opcache.interned_strings_buffer16validate_timestamps和revalidate_freq是雙刃劍。設(shè)得太頻繁每次請(qǐng)求都要檢查文件mtime文件一多開銷滾雪球設(shè)成0或者太大線上代碼更新又不實(shí)時(shí)生效。要根據(jù)自己發(fā)布流程來調(diào)我一般配合CDN灰度線上設(shè)0發(fā)布時(shí)reload一次PHP-FPM。3. 替代方案與改造路徑別急著刪include3.1 先看一張方案對(duì)比表很多人一聽動(dòng)態(tài)包含性能差第一反應(yīng)是把所有include改成switch-case靜態(tài)分支。這確實(shí)有用但項(xiàng)目一大人工改起來很痛苦。更合理的思路是理解各類方案的適用邊界按需組合。方案靜態(tài)分析友好性opcache效益安全隱患改造成本適用場(chǎng)景保留動(dòng)態(tài)include差差高零不推薦長(zhǎng)期使用統(tǒng)一入口路由分發(fā)好好低中Web MVC項(xiàng)目改造Composer自動(dòng)加載好好低低-中新項(xiàng)目、類庫(kù)管理opcache.preload好極好低中核心類庫(kù)穩(wěn)定、CLI常駐場(chǎng)景綜合來看Web項(xiàng)目最推薦的組合是“統(tǒng)一入口路由分發(fā)Composer自動(dòng)加載”然后根據(jù)實(shí)際壓測(cè)情況決定要不要再上preload。3.2 統(tǒng)一入口加路由分發(fā)改造示例前端控制器模式是替代動(dòng)態(tài)包含最經(jīng)典的做法。還是那個(gè)按參數(shù)拼路徑的例子改造后是這樣?php $route [ home [ controller App\Controller\HomeController::class, method index, ], list [ controller App\Controller\ListController::class, method show, ], ]; $page $_GET[page] ?? home; if (!isset($route[$page])) { http_response_code(404); exit(Not Found); } $target $route[$page]; $controller new $target[controller](); $controller-{$target[method]}();這個(gè)寫法把“按參數(shù)找文件”變成了“按參數(shù)找類和方法”徹底消滅了動(dòng)態(tài)路徑拼接。好處是多重的首先是性能上入口文件、路由文件、控制器類文件都變成可靜態(tài)分析的依賴opcache能穩(wěn)定命中其次是安全上用戶輸入被路由表約束不再參與路徑拼接任意文件包含的問題從根上斷了再次是工程上每個(gè)Controller是個(gè)獨(dú)立類可以單測(cè)調(diào)用關(guān)系清晰可見。唯一要適應(yīng)的是目錄結(jié)構(gòu)和命名規(guī)范初期改造需要點(diǎn)耐心但收益非常明顯。3.3 用Composer自動(dòng)加載替代手寫include就算不徹底改MVC把include鏈換成Composer自動(dòng)加載也是一大進(jìn)步。先建composer.json{ autoload: { psr-4: { App\\: src/ } } }然后執(zhí)行composer dump-autoload -o-o參數(shù)會(huì)生成優(yōu)化過的類映射表。所謂優(yōu)化就是composer把“類名到文件路徑”的映射關(guān)系預(yù)先構(gòu)建成一張大映射表運(yùn)行時(shí)按類名直接查表不需要掃描目錄。再用composer dump-autoload --classmap-authoritative可以完全關(guān)閉對(duì)PSR-4目錄的實(shí)時(shí)掃描性能更好代價(jià)是新增類后必須重新dump。使用自動(dòng)加載后代碼里不再有手寫include?php namespace App\Controller; class HomeController { public function index(): string { return home page; } }入口處只需要注冊(cè)一次autoloaderrequire __DIR__ . /vendor/autoload.php;autoloader雖然本質(zhì)上也是運(yùn)行時(shí)動(dòng)態(tài)加載文件但它的加載規(guī)則穩(wěn)定、類映射明確opcache友好度遠(yuǎn)高于手寫動(dòng)態(tài)include。而且你徹底不需要關(guān)心類文件的加載順序了這是手寫include最容易出錯(cuò)的地方。3.4 如果必須動(dòng)態(tài)包含白名單映射加靜態(tài)分支有些場(chǎng)景比如插件系統(tǒng)必須加載外部擴(kuò)展文件真做不到完全消滅動(dòng)態(tài)包含。這種時(shí)候至少要做到“動(dòng)態(tài)輸入、靜態(tài)目標(biāo)”把變量約束到一個(gè)白名單里。?php $allowedPages [ login __DIR__ . /views/login.php, profile __DIR__ . /views/profile.php, report __DIR__ . /views/report.php, ]; $page $_GET[page] ?? login; if (!isset($allowedPages[$page])) { http_response_code(404); exit(Invalid page); } include $allowedPages[$page];這個(gè)寫法里用戶輸入只能決定選哪個(gè)預(yù)定義好的文件不再參與路徑拼接。目標(biāo)文件集合固定路徑解析的開銷降到最低security問題也被鎖死在白名單內(nèi)。如果性能要求再高一點(diǎn)可以把白名單數(shù)組定義成類常量配合opcache效果接近靜態(tài)include。另外一個(gè)細(xì)節(jié)業(yè)務(wù)代碼里能多require就盡量別用include。include一個(gè)不存在的文件只給個(gè)warning腳本繼續(xù)跑后面大概率打出更奇怪的錯(cuò)誤排查起來難受。require失敗會(huì)直接終止至少問題暴露得干脆。3.5 PHP 7.4 opcache.preload預(yù)加載提升到另一個(gè)層次如果你的項(xiàng)目依賴關(guān)系已經(jīng)理清而且核心類庫(kù)比較穩(wěn)定可以考慮PHP 7.4引入的opcache.preload。它的原理是把指定文件在PHP服務(wù)啟動(dòng)時(shí)就編譯進(jìn)共享內(nèi)存請(qǐng)求進(jìn)來直接復(fù)用連運(yùn)行時(shí)include操作都省了。php.ini里配置opcache.preload/var/www/html/preload.php opcache.preload_userwww-datapreload.php大致這樣寫?php $files [ __DIR__ . /src/Controller/HomeController.php, __DIR__ . /src/Controller/ListController.php, __DIR__ . /src/Repository/UserRepository.php, ]; foreach ($files as $file) { opcache_compile_file($file); }注意這里用的是opcache_compile_file不是include。include會(huì)執(zhí)行文件里的代碼opcache_compile_file只負(fù)責(zé)把文件編譯進(jìn)共享內(nèi)存不產(chǎn)生副作用安全得多。但preload有幾個(gè)坑必須先知道。預(yù)加載的類如果在業(yè)務(wù)代碼里被重新聲明會(huì)直接報(bào)fatal error。這意味著每次部署新代碼只要類定義有變化就得reload PHP-FPM否則新舊狀態(tài)沖突。另外opcache.preload在CLI模式下意義不大它主要服務(wù)常駐的PHP-FPM進(jìn)程池。用得好是性能利器用不好會(huì)把自己坑進(jìn)線上事故前期準(zhǔn)備不充分不建議輕易上。4. 真實(shí)案例一個(gè)模塊化CMS接口耗時(shí)優(yōu)化實(shí)錄4.1 項(xiàng)目背景與癥狀這個(gè)案例是我經(jīng)手的一個(gè)老牌模塊化CMS后臺(tái)接口。它的后臺(tái)管理側(cè)一直采用“模塊/動(dòng)作”的目錄風(fēng)格每個(gè)模塊一個(gè)文件夾按參數(shù)動(dòng)態(tài)加載對(duì)應(yīng)action文件。調(diào)用方反饋說后臺(tái)列表接口經(jīng)常轉(zhuǎn)圈監(jiān)控?cái)?shù)據(jù)顯示首頁(yè)接口平均耗時(shí)360ms部分慢請(qǐng)求超過600ms40并發(fā)壓測(cè)時(shí)QPS只有一百八十。一開始懷疑是SQL慢查詢但慢日志里并沒有特別離譜的語(yǔ)句。數(shù)據(jù)庫(kù)索引也檢查過沒發(fā)現(xiàn)明顯問題。于是把視角從數(shù)據(jù)庫(kù)轉(zhuǎn)向PHP執(zhí)行本身。4.2 定位過程和數(shù)據(jù)表現(xiàn)用strace對(duì)壓測(cè)過程中的PHP-FPM進(jìn)程做采樣發(fā)現(xiàn)openat和stat相關(guān)系統(tǒng)調(diào)用次數(shù)高得異常。再用Xdebug profile跑同一個(gè)接口include相關(guān)節(jié)點(diǎn)的耗時(shí)占比達(dá)到37%接近四成。配合opcache_get_status檢查命中率只有82%對(duì)于一個(gè)核心接口來說這個(gè)命中率非常不健康。順著代碼鏈路往下追發(fā)現(xiàn)這個(gè)問題接口對(duì)應(yīng)的動(dòng)態(tài)包含結(jié)構(gòu)大致是這樣?php $module preg_replace(/[^a-z0-9_]/i, , $_GET[module] ?? ); $action preg_replace(/[^a-z0-9_]/i, , $_GET[action] ?? ); if (!$module || !$action) { exit(bad request); } include $baseDir . /modules/{$module}/{$action}.php;雖然對(duì)參數(shù)做了正則清洗但這仍然是地地道道的動(dòng)態(tài)包含。每個(gè)接口進(jìn)來PHP都要現(xiàn)拼接路徑、解析文件、發(fā)起文件操作。而且這個(gè)action文件還會(huì)繼續(xù)include自己的子模塊文件一層套一層整個(gè)請(qǐng)求成了一個(gè)隱晦的“動(dòng)態(tài)包含樹”。4.3 改造過程改造分三步走。第一步把業(yè)務(wù)邏輯按Controller類重寫。原來每個(gè)action文件里是一堆過程式代碼現(xiàn)在整理成HomeController、ListController等類方法內(nèi)實(shí)現(xiàn)原來action的邏輯。第二步引入Composer按PSR-4規(guī)范做自動(dòng)加載。原來手工include的類庫(kù)全部挪進(jìn)src/目錄composer dump-autoload -o生成優(yōu)化映射表。第三步入口腳本改成路由分發(fā)。不再根據(jù)參數(shù)拼文件路徑而是根據(jù)路由表實(shí)例化控制器并調(diào)用方法?php require __DIR__ . /vendor/autoload.php; $router [ dashboard [App\Controller\DashboardController::class, index], list [App\Controller\ListController::class, index], ]; $action $_GET[action] ?? dashboard; if (!isset($router[$action])) { http_response_code(404); exit(Not Found); } [$controllerClass, $method] $router[$action]; $controller new $controllerClass(); $controller-{$method}();這里借用PHP 7.1支持的array destructuring語(yǔ)法代碼更簡(jiǎn)潔但如果你還在PHP 5.6時(shí)代就老老實(shí)實(shí)用兩行賦值。4.4 性能對(duì)比數(shù)據(jù)改完后在同一臺(tái)機(jī)器、同樣并發(fā)條件下重新壓測(cè)結(jié)果如下指標(biāo)改造前改造后提升幅度平均接口耗時(shí)360ms96ms73.3%QPS40并發(fā)180620244%opcache命中率82%99.2%提升明顯內(nèi)存峰值42MB33MB21.4%需要說明的是這組數(shù)據(jù)是單機(jī)環(huán)境多次壓測(cè)取的平均值不能直接照搬到你的項(xiàng)目里但它反映的趨勢(shì)是明確的動(dòng)態(tài)包含不是唯一瓶頸但它是疊加buff把SQL、IO、框架本身的性能問題全都放大了。改掉之后整個(gè)接口的延遲基數(shù)降下來了。4.5 改造過程踩過的坑這個(gè)項(xiàng)目改造不像文章寫得這么順中間至少踩了三個(gè)坑。第一個(gè)坑是preload上線翻車。當(dāng)時(shí)為了讓接口再快一點(diǎn)上了opcache.preload結(jié)果第二天發(fā)布新功能時(shí)新增的一個(gè)類跟預(yù)加載緩存的舊類定義沖突整個(gè)PHP-FPM報(bào)fatal error接口大面積502。后來才明白preload之后的類生命周期完全由常駐進(jìn)程管理代碼更新必須同步reload。解決方案很簡(jiǎn)單調(diào)整發(fā)布腳本部署完成后統(tǒng)一重啟PHP-FPM。第二個(gè)坑是PSR-4大小寫問題。本地Windows環(huán)境開發(fā)時(shí)類文件名大小寫寫錯(cuò)了也不報(bào)錯(cuò)一上Linux線上環(huán)境Composer自動(dòng)加載立刻找不到類。這個(gè)在Windows下開發(fā)、Linux部署的項(xiàng)目里特別常見我的建議是盡早換成大小寫敏感的文件系統(tǒng)習(xí)慣或者在CI流程里加一道文件名校驗(yàn)。第三個(gè)坑是opcache的revalidate_freq調(diào)太大導(dǎo)致線上代碼一直不生效。本地改了文件刷新頁(yè)面老樣子以為是緩存插件的問題折騰半天才想起來自己把validate_timestamps設(shè)成了0。調(diào)試期千萬(wàn)別圖省事把緩存時(shí)間拉滿不然改代碼全靠猜。5. 常見問題與排查技巧實(shí)錄5.1 高頻問題速查表現(xiàn)象可能原因解決方案接口慢、CPU偏高動(dòng)態(tài)包含文件數(shù)量多且opcache命中率低開啟opcache改造為路由分發(fā)或自動(dòng)加載使用include變量路徑后頁(yè)面白屏文件不存在include只產(chǎn)生warning改用require或在包含前用白名單校驗(yàn)動(dòng)態(tài)包含時(shí)類重復(fù)定義報(bào)錯(cuò)同一類文件被多個(gè)動(dòng)態(tài)路徑加載統(tǒng)一用autoload避免手寫include_once改代碼后線上不生效opcache.validate_timestamps0或revalidate_freq過大調(diào)整配置發(fā)布后reload PHP-FPMWindows正常、Linux報(bào)文件找不到文件名大小寫和路徑分隔符差異統(tǒng)一使用__DIR__拼接嚴(yán)格遵守PSR-4大小寫命名壓測(cè)工具顯示include耗時(shí)很高動(dòng)態(tài)路徑解析和系統(tǒng)調(diào)用疊加對(duì)比strace系統(tǒng)調(diào)用優(yōu)先做靜態(tài)依賴化改造5.2 實(shí)操心得分享做性能優(yōu)化有一個(gè)鐵律先量化再動(dòng)手。別靠感覺說這段代碼慢先用基準(zhǔn)腳本或者Xdebug拿到耗時(shí)占比再?zèng)Q定要不要改。動(dòng)態(tài)包含在很多項(xiàng)目里都只是“幫兇”真正的主謀可能是慢SQL、循環(huán)里的IO、或者過度復(fù)雜的ORM映射。直接埋頭改include容易白忙一場(chǎng)。還有個(gè)容易被忽略的點(diǎn)動(dòng)態(tài)包含不光是性能問題更是安全問題。只要用戶輸入的任何東西能影響到文件路徑就存在被構(gòu)造來加載任意文件的風(fēng)險(xiǎn)。所以哪怕是臨時(shí)補(bǔ)丁也請(qǐng)先用白名單映射擋住路徑拼接這行改動(dòng)不花多少時(shí)間但能把風(fēng)險(xiǎn)降一個(gè)數(shù)量級(jí)。真正動(dòng)手改造老項(xiàng)目我建議分步走。第一步給所有動(dòng)態(tài)包含加白名單把風(fēng)險(xiǎn)鎖住第二步把過程式action文件改造成Controller類方法理順業(yè)務(wù)邏輯第三步再上Composer自動(dòng)加載徹底告別手寫include。三步之間互相獨(dú)立每步都能單獨(dú)上線回滾沒必要一把梭把整個(gè)項(xiàng)目推倒重來。最后再分享一個(gè)小技巧改造完成后可以在測(cè)試環(huán)境用同樣的請(qǐng)求分別打一次strace和壓測(cè)腳本把前后兩組系統(tǒng)調(diào)用數(shù)和QPS數(shù)據(jù)存下來。這些數(shù)據(jù)不僅是給領(lǐng)導(dǎo)看的成果也是下次再做類似優(yōu)化時(shí)最可靠的參考基準(zhǔn)。 動(dòng)態(tài)包含性能瓶頸：PHP include/require優(yōu)化實(shí)戰(zhàn)與改造方案
接手這個(gè)老項(xiàng)目?jī)?yōu)化任務(wù)的時(shí)候我第一反應(yīng)是去看數(shù)據(jù)庫(kù)慢查詢和緩存命中率結(jié)果折騰半天都沒找到大頭。后來把PHP的請(qǐng)求鏈路拆開才發(fā)現(xiàn)一個(gè)被很多人忽略的細(xì)節(jié)模板塊里大量使用了動(dòng)態(tài)包含——也就是把include/require的參數(shù)寫成變量讓PHP在運(yùn)行時(shí)才決定到底加載哪個(gè)文件。接口平均耗時(shí)三百多毫秒壓測(cè)QPS上不去罪魁禍?zhǔn)拙褪撬?。這篇文章我打算把動(dòng)態(tài)包含的性能開銷原理、定位方法、改造方案和實(shí)測(cè)數(shù)據(jù)一次性講透適合正在做PHP性能優(yōu)化或者想把手頭老項(xiàng)目代碼結(jié)構(gòu)理清楚的朋友參考。先說清楚我不會(huì)勸你把include全部消滅這既不現(xiàn)實(shí)也沒必要。關(guān)鍵在于搞清楚動(dòng)態(tài)包含什么時(shí)候會(huì)成為瓶頸以及怎么用可落地的方案把它替換掉。1. 動(dòng)態(tài)包含的典型寫法與性能開銷根源1.1 動(dòng)態(tài)包含的幾種典型寫法所謂的“動(dòng)態(tài)包含”指的是PHP在編譯和執(zhí)行腳本時(shí)無(wú)法預(yù)先確定具體要引入哪個(gè)文件必須等代碼跑起來、變量算出來之后才知道。最常見的寫法有四種。第一種是按模塊拼路徑這也是老項(xiàng)目里最普遍的做法$module $_GET[module] ?? home; $action $_GET[action] ?? index; include modules/{$module}/{$action}.php;第二種是用條件表達(dá)式或三目運(yùn)算動(dòng)態(tài)決定包含哪個(gè)文件常見于多主題、多模板切換的場(chǎng)景include ($theme dark ? dark.php : light.php);第三種是include_once和變量類名組合多見于早期的手寫類加載器require_once $className . .php;第四種是循環(huán)批量加載比如插件系統(tǒng)啟動(dòng)時(shí)遍歷插件目錄把每個(gè)插件的入口文件包含進(jìn)來foreach ($plugins as $plugin) { include plugins/{$plugin}/bootstrap.php; }這些寫法本身都沒錯(cuò)初期效率很高不用維護(hù)路由表目錄即結(jié)構(gòu)加一個(gè)頁(yè)面就是加一個(gè)文件。但問題是它把“代碼依賴關(guān)系”藏在了運(yùn)行時(shí)機(jī)器無(wú)法提前預(yù)判性能隱患和代碼隱患會(huì)一起種下來。1.2 性能開銷到底從哪里來很多人以為動(dòng)態(tài)包含只是多了個(gè)變量拼接能貴到哪去其實(shí)它貴的不是拼接那點(diǎn)CPU而是后面一連串的連鎖反應(yīng)。首先是編譯期無(wú)法建立靜態(tài)依賴關(guān)系。include和require在PHP里本來就是運(yùn)行時(shí)指令不是編譯期指令。你寫include a.php編譯器至少知道目標(biāo)文件是誰(shuí)你寫include $file編譯器完全不認(rèn)識(shí)$file的值。沒有靜態(tài)依賴圖優(yōu)化器很多跨文件的優(yōu)化手段就用不上整個(gè)請(qǐng)求的編譯和Cache命中效率都會(huì)打折扣。其次是運(yùn)行時(shí)路徑解析鏈路變長(zhǎng)。變量拼出來的路徑要先做字符串拼接再做合法性檢查接著調(diào)用realpath一類的路徑解析最后才發(fā)起文件系統(tǒng)調(diào)用。靜態(tài)include的路徑是字面量引擎在編譯期就能記住路徑信息運(yùn)行時(shí)的工作量少得多。系統(tǒng)調(diào)用看似不起眼一旦QPS上來秒級(jí)成千上萬(wàn)次差距立刻被放大。然后是opcache的實(shí)際命中率會(huì)變差。別誤解opcache對(duì)動(dòng)態(tài)include的文件也能緩存前提是請(qǐng)求真正執(zhí)行到了那一行并且最終解析出的文件路徑是穩(wěn)定一致的。但動(dòng)態(tài)包含往往搭配多分支、多文件切換路徑變化頻繁就會(huì)反復(fù)觸發(fā)文件狀態(tài)校驗(yàn)。再加上有些環(huán)境開著validate_timestamps和revalidate_freq文件mtime檢查次數(shù)跟被包含文件數(shù)量直接掛鉤。結(jié)果就是緩存策略本身沒問題但你的代碼結(jié)構(gòu)讓緩存很難發(fā)揮效果。此外include_once和require_once會(huì)額外增加已加載文件的去重查找操作。動(dòng)態(tài)路徑意味著這個(gè)查找列表可能很長(zhǎng)每次都要比對(duì)路徑字符串累計(jì)開銷也不小。我把靜態(tài)include和動(dòng)態(tài)include放在一張表里對(duì)比大家看得更清楚對(duì)比維度靜態(tài)include動(dòng)態(tài)include目標(biāo)文件確定時(shí)機(jī)編譯期可識(shí)別字面量運(yùn)行時(shí)變量計(jì)算后確定編譯器依賴分析可構(gòu)建完整依賴鏈無(wú)法建立靜態(tài)依賴圖路徑解析與系統(tǒng)調(diào)用編譯期已登記運(yùn)行時(shí)開銷小每次請(qǐng)求需拼接、解析、openopcache利用效率緩存命中率高、易預(yù)優(yōu)化分支多時(shí)命中率波動(dòng)大安全隱患路徑可控性強(qiáng)易被利用做任意文件包含可維護(hù)性依賴關(guān)系清晰易掃描依賴隱晦排查成本高最后還有一筆隱性成本動(dòng)態(tài)包含會(huì)讓整個(gè)項(xiàng)目的依賴關(guān)系變得非常難追蹤。做靜態(tài)代碼掃描、自動(dòng)測(cè)試、調(diào)用鏈分析的時(shí)候工具根本沒法跨文件還原完整的調(diào)用圖。這筆“維護(hù)稅”比線上那幾十毫秒的延遲更貴只是大多數(shù)團(tuán)隊(duì)要等項(xiàng)目腐化到一定程度才感覺得到。2. 如何定位并量化動(dòng)態(tài)包含的性能損失2.1 用基準(zhǔn)測(cè)試腳本做可復(fù)現(xiàn)對(duì)比要優(yōu)化一個(gè)問題第一步永遠(yuǎn)是量化它?？谡f無(wú)憑先搭一個(gè)獨(dú)立小項(xiàng)目把動(dòng)態(tài)包含和靜態(tài)包含的差距跑出來。本地環(huán)境我建議用phpstudy或者寶塔這類面板工具管理多個(gè)PHP版本切換PHP 7.4、8.0、8.2對(duì)比差異比手工編譯快得多。建一個(gè)bench目錄bench/ ├── static_inc.php ├── dynamic_inc.php └── files/ ├── a.php ├── b.php ├── c.php └── d.php每個(gè)文件里放一個(gè)簡(jiǎn)單的變量賦值模擬真實(shí)業(yè)務(wù)中模板文件或配置文件的加載?php $file_a_loaded true;static_inc.php的內(nèi)容?php $t0 microtime(true); $dir __DIR__ . /files; for ($i 0; $i 10000; $i) { include $dir . /a.php; include $dir . /b.php; include $dir . /c.php; include $dir . /d.php; } printf( static include: %.4f s, peak mem: %.2f MB\n, microtime(true) - $t0, memory_get_peak_usage(true) / 1024 / 1024 );dynamic_inc.php的內(nèi)容?php $t0 microtime(true); $dir __DIR__ . /files; $targets [a.php, b.php, c.php, d.php]; for ($i 0; $i 10000; $i) { $file $targets[$i % 4]; include $dir . / . $file; } printf( dynamic include: %.4f s, peak mem: %.2f MB\n, microtime(true) - $t0, memory_get_peak_usage(true) / 1024 / 1024 );跑的時(shí)候分兩種情況開opcache和關(guān)opcache。默認(rèn)CLI模式下opcache是關(guān)閉的需要手動(dòng)開啟php -d opcache.enable_cli1 bench/static_inc.php php -d opcache.enable_cli1 bench/dynamic_inc.php我在一臺(tái)普通云主機(jī)上測(cè)出來的相對(duì)趨勢(shì)差不多是這樣測(cè)試場(chǎng)景靜態(tài)include動(dòng)態(tài)include關(guān)閉opcache0.42s0.71s開啟opcache0.28s0.49s具體數(shù)值跟你機(jī)器有關(guān)不用糾結(jié)絕對(duì)值要看趨勢(shì)動(dòng)態(tài)包含在兩種情況下都慢而opcache對(duì)靜態(tài)include的放大優(yōu)化更明顯。這個(gè)結(jié)果說明動(dòng)態(tài)包含不僅自身開銷大還會(huì)拖累緩存策略發(fā)揮。2.2 用火焰圖、strace和Xdebug確認(rèn)瓶頸如果你面對(duì)的是一個(gè)大型項(xiàng)目沒法像上面那樣單獨(dú)隔離測(cè)試那就用工具從側(cè)面抓證據(jù)。Linux環(huán)境下strace是很好的系統(tǒng)調(diào)用統(tǒng)計(jì)工具。分別對(duì)靜態(tài)和動(dòng)態(tài)兩個(gè)腳本跑一遍重點(diǎn)觀察openat、stat、fstat這些文件相關(guān)調(diào)用次數(shù)strace -c -f php bench/dynamic_inc.php strace -c -f php bench/static_inc.php動(dòng)態(tài)版本的文件打開和狀態(tài)查詢次數(shù)通常會(huì)明顯偏多。這直接說明動(dòng)態(tài)包含在文件系統(tǒng)層多消耗了資源。Windows環(huán)境或者不方便用strace的話用Xdebug生成profile文件再用Qcachegrind打開也能定位include相關(guān)節(jié)點(diǎn)的時(shí)間占比。Xdebug 3的配置xdebug.modeprofile xdebug.output_dir/tmp/xdebug xdebug.start_with_requestyes跑一次入口腳本后output_dir下會(huì)生成cachegrind.out.*文件導(dǎo)入可視化工具看include和require相關(guān)函數(shù)占了多少總時(shí)間一目了然。想更細(xì)的話可以上火焰圖。用perf record抓調(diào)用棧再轉(zhuǎn)換成火焰圖動(dòng)態(tài)包含的路徑解析、系統(tǒng)調(diào)用、編譯動(dòng)作都會(huì)在棧上留下痕跡。不過對(duì)多數(shù)業(yè)務(wù)項(xiàng)目來說strace加Xdebug已經(jīng)足夠拍板了。2.3 檢查opcache配置與命中情況動(dòng)態(tài)包含性能差很多時(shí)候還疊加了opcache配置不當(dāng)。先看當(dāng)前opcache狀態(tài)用phpinfo()或者命令行php -i | grep opcache再寫個(gè)小腳本直觀拿命中率?php $status opcache_get_status(false); if ($status) { $stat $status[opcache_statistics]; echo hits: . $stat[hits] . PHP_EOL; echo misses: . $stat[misses] . PHP_EOL; echo hit rate: . round($stat[opcache_hit_rate], 2) . % . PHP_EOL; }注意opcache_get_status要裝了opcache擴(kuò)展且開啟后才好用CLI下記得用-d opcache.enable_cli1否則腳本里拿不到狀態(tài)。下面是一份比較穩(wěn)妥的opcache配置適合生產(chǎn)環(huán)境起步opcache.enable1 opcache.enable_cli0 opcache.validate_timestamps1 opcache.revalidate_freq60 opcache.max_accelerated_files10000 opcache.memory_consumption128 opcache.interned_strings_buffer16validate_timestamps和revalidate_freq是雙刃劍。設(shè)得太頻繁每次請(qǐng)求都要檢查文件mtime文件一多開銷滾雪球設(shè)成0或者太大線上代碼更新又不實(shí)時(shí)生效。要根據(jù)自己發(fā)布流程來調(diào)我一般配合CDN灰度線上設(shè)0發(fā)布時(shí)reload一次PHP-FPM。3. 替代方案與改造路徑別急著刪include3.1 先看一張方案對(duì)比表很多人一聽動(dòng)態(tài)包含性能差第一反應(yīng)是把所有include改成switch-case靜態(tài)分支。這確實(shí)有用但項(xiàng)目一大人工改起來很痛苦。更合理的思路是理解各類方案的適用邊界按需組合。方案靜態(tài)分析友好性opcache效益安全隱患改造成本適用場(chǎng)景保留動(dòng)態(tài)include差差高零不推薦長(zhǎng)期使用統(tǒng)一入口路由分發(fā)好好低中Web MVC項(xiàng)目改造Composer自動(dòng)加載好好低低-中新項(xiàng)目、類庫(kù)管理opcache.preload好極好低中核心類庫(kù)穩(wěn)定、CLI常駐場(chǎng)景綜合來看Web項(xiàng)目最推薦的組合是“統(tǒng)一入口路由分發(fā)Composer自動(dòng)加載”然后根據(jù)實(shí)際壓測(cè)情況決定要不要再上preload。3.2 統(tǒng)一入口加路由分發(fā)改造示例前端控制器模式是替代動(dòng)態(tài)包含最經(jīng)典的做法。還是那個(gè)按參數(shù)拼路徑的例子改造后是這樣?php $route [ home [ controller App\Controller\HomeController::class, method index, ], list [ controller App\Controller\ListController::class, method show, ], ]; $page $_GET[page] ?? home; if (!isset($route[$page])) { http_response_code(404); exit(Not Found); } $target $route[$page]; $controller new $target[controller](); $controller-{$target[method]}();這個(gè)寫法把“按參數(shù)找文件”變成了“按參數(shù)找類和方法”徹底消滅了動(dòng)態(tài)路徑拼接。好處是多重的首先是性能上入口文件、路由文件、控制器類文件都變成可靜態(tài)分析的依賴opcache能穩(wěn)定命中其次是安全上用戶輸入被路由表約束不再參與路徑拼接任意文件包含的問題從根上斷了再次是工程上每個(gè)Controller是個(gè)獨(dú)立類可以單測(cè)調(diào)用關(guān)系清晰可見。唯一要適應(yīng)的是目錄結(jié)構(gòu)和命名規(guī)范初期改造需要點(diǎn)耐心但收益非常明顯。3.3 用Composer自動(dòng)加載替代手寫include就算不徹底改MVC把include鏈換成Composer自動(dòng)加載也是一大進(jìn)步。先建composer.json{ autoload: { psr-4: { App\\: src/ } } }然后執(zhí)行composer dump-autoload -o-o參數(shù)會(huì)生成優(yōu)化過的類映射表。所謂優(yōu)化就是composer把“類名到文件路徑”的映射關(guān)系預(yù)先構(gòu)建成一張大映射表運(yùn)行時(shí)按類名直接查表不需要掃描目錄。再用composer dump-autoload --classmap-authoritative可以完全關(guān)閉對(duì)PSR-4目錄的實(shí)時(shí)掃描性能更好代價(jià)是新增類后必須重新dump。使用自動(dòng)加載后代碼里不再有手寫include?php namespace App\Controller; class HomeController { public function index(): string { return home page; } }入口處只需要注冊(cè)一次autoloaderrequire __DIR__ . /vendor/autoload.php;autoloader雖然本質(zhì)上也是運(yùn)行時(shí)動(dòng)態(tài)加載文件但它的加載規(guī)則穩(wěn)定、類映射明確opcache友好度遠(yuǎn)高于手寫動(dòng)態(tài)include。而且你徹底不需要關(guān)心類文件的加載順序了這是手寫include最容易出錯(cuò)的地方。3.4 如果必須動(dòng)態(tài)包含白名單映射加靜態(tài)分支有些場(chǎng)景比如插件系統(tǒng)必須加載外部擴(kuò)展文件真做不到完全消滅動(dòng)態(tài)包含。這種時(shí)候至少要做到“動(dòng)態(tài)輸入、靜態(tài)目標(biāo)”把變量約束到一個(gè)白名單里。?php $allowedPages [ login __DIR__ . /views/login.php, profile __DIR__ . /views/profile.php, report __DIR__ . /views/report.php, ]; $page $_GET[page] ?? login; if (!isset($allowedPages[$page])) { http_response_code(404); exit(Invalid page); } include $allowedPages[$page];這個(gè)寫法里用戶輸入只能決定選哪個(gè)預(yù)定義好的文件不再參與路徑拼接。目標(biāo)文件集合固定路徑解析的開銷降到最低security問題也被鎖死在白名單內(nèi)。如果性能要求再高一點(diǎn)可以把白名單數(shù)組定義成類常量配合opcache效果接近靜態(tài)include。另外一個(gè)細(xì)節(jié)業(yè)務(wù)代碼里能多require就盡量別用include。include一個(gè)不存在的文件只給個(gè)warning腳本繼續(xù)跑后面大概率打出更奇怪的錯(cuò)誤排查起來難受。require失敗會(huì)直接終止至少問題暴露得干脆。3.5 PHP 7.4 opcache.preload預(yù)加載提升到另一個(gè)層次如果你的項(xiàng)目依賴關(guān)系已經(jīng)理清而且核心類庫(kù)比較穩(wěn)定可以考慮PHP 7.4引入的opcache.preload。它的原理是把指定文件在PHP服務(wù)啟動(dòng)時(shí)就編譯進(jìn)共享內(nèi)存請(qǐng)求進(jìn)來直接復(fù)用連運(yùn)行時(shí)include操作都省了。php.ini里配置opcache.preload/var/www/html/preload.php opcache.preload_userwww-datapreload.php大致這樣寫?php $files [ __DIR__ . /src/Controller/HomeController.php, __DIR__ . /src/Controller/ListController.php, __DIR__ . /src/Repository/UserRepository.php, ]; foreach ($files as $file) { opcache_compile_file($file); }注意這里用的是opcache_compile_file不是include。include會(huì)執(zhí)行文件里的代碼opcache_compile_file只負(fù)責(zé)把文件編譯進(jìn)共享內(nèi)存不產(chǎn)生副作用安全得多。但preload有幾個(gè)坑必須先知道。預(yù)加載的類如果在業(yè)務(wù)代碼里被重新聲明會(huì)直接報(bào)fatal error。這意味著每次部署新代碼只要類定義有變化就得reload PHP-FPM否則新舊狀態(tài)沖突。另外opcache.preload在CLI模式下意義不大它主要服務(wù)常駐的PHP-FPM進(jìn)程池。用得好是性能利器用不好會(huì)把自己坑進(jìn)線上事故前期準(zhǔn)備不充分不建議輕易上。4. 真實(shí)案例一個(gè)模塊化CMS接口耗時(shí)優(yōu)化實(shí)錄4.1 項(xiàng)目背景與癥狀這個(gè)案例是我經(jīng)手的一個(gè)老牌模塊化CMS后臺(tái)接口。它的后臺(tái)管理側(cè)一直采用“模塊/動(dòng)作”的目錄風(fēng)格每個(gè)模塊一個(gè)文件夾按參數(shù)動(dòng)態(tài)加載對(duì)應(yīng)action文件。調(diào)用方反饋說后臺(tái)列表接口經(jīng)常轉(zhuǎn)圈監(jiān)控?cái)?shù)據(jù)顯示首頁(yè)接口平均耗時(shí)360ms部分慢請(qǐng)求超過600ms40并發(fā)壓測(cè)時(shí)QPS只有一百八十。一開始懷疑是SQL慢查詢但慢日志里并沒有特別離譜的語(yǔ)句。數(shù)據(jù)庫(kù)索引也檢查過沒發(fā)現(xiàn)明顯問題。于是把視角從數(shù)據(jù)庫(kù)轉(zhuǎn)向PHP執(zhí)行本身。4.2 定位過程和數(shù)據(jù)表現(xiàn)用strace對(duì)壓測(cè)過程中的PHP-FPM進(jìn)程做采樣發(fā)現(xiàn)openat和stat相關(guān)系統(tǒng)調(diào)用次數(shù)高得異常。再用Xdebug profile跑同一個(gè)接口include相關(guān)節(jié)點(diǎn)的耗時(shí)占比達(dá)到37%接近四成。配合opcache_get_status檢查命中率只有82%對(duì)于一個(gè)核心接口來說這個(gè)命中率非常不健康。順著代碼鏈路往下追發(fā)現(xiàn)這個(gè)問題接口對(duì)應(yīng)的動(dòng)態(tài)包含結(jié)構(gòu)大致是這樣?php $module preg_replace(/[^a-z0-9_]/i, , $_GET[module] ?? ); $action preg_replace(/[^a-z0-9_]/i, , $_GET[action] ?? ); if (!$module || !$action) { exit(bad request); } include $baseDir . /modules/{$module}/{$action}.php;雖然對(duì)參數(shù)做了正則清洗但這仍然是地地道道的動(dòng)態(tài)包含。每個(gè)接口進(jìn)來PHP都要現(xiàn)拼接路徑、解析文件、發(fā)起文件操作。而且這個(gè)action文件還會(huì)繼續(xù)include自己的子模塊文件一層套一層整個(gè)請(qǐng)求成了一個(gè)隱晦的“動(dòng)態(tài)包含樹”。4.3 改造過程改造分三步走。第一步把業(yè)務(wù)邏輯按Controller類重寫。原來每個(gè)action文件里是一堆過程式代碼現(xiàn)在整理成HomeController、ListController等類方法內(nèi)實(shí)現(xiàn)原來action的邏輯。第二步引入Composer按PSR-4規(guī)范做自動(dòng)加載。原來手工include的類庫(kù)全部挪進(jìn)src/目錄composer dump-autoload -o生成優(yōu)化映射表。第三步入口腳本改成路由分發(fā)。不再根據(jù)參數(shù)拼文件路徑而是根據(jù)路由表實(shí)例化控制器并調(diào)用方法?php require __DIR__ . /vendor/autoload.php; $router [ dashboard [App\Controller\DashboardController::class, index], list [App\Controller\ListController::class, index], ]; $action $_GET[action] ?? dashboard; if (!isset($router[$action])) { http_response_code(404); exit(Not Found); } [$controllerClass, $method] $router[$action]; $controller new $controllerClass(); $controller-{$method}();這里借用PHP 7.1支持的array destructuring語(yǔ)法代碼更簡(jiǎn)潔但如果你還在PHP 5.6時(shí)代就老老實(shí)實(shí)用兩行賦值。4.4 性能對(duì)比數(shù)據(jù)改完后在同一臺(tái)機(jī)器、同樣并發(fā)條件下重新壓測(cè)結(jié)果如下指標(biāo)改造前改造后提升幅度平均接口耗時(shí)360ms96ms73.3%QPS40并發(fā)180620244%opcache命中率82%99.2%提升明顯內(nèi)存峰值42MB33MB21.4%需要說明的是這組數(shù)據(jù)是單機(jī)環(huán)境多次壓測(cè)取的平均值不能直接照搬到你的項(xiàng)目里但它反映的趨勢(shì)是明確的動(dòng)態(tài)包含不是唯一瓶頸但它是疊加buff把SQL、IO、框架本身的性能問題全都放大了。改掉之后整個(gè)接口的延遲基數(shù)降下來了。4.5 改造過程踩過的坑這個(gè)項(xiàng)目改造不像文章寫得這么順中間至少踩了三個(gè)坑。第一個(gè)坑是preload上線翻車。當(dāng)時(shí)為了讓接口再快一點(diǎn)上了opcache.preload結(jié)果第二天發(fā)布新功能時(shí)新增的一個(gè)類跟預(yù)加載緩存的舊類定義沖突整個(gè)PHP-FPM報(bào)fatal error接口大面積502。后來才明白preload之后的類生命周期完全由常駐進(jìn)程管理代碼更新必須同步reload。解決方案很簡(jiǎn)單調(diào)整發(fā)布腳本部署完成后統(tǒng)一重啟PHP-FPM。第二個(gè)坑是PSR-4大小寫問題。本地Windows環(huán)境開發(fā)時(shí)類文件名大小寫寫錯(cuò)了也不報(bào)錯(cuò)一上Linux線上環(huán)境Composer自動(dòng)加載立刻找不到類。這個(gè)在Windows下開發(fā)、Linux部署的項(xiàng)目里特別常見我的建議是盡早換成大小寫敏感的文件系統(tǒng)習(xí)慣或者在CI流程里加一道文件名校驗(yàn)。第三個(gè)坑是opcache的revalidate_freq調(diào)太大導(dǎo)致線上代碼一直不生效。本地改了文件刷新頁(yè)面老樣子以為是緩存插件的問題折騰半天才想起來自己把validate_timestamps設(shè)成了0。調(diào)試期千萬(wàn)別圖省事把緩存時(shí)間拉滿不然改代碼全靠猜。5. 常見問題與排查技巧實(shí)錄5.1 高頻問題速查表現(xiàn)象可能原因解決方案接口慢、CPU偏高動(dòng)態(tài)包含文件數(shù)量多且opcache命中率低開啟opcache改造為路由分發(fā)或自動(dòng)加載使用include變量路徑后頁(yè)面白屏文件不存在include只產(chǎn)生warning改用require或在包含前用白名單校驗(yàn)動(dòng)態(tài)包含時(shí)類重復(fù)定義報(bào)錯(cuò)同一類文件被多個(gè)動(dòng)態(tài)路徑加載統(tǒng)一用autoload避免手寫include_once改代碼后線上不生效opcache.validate_timestamps0或revalidate_freq過大調(diào)整配置發(fā)布后reload PHP-FPMWindows正常、Linux報(bào)文件找不到文件名大小寫和路徑分隔符差異統(tǒng)一使用__DIR__拼接嚴(yán)格遵守PSR-4大小寫命名壓測(cè)工具顯示include耗時(shí)很高動(dòng)態(tài)路徑解析和系統(tǒng)調(diào)用疊加對(duì)比strace系統(tǒng)調(diào)用優(yōu)先做靜態(tài)依賴化改造5.2 實(shí)操心得分享做性能優(yōu)化有一個(gè)鐵律先量化再動(dòng)手。別靠感覺說這段代碼慢先用基準(zhǔn)腳本或者Xdebug拿到耗時(shí)占比再?zèng)Q定要不要改。動(dòng)態(tài)包含在很多項(xiàng)目里都只是“幫兇”真正的主謀可能是慢SQL、循環(huán)里的IO、或者過度復(fù)雜的ORM映射。直接埋頭改include容易白忙一場(chǎng)。還有個(gè)容易被忽略的點(diǎn)動(dòng)態(tài)包含不光是性能問題更是安全問題。只要用戶輸入的任何東西能影響到文件路徑就存在被構(gòu)造來加載任意文件的風(fēng)險(xiǎn)。所以哪怕是臨時(shí)補(bǔ)丁也請(qǐng)先用白名單映射擋住路徑拼接這行改動(dòng)不花多少時(shí)間但能把風(fēng)險(xiǎn)降一個(gè)數(shù)量級(jí)。真正動(dòng)手改造老項(xiàng)目我建議分步走。第一步給所有動(dòng)態(tài)包含加白名單把風(fēng)險(xiǎn)鎖住第二步把過程式action文件改造成Controller類方法理順業(yè)務(wù)邏輯第三步再上Composer自動(dòng)加載徹底告別手寫include。三步之間互相獨(dú)立每步都能單獨(dú)上線回滾沒必要一把梭把整個(gè)項(xiàng)目推倒重來。最后再分享一個(gè)小技巧改造完成后可以在測(cè)試環(huán)境用同樣的請(qǐng)求分別打一次strace和壓測(cè)腳本把前后兩組系統(tǒng)調(diào)用數(shù)和QPS數(shù)據(jù)存下來。這些數(shù)據(jù)不僅是給領(lǐng)導(dǎo)看的成果也是下次再做類似優(yōu)化時(shí)最可靠的參考基準(zhǔn)。