簡介這份2026最新易支付開源模板整合了前臺展示、用戶中心與后臺管理三大模塊面向需要快速搭建支付平臺的開發(fā)者與運營者尤其適合具備PHP基礎(chǔ)、希望二次開發(fā)或定制支付系統(tǒng)的中高級技術(shù)人員。壓縮包共1206個文件約20.05MB以svg圖標(biāo)、js腳本、php頁面、jpg圖片、css樣式及woff2字體等為主前端資源與后端邏輯分層清晰便于按模塊定位與替換。已有52人學(xué)習(xí)下載。資源核心價值在于提供一套可直接運行的支付系統(tǒng)骨架前臺涵蓋支付入口、狀態(tài)實時更新與渠道對接接口用戶中心支持賬戶信息管理、交易記錄查詢與充值提現(xiàn)后臺則覆蓋財務(wù)管理、用戶管理與數(shù)據(jù)分析并針對后臺加載緩慢與后門代碼等常見問題做了優(yōu)化處理。開發(fā)者可基于此模板快速完成界面調(diào)整、功能擴展與安全加固減少從零搭建的時間成本適合作為支付類項目的起步基礎(chǔ)或教學(xué)參考案例。1. 三合一易支付模板到底解決了誰的痛點如果你接過那種「前臺收銀臺 用戶中心 管理后臺」要分三次搭的私活就會明白三合一模板的價值不在代碼多漂亮而在省掉重復(fù)造輪子的時間。易支付這類聚合支付系統(tǒng)本質(zhì)是把多個上游通道封裝成統(tǒng)一的下單、回調(diào)、對賬接口前臺負(fù)責(zé)展示和拉起支付用戶中心負(fù)責(zé)商戶查訂單、看結(jié)算、改密鑰后臺負(fù)責(zé)通道配置、費率、風(fēng)控和人工補單。三塊拆開寫光是登錄態(tài)、訂單號生成規(guī)則、回調(diào)驗簽這三處就夠你對三遍。這份「2026最新易支付開源模板前臺用戶中心后臺三合一」的標(biāo)題指向的就是一套把這三端打包好的 PHP 系模板。它適合兩類人一是想快速搭一套自用收款系統(tǒng)的小團隊二是想拿它當(dāng)骨架二次開發(fā)支付 SaaS 的開發(fā)者。但要注意開源模板不等于開箱即用通道對接、回調(diào)安全、后臺權(quán)限這三塊永遠是翻車重災(zāi)區(qū)下面按「先立住原理、再動手復(fù)現(xiàn)、最后避坑」的順序拆開講。2. 三合一架構(gòu)拆解前臺、用戶中心、后臺各自管什么2.1 三端的職責(zé)邊界與數(shù)據(jù)流先把三端的分工說清楚不然后面配置會亂。前臺收銀臺只做三件事接收訂單參數(shù)、生成支付鏈接或二維碼、展示支付結(jié)果頁。它不碰數(shù)據(jù)庫里的商戶余額也不做驗簽決策只負(fù)責(zé)把用戶引導(dǎo)到正確的支付入口。用戶中心是商戶的自助面板核心是訂單查詢、結(jié)算記錄、API 密鑰管理、回調(diào)地址配置它讀的是訂單表和商戶表寫的是密鑰和回調(diào)配置。后臺是運營側(cè)管通道上游支付接口、費率模板、風(fēng)控規(guī)則、人工補單和日志審計。數(shù)據(jù)流是這樣的商戶系統(tǒng)調(diào)用易支付的下單接口 → 前臺生成訂單并落庫 → 用戶完成支付 → 上游異步回調(diào)到易支付的通知地址 → 系統(tǒng)驗簽后更新訂單狀態(tài) → 同時通知商戶的回調(diào)地址。這條鏈路里前臺是入口用戶中心是查詢窗口后臺是配置和兜底。三端共用一套訂單表和商戶表所以數(shù)據(jù)庫設(shè)計必須統(tǒng)一不能前臺一套、后臺一套。常見做法是把三端放在同一個 PHP 項目里用路由前綴區(qū)分比如/pay/走前臺/user/走用戶中心/admin/走后臺。這樣部署簡單但要注意后臺路徑必須做 IP 白名單或二次認(rèn)證否則就是熱詞里說的「后臺管理系統(tǒng)」被掃密碼字典的典型場景。2.2 目錄結(jié)構(gòu)與關(guān)鍵文件定位拿到一個三合一模板先別急著改代碼把目錄結(jié)構(gòu)摸清楚。典型結(jié)構(gòu)如下# 典型三合一易支付模板目錄結(jié)構(gòu)PHP 系 /pay/ # 前臺收銀臺入口 index.php # 下單入口接收商戶訂單參數(shù) submit.php # 生成支付鏈接/二維碼 return.php # 同步回調(diào)展示頁 notify.php # 異步回調(diào)處理核心驗簽邏輯 /user/ # 用戶中心 login.php # 商戶登錄 order.php # 訂單查詢 settle.php # 結(jié)算記錄 api_setting.php # API 密鑰與回調(diào)地址配置 /admin/ # 管理后臺 login.php # 管理員登錄務(wù)必加二次驗證 channel.php # 上游通道配置 rate.php # 費率模板 order_manage.php # 人工補單與訂單管理 log.php # 回調(diào)日志審計 /config/ database.php # 數(shù)據(jù)庫連接 channel.json # 通道密鑰配置不要提交到公開倉庫定位關(guān)鍵文件時優(yōu)先看notify.php和api_setting.php。前者決定回調(diào)驗簽是否安全后者決定商戶密鑰怎么存。很多模板把密鑰明文存數(shù)據(jù)庫這是血淚經(jīng)驗里最常見的坑后面避坑章節(jié)會細說。2.3 數(shù)據(jù)庫最小表結(jié)構(gòu)三端共用表不用多但字段要夠。最小可用集合是四張表商戶表、訂單表、通道表、回調(diào)日志表。-- 商戶表用戶中心讀寫的核心 CREATE TABLE merchant ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, username VARCHAR(64) NOT NULL UNIQUE, password_hash VARCHAR(255) NOT NULL, -- 用 password_hash() 生成不要存明文 api_key VARCHAR(64) NOT NULL, -- 商戶 API 密鑰 callback_url VARCHAR(255) DEFAULT , -- 商戶回調(diào)地址 balance DECIMAL(12,2) DEFAULT 0.00, -- 結(jié)算余額 status TINYINT DEFAULT 1, -- 1 正常 0 禁用 created_at DATETIME DEFAULT CURRENT_TIMESTAMP ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 訂單表前臺寫入用戶中心和后臺都讀 CREATE TABLE order ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, trade_no VARCHAR(32) NOT NULL UNIQUE, -- 易支付訂單號 merchant_id INT UNSIGNED NOT NULL, amount DECIMAL(10,2) NOT NULL, channel_id INT UNSIGNED NOT NULL, -- 走哪個上游通道 status TINYINT DEFAULT 0, -- 0 待支付 1 已支付 2 已回調(diào) notify_status TINYINT DEFAULT 0, -- 商戶回調(diào)是否成功 created_at DATETIME DEFAULT CURRENT_TIMESTAMP, paid_at DATETIME NULL, INDEX idx_merchant (merchant_id), INDEX idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 通道表后臺配置上游支付接口 CREATE TABLE channel ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, name VARCHAR(64) NOT NULL, gateway_url VARCHAR(255) NOT NULL, app_id VARCHAR(64) NOT NULL, app_secret VARCHAR(255) NOT NULL, -- 加密存儲不要明文 rate DECIMAL(5,4) DEFAULT 0.0060, -- 費率 status TINYINT DEFAULT 1 ) ENGINEInnoDB DEFAULT CHARSETutf8mb4; -- 回調(diào)日志表排查回調(diào)失敗的唯一后悔藥 CREATE TABLE notify_log ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, trade_no VARCHAR(32) NOT NULL, direction TINYINT NOT NULL, -- 1 上游回調(diào)進來 2 通知商戶出去 raw_data TEXT, result VARCHAR(255), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, INDEX idx_trade (trade_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字段說明trade_no用 32 位足夠建議格式是「日期 商戶 ID 隨機串」避免自增暴露單量。notify_status單獨一列是為了區(qū)分「用戶付了」和「商戶收到了通知」這兩個狀態(tài)在排查時經(jīng)常被混為一談。notify_log表一定要建回調(diào)出問題時沒有日志就是黑匣子只能靠猜。3. 本地跑通三合一模板的最小步驟3.1 環(huán)境準(zhǔn)備與依賴安裝PHP 系易支付模板一般要求 PHP 7.4 以上推薦 8.1MySQL 5.7 或 8.0。本地用 Docker 起環(huán)境最省事避免版本玄學(xué)。# 用 docker-compose 起 PHP MySQL 環(huán)境 # docker-compose.yml version: 3.8 services: web: image: php:8.1-apache ports: - 8080:80 volumes: - ./:/var/www/html depends_on: - db db: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: epay ports: - 3306:3306啟動后把模板解壓到當(dāng)前目錄訪問http://localhost:8080/pay/看前臺是否正常。如果報 500先看 Apache 錯誤日志八成是mod_rewrite沒開或.htaccess規(guī)則不兼容。PHP 8 下還要注意模板里有沒有用each()這類已移除函數(shù)有的話直接替換成foreach。依賴方面這類模板通常不依賴 Composer但會用到curl、openssl、pdo_mysql擴展。進容器執(zhí)行docker-php-ext-install pdo_mysql補上curl和openssl一般自帶。3.2 數(shù)據(jù)庫導(dǎo)入與配置修改把模板自帶的.sql文件導(dǎo)入然后改config/database.php。// config/database.php 關(guān)鍵配置 return [ host db, // docker-compose 里的服務(wù)名 port 3306, dbname epay, user root, password root123, charset utf8mb4, ];參數(shù)說明host在 Docker 環(huán)境里填服務(wù)名本地裸裝填127.0.0.1。charset必須是utf8mb4否則商戶名帶 emoji 會插入失敗。改完配置先訪問用戶中心登錄頁能打開說明數(shù)據(jù)庫通了。如果提示「連接超時」檢查 MySQL 容器是否健康docker ps看狀態(tài)。導(dǎo)入 SQL 時注意有些模板的 SQL 里帶了DEFINER語句MySQL 8 下會報權(quán)限錯誤用sed去掉再導(dǎo)入# 去掉 DEFINER 后再導(dǎo)入避免 MySQL 8 權(quán)限報錯 sed s/DEFINER[^ ]*//g epay.sql epay_clean.sql mysql -h 127.0.0.1 -uroot -proot123 epay epay_clean.sql3.3 配置一個測試通道并完成首單后臺登錄后先加一個測試通道。如果沒有真實上游可以用模板自帶的「測試通道」或自己寫一個模擬回調(diào)。// 模擬上游回調(diào)用于本地驗證 notify.php 邏輯 // 放到 /pay/mock_notify.php僅本地測試用 $trade_no $_GET[trade_no] ?? ; $amount $_GET[amount] ?? 0.01; $sign md5($trade_no . $amount . test_secret); // 與通道配置的密鑰一致 // 構(gòu)造上游回調(diào)數(shù)據(jù) $data [ trade_no $trade_no, amount $amount, status success, sign $sign, ]; // 直接調(diào)用 notify 邏輯本地測試可繞過 curl $_POST $data; include __DIR__ . /notify.php;邏輯說明這段代碼模擬上游支付成功后回調(diào)易支付的通知地址。sign的生成規(guī)則要和notify.php里的驗簽規(guī)則一致否則會被拒。參數(shù)trade_no從你前臺下單后拿到的訂單號填。跑通后去用戶中心看訂單狀態(tài)是否變成「已支付」再去后臺看回調(diào)日志有沒有記錄。這一步過了說明三端鏈路是通的剩下的就是接真實通道。4. 回調(diào)驗簽與訂單狀態(tài)機最容易翻車的地方4.1 驗簽邏輯怎么寫才不被繞過回調(diào)驗簽是整個系統(tǒng)安全的地基。常見錯誤是只驗sign不驗金額或者用比較簽名導(dǎo)致時序攻擊。正確做法是先按約定順序拼接參數(shù)用通道密鑰做 HMAC再用hash_equals比較。// notify.php 中的驗簽核心邏輯 function verifySign(array $params, string $secret): bool { // 1. 取出簽名其余參數(shù)按 key 升序排列 $sign $params[sign] ?? ; unset($params[sign], $params[sign_type]); ksort($params); // 2. 拼接成 keyvaluekeyvalue 形式 $pairs []; foreach ($params as $k $v) { if ($v || $v null) continue; // 空值不參與簽名 $pairs[] $k . . $v; } $raw implode(, $pairs); // 3. HMAC-SHA256 計算用 hash_equals 防時序攻擊 $calc hash_hmac(sha256, $raw, $secret); return hash_equals($calc, $sign); } // 使用示例 if (!verifySign($_POST, $channel[app_secret])) { file_put_contents(/tmp/notify_fail.log, json_encode($_POST) . PHP_EOL, FILE_APPEND); exit(sign error); }參數(shù)說明ksort保證拼接順序一致這是驗簽失敗最常見的原因——上游按字母序拼你按接收順序拼結(jié)果永遠對不上。hash_equals是 PHP 內(nèi)置的恒定時間比較函數(shù)別用?？罩凳欠駞⑴c簽名要和上游文檔對齊有的通道要求空值也拼進去有的要求跳過這個必須實測確認(rèn)。4.2 訂單狀態(tài)機的三個狀態(tài)與冪等處理訂單狀態(tài)不能隨便改要有明確的狀態(tài)機待支付0→ 已支付1→ 已回調(diào)商戶2。上游可能重復(fù)回調(diào)所以更新狀態(tài)必須冪等。// 冪等更新訂單狀態(tài)避免重復(fù)回調(diào)導(dǎo)致重復(fù)加款 $pdo-beginTransaction(); try { // 加行鎖防止并發(fā)回調(diào)同時讀到舊狀態(tài) $stmt $pdo-prepare(SELECT status FROM order WHERE trade_no ? FOR UPDATE); $stmt-execute([$trade_no]); $order $stmt-fetch(); if (!$order) { throw new Exception(order not found); } if ($order[status] 1) { // 已經(jīng)處理過直接返回成功不再加款 $pdo-commit(); exit(success); } // 更新訂單狀態(tài)并給商戶加款 $pdo-prepare(UPDATE order SET status 1, paid_at NOW() WHERE trade_no ?) -execute([$trade_no]); $pdo-prepare(UPDATE merchant SET balance balance ? WHERE id ?) -execute([$amount, $merchant_id]); $pdo-commit(); } catch (Exception $e) { $pdo-rollBack(); exit(fail); }邏輯說明FOR UPDATE行鎖是關(guān)鍵沒有它兩個并發(fā)回調(diào)會同時讀到status0然后各加一次款這就是典型的重復(fù)加款事故。status 1的判斷保證冪等重復(fù)回調(diào)直接返回success讓上游停止重試。金額加款要用數(shù)據(jù)庫層面的balance balance ?不要先讀再寫否則并發(fā)下會丟更新。4.3 通知商戶回調(diào)的重試策略易支付收到上游回調(diào)后還要通知商戶自己的回調(diào)地址。這一步失敗很常見因為商戶服務(wù)器可能臨時不可用。重試策略建議立即通知一次失敗后按 1 分鐘、5 分鐘、30 分鐘、2 小時、6 小時重試共 5 次。// 通知商戶回調(diào)帶重試次數(shù)記錄 function notifyMerchant(string $url, array $data, int $retry 0): bool { $ch curl_init($url); curl_setopt_array($ch, [ CURLOPT_POST true, CURLOPT_POSTFIELDS http_build_query($data), CURLOPT_RETURNTRANSFER true, CURLOPT_TIMEOUT 10, CURLOPT_CONNECTTIMEOUT 5, ]); $resp curl_exec($ch); $code curl_getinfo($ch, CURLINFO_HTTP_CODE); curl_close($ch); // 商戶返回 success 才算成功 if ($code 200 trim($resp) success) { return true; } // 記錄失敗交給定時任務(wù)重試 file_put_contents(/tmp/merchant_retry.log, json_encode([url $url, data $data, retry $retry]) . PHP_EOL, FILE_APPEND); return false; }參數(shù)說明CURLOPT_TIMEOUT設(shè) 10 秒別設(shè)太長否則回調(diào)線程被拖死。判斷成功不能只看 HTTP 200還要看響應(yīng)體是不是success這是易支付生態(tài)的約定。失敗記錄寫日志用 crontab 定時掃描重試不要在主回調(diào)流程里sleep重試會阻塞。5. 部署與運維避坑那些讓你半夜爬起來的問題5.1 后臺路徑暴露與弱口令現(xiàn)象后臺/admin/路徑被掃描器掃到日志里大量登錄失敗記錄甚至被撞庫成功。原因模板默認(rèn)后臺路徑就是/admin/且管理員賬號是admin/123456很多部署者不改。解決第一后臺路徑改成隨機串比如/manage_x7k2/在 Apache 或 Nginx 里做 rewrite。第二管理員密碼強制 12 位以上登錄加圖形驗證碼。第三后臺加 IP 白名單只允許運維 IP 訪問。第四登錄失敗 5 次鎖定 15 分鐘。這四條做完基本能擋住 99% 的自動化掃描。5.2 回調(diào)地址被偽造與金額篡改現(xiàn)象訂單金額是 100 元但回調(diào)里金額被改成 1 元系統(tǒng)按 1 元加款。原因驗簽時沒有把金額納入簽名或者驗簽通過后直接用回調(diào)里的金額更新訂單沒有和本地訂單金額比對。解決驗簽必須覆蓋所有業(yè)務(wù)字段包括金額、訂單號、狀態(tài)。驗簽通過后還要用trade_no查本地訂單比對回調(diào)金額和本地金額是否一致不一致直接拒絕并告警。這一步是很多模板漏掉的屬于典型的安全盲區(qū)。5.3 數(shù)據(jù)庫連接數(shù)打滿現(xiàn)象高峰期前臺下單報「Too many connections」用戶中心也打不開。原因PHP 每個請求建一個數(shù)據(jù)庫連接沒有連接池并發(fā)一高就爆。解決短期把 MySQL 的max_connections調(diào)到 500同時檢查代碼里有沒有忘記close的連接。長期方案是引入連接池或者用 Redis 緩存訂單查詢結(jié)果減少數(shù)據(jù)庫壓力。另外notify.php里的數(shù)據(jù)庫操作要盡快釋放連接不要在回調(diào)里做耗時操作。5.4 時區(qū)不一致導(dǎo)致對賬對不上現(xiàn)象用戶中心顯示的訂單時間和后臺日志時間差 8 小時對賬時怎么都對不上。原因PHP 時區(qū)、MySQL 時區(qū)、服務(wù)器系統(tǒng)時區(qū)三者不一致。解決統(tǒng)一用Asia/Shanghai。PHP 里date_default_timezone_set(Asia/Shanghai)MySQL 里SET time_zone 08:00服務(wù)器timedatectl set-timezone Asia/Shanghai。三處都改完時間才一致。這個坑不致命但很煩建議部署第一天就統(tǒng)一。5.5 日志文件撐爆磁盤現(xiàn)象服務(wù)器運行一個月后磁盤滿了網(wǎng)站 500。原因回調(diào)日志、錯誤日志沒有輪轉(zhuǎn)一直追加。解決用logrotate配置日志輪轉(zhuǎn)每天切割保留 7 天?；蛘咴诖a里按大小切割超過 100MB 就重命名。notify_log表也要定期歸檔超過 3 個月的記錄導(dǎo)出后刪除否則單表幾百萬行查詢會變慢。6. 二次開發(fā)進階把三合一模板改成自己的支付網(wǎng)關(guān)6.1 通道插件化新增一個上游只要加一個文件模板自帶的通道配置是寫死在代碼里的加新通道要改多處。更好的做法是插件化每個通道一個類實現(xiàn)統(tǒng)一接口。// 通道接口所有上游實現(xiàn)這個接口 interface ChannelInterface { public function pay(array $order): string; // 返回支付鏈接或二維碼 public function verify(array $callback): bool; // 驗簽 public function getAmount(array $callback): float; // 從回調(diào)取金額 } // 新增一個通道只需實現(xiàn)接口放到 /channel/ 目錄 class AlipayChannel implements ChannelInterface { private string $appId; private string $secret; public function __construct(array $config) { $this-appId $config[app_id]; $this-secret $config[app_secret]; } public function pay(array $order): string { // 拼接上游支付參數(shù)返回支付 URL $params [ app_id $this-appId, out_trade_no $order[trade_no], total_amount $order[amount], notify_url $order[notify_url], ]; ksort($params); $params[sign] hash_hmac(sha256, http_build_query($params), $this-secret); return https://upstream.example.com/pay? . http_build_query($params); } public function verify(array $callback): bool { $sign $callback[sign] ?? ; unset($callback[sign]); ksort($callback); $calc hash_hmac(sha256, http_build_query($callback), $this-secret); return hash_equals($calc, $sign); } public function getAmount(array $callback): float { return (float)($callback[total_amount] ?? 0); } }邏輯說明接口定義三個方法pay負(fù)責(zé)生成支付入口verify負(fù)責(zé)驗簽getAmount負(fù)責(zé)取金額。新增通道時只寫一個類文件在后臺通道配置里選類名即可不用改前臺和回調(diào)邏輯。參數(shù)說明notify_url是易支付自己的回調(diào)地址傳給上游out_trade_no用易支付訂單號保證唯一。這樣改造后加通道從半天縮短到半小時。6.2 用定時任務(wù)做對賬與補單回調(diào)可能丟所以每天要對賬。寫一個腳本拉取上游昨天的賬單和本地訂單比對找出「上游已支付但本地未更新」的訂單自動補單。# crontab 每天凌晨 2 點對賬 0 2 * * * /usr/bin/php /var/www/html/cron/reconcile.php /var/log/epay_reconcile.log 21// cron/reconcile.php 核心邏輯 $date date(Y-m-d, strtotime(-1 day)); // 1. 從各通道拉取昨日成功訂單 $upstreamOrders fetchUpstreamOrders($date); // 2. 查本地已支付訂單 $localOrders $pdo-query(SELECT trade_no FROM order WHERE status 1 AND DATE(paid_at) $date) -fetchAll(PDO::FETCH_COLUMN); // 3. 差集就是漏單 $missing array_diff($upstreamOrders, $localOrders); foreach ($missing as $tradeNo) { // 補單更新狀態(tài)并加款注意冪等 reconcileOrder($tradeNo); }參數(shù)說明fetchUpstreamOrders需要各通道提供對賬接口沒有的話至少導(dǎo)出 CSV 手動比對。reconcileOrder內(nèi)部要復(fù)用第 4 章的冪等邏輯避免重復(fù)加款。對賬腳本跑完發(fā)郵件或釘釘通知漏單數(shù)量大于 0 就告警。6.3 驗證清單上線前必須過的 8 項檢查上線前照著這張表過一遍能省掉大部分半夜救火。檢查項驗證方法通過標(biāo)準(zhǔn)后臺路徑訪問默認(rèn)/admin/返回 404 或跳轉(zhuǎn)管理員密碼嘗試弱口令登錄失敗并鎖定回調(diào)驗簽篡改金額后回調(diào)被拒絕并記錄日志冪等加款同一訂單回調(diào)兩次只加款一次商戶通知商戶回調(diào)地址不可用進入重試隊列時區(qū)一致對比前臺和后臺時間完全一致日志輪轉(zhuǎn)查看日志目錄有切割配置對賬腳本手動跑一次能找出漏單這張表我一般會打印出來貼在工位上每上線一個新通道就重過一遍。血淚經(jīng)驗是驗簽和冪等這兩項最容易偷懶但恰恰是出事時最致命的。6.4 一個具體技巧用 Redis 緩存訂單查詢用戶中心查訂單是高頻操作每次都查 MySQL 壓力大。用 Redis 緩存最近 10 分鐘的訂單查詢結(jié)果命中率能到 80% 以上。// 用戶中心訂單查詢加 Redis 緩存 $cacheKey order:merchant:{$merchantId}:page:{$page}; $redis new Redis(); $redis-connect(127.0.0.1, 6379); $cached $redis-get($cacheKey); if ($cached ! false) { $orders json_decode($cached, true); } else { $orders $pdo-query(SELECT * FROM order WHERE merchant_id $merchantId ORDER BY id DESC LIMIT 20) -fetchAll(PDO::FETCH_ASSOC); $redis-setex($cacheKey, 600, json_encode($orders)); // 緩存 10 分鐘 }參數(shù)說明setex的 600 是過期時間訂單狀態(tài)會變所以緩存不能太久。下單和回調(diào)成功時要主動刪掉對應(yīng)商戶的緩存避免查到舊狀態(tài)。這個技巧不復(fù)雜但能把用戶中心的響應(yīng)從 200ms 降到 20ms體驗提升明顯。我自己維護這套模板兩年多最大的習(xí)慣就是每次改完回調(diào)邏輯一定用模擬腳本跑三遍正常回調(diào)、重復(fù)回調(diào)、篡改金額回調(diào)。三遍都過才敢上線。希望幫到你。本文還有配套的精品資源點擊獲取