簡(jiǎn)介這是一套基于PHP開(kāi)發(fā)的卡密驗(yàn)證系統(tǒng)面向需要為在線(xiàn)服務(wù)、游戲或軟件產(chǎn)品搭建激活碼/兌換碼驗(yàn)證機(jī)制的個(gè)人開(kāi)發(fā)者與中小企業(yè)。系統(tǒng)提供完整的前端交互與后臺(tái)管理覆蓋卡密生成與狀態(tài)管理、訂單及支付回調(diào)處理、用戶(hù)權(quán)限管理、銷(xiāo)售統(tǒng)計(jì)等模塊并包含API接口可供二次集成。資源包共451個(gè)文件體積約1.35MB其中包含205個(gè)php核心邏輯文件、68個(gè)html頁(yè)面、34個(gè)js腳本與26個(gè)css樣式以及png/svg圖片和字體等靜態(tài)資源目錄按admin后臺(tái)、data數(shù)據(jù)、extend擴(kuò)展及支付接口等模塊劃分方便定位與維護(hù)已有1872人學(xué)習(xí)下載。通過(guò)部署這套系統(tǒng)可以快速搭建從用戶(hù)購(gòu)買(mǎi)、卡密發(fā)放到驗(yàn)證使用全流程閉環(huán)尤其適合希望快速上線(xiàn)付費(fèi)授權(quán)業(yè)務(wù)的開(kāi)發(fā)者參考或直接使用。無(wú)論是搭建正式授權(quán)平臺(tái)還是學(xué)習(xí)PHP項(xiàng)目架構(gòu)這套卡密系統(tǒng)都具備實(shí)用價(jià)值。1. 一套 PHP 卡密驗(yàn)證系統(tǒng)后臺(tái)功能到底要完善到什么程度很多做獨(dú)立軟件、插件和游戲工具的作者最后都會(huì)遇到授權(quán)問(wèn)題。卡密驗(yàn)證系統(tǒng)是成本最低的方案用戶(hù)填一串卡密客戶(hù)端根據(jù)返回結(jié)果決定是否放行。PHP 在這個(gè)場(chǎng)景里出現(xiàn)頻率最高因?yàn)椴渴痖T(mén)檻低一臺(tái)支持 PHP-FPM 的云主機(jī)加上寶塔面板或虛擬主機(jī)就能把后臺(tái)管理系統(tǒng)跑起來(lái)不需要獨(dú)立構(gòu)建原生服務(wù)。不過(guò)多數(shù)從零手寫(xiě)的卡密系統(tǒng)并不完善。比較常見(jiàn)的是只有一張卡密表一個(gè) ajax 驗(yàn)證接口后臺(tái)只有“查卡密”和“改狀態(tài)”兩個(gè)功能。這種系統(tǒng)的瓶頸不在功能少而在狀態(tài)管理不閉合一碼多用、過(guò)期卡無(wú)法自動(dòng)失效、設(shè)備綁定隨意覆蓋、驗(yàn)證日志缺失用戶(hù)來(lái)投訴時(shí)沒(méi)有任何可追溯的證據(jù)。所以這里要講的不是一份“能跑就行”的腳本而是一套后臺(tái)功能完整的 PHP 卡密驗(yàn)證系統(tǒng)該怎么落地。重點(diǎn)放在數(shù)據(jù)表狀態(tài)機(jī)、驗(yàn)證 API 的并發(fā)安全、后臺(tái)的批量管理和安全加固上。適合正準(zhǔn)備自研授權(quán)系統(tǒng)的開(kāi)發(fā)者也適合接手現(xiàn)有卡密系統(tǒng)后想重構(gòu)后臺(tái)的工程師。2. 卡密系統(tǒng)數(shù)據(jù)模型從狀態(tài)機(jī)到綁定關(guān)系后臺(tái)功能完善的前提是數(shù)據(jù)表結(jié)構(gòu)能支撐所有操作?？芟到y(tǒng)的核心表只有三張卡密表、設(shè)備綁定表、驗(yàn)證日志表另外配一張產(chǎn)品類(lèi)型表。很多所謂“功能完善”的后臺(tái)其實(shí)只是把數(shù)據(jù)表字段直接暴露在界面上。2.1 卡密表狀態(tài)機(jī)是業(yè)務(wù)邊界卡密表不是只有一個(gè) status 字段那么簡(jiǎn)單。單獨(dú)看狀態(tài)字段常見(jiàn)取值是 0 未使用、1 已使用、2 作廢、3 凍結(jié)是否真正可用要結(jié)合 expires_at 和 status 一起判斷。這樣設(shè)計(jì)可以避免定時(shí)任務(wù)把過(guò)期卡刷成單獨(dú)狀態(tài)也方便后臺(tái)做“全部有效卡密”查詢(xún)。建表語(yǔ)句如下CREATE TABLE card_keys ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, card_key VARCHAR(32) NOT NULL COMMENT 卡號(hào)對(duì)外字符串, card_code VARCHAR(32) NOT NULL COMMENT 卡密與卡號(hào)組合使用, product_id INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 產(chǎn)品類(lèi)型ID, duration INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 激活后有效天數(shù)0表示永久, bind_device VARCHAR(64) NOT NULL DEFAULT COMMENT 第一個(gè)綁定設(shè)備的SHA256值, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未使用 1已使用 2作廢 3凍結(jié), expires_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 到期時(shí)間戳0表示永久, used_at INT UNSIGNED NOT NULL DEFAULT 0 COMMENT 首次激活時(shí)間, created_at INT UNSIGNED NOT NULL, remark VARCHAR(255) NOT NULL DEFAULT , PRIMARY KEY (id), UNIQUE KEY idx_key (card_key), KEY idx_product (product_id), KEY idx_expires (expires_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這里有幾個(gè)關(guān)鍵參數(shù)要說(shuō)明。card_key 對(duì)外唯一業(yè)務(wù)查詢(xún)一律用 card_key 定位card_code 不必全局唯一但驗(yàn)證時(shí)必須和 card_key 一起傳否則相當(dāng)于只有一層防護(hù)。duration 和 expires_at 同時(shí)存在是因?yàn)榧せ顣r(shí)要用 duration 算出最終時(shí)間戳寫(xiě)入 expires_at。如果卡密是渠道商批量采購(gòu)還要額外加 order_id 字段方便溯源。status 字段的狀態(tài)流轉(zhuǎn)要在后端控制不能允許任意跳轉(zhuǎn)。未使用的卡只能在驗(yàn)證接口里變成已使用已使用的卡不能直接改回未使用作廢和凍結(jié)操作后臺(tái)要限制到管理員角色。為了更容易讀懂狀態(tài)判斷邏輯把常用狀態(tài)值列成一張表status含義有效判斷0未使用可激活1已使用expires_at 為 0 或大于當(dāng)前時(shí)間2作廢永遠(yuǎn)不可用3凍結(jié)不可用解凍后恢復(fù)原狀態(tài)2.2 設(shè)備綁定表與驗(yàn)證日志表后臺(tái)審計(jì)的基礎(chǔ)卡密一碼多用是常見(jiàn)糾紛來(lái)源。只用一個(gè) bind_device 字段記錄單設(shè)備不能滿(mǎn)足“同一卡密在 KTV 點(diǎn)歌機(jī)、電腦、手機(jī)之間換綁”的場(chǎng)景。所以我一般會(huì)單獨(dú)建設(shè)備綁定表記錄每個(gè)卡密在所有設(shè)備上的激活歷史CREATE TABLE card_bindings ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, card_id INT UNSIGNED NOT NULL, device_hash CHAR(64) NOT NULL COMMENT 設(shè)備ID的SHA256, created_at INT UNSIGNED NOT NULL, PRIMARY KEY (id), UNIQUE KEY idx_card_device (card_id, device_hash), KEY idx_device (device_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;綁定表允許同一個(gè)卡密對(duì)應(yīng)多個(gè)設(shè)備最大設(shè)備數(shù)由產(chǎn)品類(lèi)型配置決定。驗(yàn)證時(shí)先查這張表如果 device_hash 已存在則放行否則判斷當(dāng)前綁定數(shù)是否到達(dá)上限。注意 device_hash 不能直接存原始設(shè)備號(hào)客戶(hù)端上報(bào)的 MAC、機(jī)器碼、Android ID 都屬于敏感信息存哈希是底線(xiàn)。哈希函數(shù)用 SHA256并且建議在服務(wù)端追加一個(gè)鹽值再算。驗(yàn)證日志表是為了讓后臺(tái)“可查”。每次驗(yàn)證請(qǐng)求至少記錄卡密、設(shè)備、IP、瀏覽器信息、結(jié)果碼和時(shí)間。字段數(shù)量不用太多但必須有聯(lián)合索引覆蓋 card_id 和 created_at否則數(shù)據(jù)量上來(lái)之后后臺(tái)查日志會(huì)慢CREATE TABLE card_verify_logs ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, card_id INT UNSIGNED NOT NULL, action TINYINT NOT NULL COMMENT 1驗(yàn)證 2綁定 3換綁 4續(xù)期, device_hash CHAR(64) NOT NULL, client_ip VARCHAR(45) NOT NULL, user_agent VARCHAR(255) NOT NULL, result TINYINT NOT NULL COMMENT 0成功 1卡密不存在 2已作廢 3已凍結(jié) 4設(shè)備超限 5過(guò)期, created_at INT UNSIGNED NOT NULL, PRIMARY KEY (id), KEY idx_card_time (card_id, created_at), KEY idx_device (device_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;這條日志表的設(shè)計(jì)要注意查詢(xún)后臺(tái)“某卡密的驗(yàn)證記錄”走 idx_card_time查詢(xún)“某設(shè)備有沒(méi)有在其他卡密上出現(xiàn)過(guò)”走 idx_device。如果只記錄成功日志一旦用戶(hù)說(shuō)激活失敗后臺(tái)看不到失敗原因就只能讓用戶(hù)截圖。所以 result 字段要記錄完整結(jié)果碼失敗原因用數(shù)字表示展示層再轉(zhuǎn)換成文案。2.3 產(chǎn)品類(lèi)型與套餐參數(shù)管理卡密驗(yàn)證系統(tǒng)如果不區(qū)分產(chǎn)品類(lèi)型每次發(fā)布新版本都要重新生成一套卡密后臺(tái)管理成本很高。常見(jiàn)做法是加一張 product 表后臺(tái)先建好“基礎(chǔ)版、專(zhuān)業(yè)版、終身版”等產(chǎn)品然后給每個(gè)產(chǎn)品配置默認(rèn)時(shí)長(zhǎng)和設(shè)備綁定數(shù)量CREATE TABLE card_products ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, product_name VARCHAR(50) NOT NULL, default_duration INT UNSIGNED NOT NULL DEFAULT 30, max_bindings TINYINT UNSIGNED NOT NULL DEFAULT 1, price DECIMAL(10,2) NOT NULL DEFAULT 0, is_active TINYINT NOT NULL DEFAULT 1, created_at INT UNSIGNED NOT NULL, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;后臺(tái)對(duì)產(chǎn)品的增刪改查本質(zhì)上就是對(duì)這個(gè)表的操作。需要注意 product_id 在卡密表里加了索引所以產(chǎn)品表可以隨便改不會(huì)影響驗(yàn)證速度。每次生成的卡密把 duration 和 max_bindings 快照到卡密記錄里而不是生成時(shí)去聯(lián)查產(chǎn)品表否則管理員后來(lái)改套餐時(shí)長(zhǎng)已售出的卡密到期時(shí)間就全變了。這個(gè)“生成時(shí)快照”的習(xí)慣是后臺(tái)功能完善的隱藏要求。3. 用 PHP 寫(xiě)卡密生成算法和驗(yàn)證 API可直接落地的代碼這一章給出最小可用實(shí)現(xiàn)。生成算法負(fù)責(zé)產(chǎn)出不可枚舉的卡密驗(yàn)證 API 負(fù)責(zé)在并發(fā)環(huán)境下安全地完成激活、綁定和續(xù)期。代碼基于 PHP 8依賴(lài) PDO 連接 MySQL 或 MariaDB。3.1 卡密生成算法隨機(jī)性、去重與防枚舉卡密生成不能直接用 uniqid() 或 mt_rand() 拼字符串前者有時(shí)間前綴后者不夠安全。推薦隨機(jī)源是 random_int() 或者 random_bytes()再通過(guò) base62 字符表去掉易混淆字符。一個(gè)可復(fù)用的生成函數(shù)如下function base62_encode(int $len 16): string { $chars ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz23456789; $result ; for ($i 0; $i $len; $i) { $result . $chars[random_int(0, strlen($chars) - 1)]; } return $result; }這個(gè)函數(shù)特意去掉了 0、O、1、I避免用戶(hù)看著像又輸不對(duì)。random_int() 在 PHP 7 之后使用操作系統(tǒng)的 CSPRNG安全強(qiáng)度可以滿(mǎn)足激活碼場(chǎng)景?？芪粩?shù)要根據(jù)業(yè)務(wù)量選擇16 位 base62 大約提供 95 bit 熵配合數(shù)據(jù)庫(kù)唯一索引枚舉成本極高如果只是臨時(shí)給幾百個(gè)用戶(hù)用12 位也夠。位數(shù)和熵的關(guān)系如下長(zhǎng)度熵估算建議場(chǎng)景10 位59 bit內(nèi)部測(cè)試12 位71 bit幾千用戶(hù)的小軟件16 位95 bit公開(kāi)渠道大量分發(fā)批量生成時(shí)還要考慮重復(fù)問(wèn)題。雖然碰撞概率極低但為了可靠我一般會(huì)在插入前用 do-while 查一次 card_key 是否存在然后讓數(shù)據(jù)庫(kù)唯一索引兜底function batch_create_cards(int $productId, int $count, int $days): array { $pdo get_pdo(); $stmt $pdo-prepare( INSERT INTO card_keys (card_key, card_code, product_id, duration, expires_at, created_at) VALUES (:key, :code, :pid, :days, :expires, :now) ); $cards []; $now time(); for ($i 0; $i $count; $i) { do { $key base62_encode(16); $code base62_encode(12); $exists $pdo-prepare(SELECT id FROM card_keys WHERE card_key :key); $exists-execute([:key $key]); } while ($exists-fetch()); $expiresAt $days 0 ? $now $days * 86400 : 0; $stmt-execute([ :key $key, :code $code, :pid $productId, :days $days, :expires $expiresAt, :now $now ]); $cards[] [card_key $key, card_code $code]; } return $cards; }這段代碼里有一處性能細(xì)節(jié)每次循環(huán)都 prepare 一次 SELECT 和一次 INSERT對(duì)于幾千張卡來(lái)說(shuō)沒(méi)問(wèn)題如果一次生成十萬(wàn)張要改成用 INSERT ... VALUES 批量拼接并讓數(shù)據(jù)庫(kù)唯一索引解決重復(fù)程序里去掉 do-while。另外批量生成的卡密應(yīng)該在后臺(tái)以文件形式下載不要把卡密直接顯示在后臺(tái)頁(yè)面上防止瀏覽器緩存泄露。3.2 驗(yàn)證 API狀態(tài)流轉(zhuǎn)、設(shè)備綁定與錯(cuò)誤碼驗(yàn)證接口是整個(gè)卡密系統(tǒng)的咽喉必須在一個(gè)數(shù)據(jù)庫(kù)事務(wù)里完成“讀狀態(tài)、寫(xiě)狀態(tài)”兩個(gè)動(dòng)作。如果先用 SELECT 查到卡密再在應(yīng)用層判斷之后 UPDATE兩個(gè)請(qǐng)求同時(shí)進(jìn)來(lái)時(shí)可能都讀到“未使用”導(dǎo)致一卡多發(fā)。解決辦法是在事務(wù)里使用 SELECT ... FOR UPDATE 鎖住行function verify_card(string $cardKey, string $cardCode, string $deviceId, int $productId): array { $pdo get_pdo(); $pdo-beginTransaction(); $stmt $pdo-prepare( SELECT * FROM card_keys WHERE card_key :key AND card_code :code AND product_id :pid FOR UPDATE ); $stmt-execute([:key $cardKey, :code $cardCode, :pid $productId]); $card $stmt-fetch(); if (!$card) { $pdo-rollBack(); return [code 1, msg 卡密不存在]; } $now time(); if ($card[status] 2 || $card[status] 3) { $pdo-rollBack(); return [code 3, msg 卡密已被作廢或凍結(jié)]; } if ($card[status] 1) { $pdo-rollBack(); if ($card[expires_at] 0 $now $card[expires_at]) { return [code 5, msg 卡密已過(guò)期]; } return [code 0, msg 驗(yàn)證成功, expires_at $card[expires_at]]; } // 未使用檢查設(shè)備綁定數(shù)量 $deviceHash hash(sha256, $deviceId . SALT); $bindCountStmt $pdo-prepare( SELECT COUNT(*) FROM card_bindings WHERE card_id :id ); $bindCountStmt-execute([:id $card[id]]); $bindCount (int)$bindCountStmt-fetchColumn(); if ($bindCount (int)$card[max_bindings]) { $pdo-rollBack(); return [code 4, msg 設(shè)備綁定數(shù)量已達(dá)上限]; } $expiresAt $card[duration] 0 ? $now $card[duration] * 86400 : 0; $updateStmt $pdo-prepare( UPDATE card_keys SET status 1, bind_device :dev, expires_at :exp, used_at :used WHERE id :id AND status 0 ); $updateStmt-execute([ :dev $deviceHash, :exp $expiresAt, :used $now, :id $card[id] ]); $bindStmt $pdo-prepare( INSERT INTO card_bindings (card_id, device_hash, created_at) VALUES (:id, :dev, :now) ); $bindStmt-execute([:id $card[id], :dev $deviceHash, :now $now]); $pdo-commit(); return [code 0, msg 激活成功, expires_at $expiresAt]; }代碼里有幾個(gè)參數(shù)需要注意。FOR UPDATE 必須和 beginTransaction 配合使用否則鎖在當(dāng)前連接上是自動(dòng)提交的等于沒(méi)鎖。UPDATE 語(yǔ)句里的 WHERE status 0 是第二道保險(xiǎn)即使前面的 SELECT 因?yàn)楦綦x級(jí)別讀到舊數(shù)據(jù)UPDATE 行數(shù)影響為 0 時(shí)也能識(shí)別出已經(jīng)被并發(fā)激活。設(shè)備哈希的鹽值 SALT 要放在配置文件里不能寫(xiě)到公共 PHP 文件名中。錯(cuò)誤碼要設(shè)計(jì)成“業(yè)務(wù)碼 HTTP 狀態(tài)碼”分離的形式。為了讓客戶(hù)端和后臺(tái)日志都能看懂業(yè)務(wù)碼從 0 開(kāi)始遞增0 成功、1 卡密不存在、2 卡密重復(fù)使用、3 作廢或凍結(jié)、4 設(shè)備超限、5 過(guò)期。返回 JSON 時(shí)可以帶上 HTTP 200業(yè)務(wù)碼由客戶(hù)端判斷也可以讓非 0 結(jié)果返回 HTTP 401但那樣接入其他語(yǔ)言會(huì)多一層判斷。提示在 UPDATE 和 INSERT 之后如果執(zhí)行過(guò)程中拋出異常記得調(diào)用 rollBack否則 PHP 腳本退出前連接會(huì)一直占著事務(wù)鎖影響其他驗(yàn)證請(qǐng)求。3.3 簽名防刷與參數(shù)校驗(yàn)驗(yàn)證接口如果只接收 card_key 和 card_code最大的風(fēng)險(xiǎn)是被人用固定卡密來(lái)回調(diào)嘗試批量綁定或探測(cè)有效卡密。常見(jiàn)的防護(hù)方式是在參數(shù)里增加 timestamp 和 sign。sign 的生成規(guī)則放在客戶(hù)端和服務(wù)端各自維護(hù)一份function check_signature(array $params, string $secret): bool { $sign $params[sign] ?? ; unset($params[sign]); ksort($params); $raw urldecode(http_build_query($params)) . $secret; $expected md5($raw); return hash_equals($expected, $sign); }簽名參數(shù)說(shuō)明如下timestamp 必須是 Unix 時(shí)間戳服務(wù)端檢查與當(dāng)前時(shí)間差不超過(guò) 300 秒防止重放。sign 計(jì)算順序是去掉 sign 后按參數(shù)名字典排序拼成 query string 后追加 secret再計(jì)算 md5。md5 不用于防碰撞只是防篡改所以足夠。拿到客戶(hù)端傳來(lái)的 salt 或者設(shè)備號(hào)時(shí)要判斷類(lèi)型避免把數(shù)組傳進(jìn)來(lái)的異常。如果前端是瀏覽器還會(huì)遇到 PHP 跨域問(wèn)題響應(yīng)頭加 Access-Control-Allow-Origin 之外還需要把回調(diào)方法限制成白名單不能直接使用 jsonp 拼接任意回調(diào)名。4. 后臺(tái)管理系統(tǒng)卡密生成、導(dǎo)入導(dǎo)出、日志統(tǒng)計(jì)與安全加固后臺(tái)本身也是一個(gè) Web 應(yīng)用常見(jiàn)做法是用 PHP 模板渲染頁(yè)面或者用 Vue3 后臺(tái)管理系統(tǒng)做前端、PHP 提供 API。不管哪種方式核心功能都集中在四塊登錄鑒權(quán)、卡密管理、批量導(dǎo)入導(dǎo)出、日志統(tǒng)計(jì)。4.1 后臺(tái)登錄會(huì)話(huà)、驗(yàn)證碼與越權(quán)防護(hù)后臺(tái)管理員表至少要包含 id、username、password_hash、role、last_login_at。密碼用 password_hash() 保存登錄驗(yàn)證用 password_verify()。PHP 7.4 之后默認(rèn)使用 bcrypt寶塔面板默認(rèn) PHP 環(huán)境可以直接用不需要額外裝擴(kuò)展。為了防暴力破解登錄接口要加驗(yàn)證碼和失敗次數(shù)限制我傾向于在 Session 中記錄連續(xù)失敗次數(shù)超過(guò) 5 次鎖定 15 分鐘session_start(); if ($_SESSION[login_fails] 5 time() - $_SESSION[fails_ts] 900) { exit(嘗試次數(shù)過(guò)多請(qǐng)稍后再試); } if (!check_captcha($_POST[captcha])) { $_SESSION[login_fails]; exit(驗(yàn)證碼錯(cuò)誤); }驗(yàn)證碼可以用 GD 庫(kù)畫(huà)一個(gè) 4 位字符串也可以使用現(xiàn)成庫(kù)。如果后臺(tái)入口在寶塔上部署記得確認(rèn) PHP 已啟用 gd 擴(kuò)展否則驗(yàn)證碼頁(yè)面一片空白。權(quán)限控制不能只靠登錄態(tài)每個(gè)管理操作都要檢查當(dāng)前用戶(hù)的 role最常被忽略的是“普通管理員不能凍結(jié)卡密、不能刪除日志”這類(lèi)垂直權(quán)限后臺(tái)菜單隱藏了入口但 API 端點(diǎn)還要再判斷一次。后臺(tái) Session 的 cookie 建議設(shè)置 HttpOnly、SameSiteLax避免被 XSS 拿走會(huì)話(huà)。如果做了前后端分離還需要為后臺(tái)接口單獨(dú)發(fā)一個(gè)短時(shí)效 Token不要直接用用戶(hù)密碼哈希做簽名。4.2 卡密管理批量生成、CSV 導(dǎo)入和導(dǎo)出后臺(tái)卡密管理頁(yè)面至少要支持按卡號(hào)/卡密/狀態(tài)搜索、批量生成、作廢、凍結(jié)、續(xù)期、導(dǎo)出 CSV。批量生成的界面要提供產(chǎn)品類(lèi)型下拉框、生成數(shù)量和有效天數(shù)提交后調(diào)用第 3 章的 batch_create_cards 函數(shù)。生成結(jié)果要以 CSV 文件下載文件內(nèi)容只有 card_key,card_code 兩列方便直接發(fā)給渠道方header(Content-Type: text/csv; charsetutf-8); header(Content-Disposition: attachment; filenamecards.csv); $out fopen(php://output, w); fputcsv($out, [card_key, card_code]); foreach ($cards as $card) { fputcsv($out, $card); } fclose($out);除了自己生成很多團(tuán)隊(duì)會(huì)從第三方卡商采購(gòu)卡密這時(shí)候后臺(tái)要支持 CSV 導(dǎo)入。導(dǎo)入文件的模板和導(dǎo)出保持一致列順序必須是 card_key,card_code,duration默認(rèn)時(shí)長(zhǎng)可以留空使用產(chǎn)品類(lèi)型默認(rèn)值。解析時(shí)要注意去重卡號(hào)重復(fù)的行跳過(guò)并記錄錯(cuò)誤行號(hào)整個(gè)文件導(dǎo)入完成后顯示成功和失敗統(tǒng)計(jì)。我一般建議先做 dry-run把預(yù)覽結(jié)果給管理員確認(rèn)后再真正寫(xiě)入避免導(dǎo)入一條格式錯(cuò)誤的記錄導(dǎo)致整批卡密作廢。4.3 日志統(tǒng)計(jì)與后臺(tái)審計(jì)后臺(tái)的“完善”很大程度體現(xiàn)在數(shù)據(jù)展示上。驗(yàn)證日志頁(yè)要能按時(shí)間范圍、結(jié)果碼、卡號(hào)、設(shè)備哈希篩選列表字段包括卡號(hào)、產(chǎn)品名、結(jié)果、IP、設(shè)備哈希、訪(fǎng)問(wèn)時(shí)間。統(tǒng)計(jì)頁(yè)常用兩個(gè) SQL一個(gè)是每日激活趨勢(shì)SELECT FROM_UNIXTIME(used_at, %Y-%m-%d) AS day, COUNT(*) AS active_count FROM card_keys WHERE status 1 GROUP BY day ORDER BY day DESC LIMIT 30;另一個(gè)是按產(chǎn)品分組的激活占比SELECT p.product_name, COUNT(c.id) AS total, SUM(CASE WHEN c.status 1 THEN 1 ELSE 0 END) AS used FROM card_keys c LEFT JOIN card_products p ON c.product_id p.id GROUP BY c.product_id;日志表會(huì)快速增長(zhǎng)后臺(tái)要提供自動(dòng)清理策略。常見(jiàn)做法是保留最近 90 天每天凌晨執(zhí)行 DELETE或者把超過(guò) 90 天的日志導(dǎo)入備份表。清理任務(wù)放在 cron 里寫(xiě)成 Shell 腳本調(diào)用 PHP 命令比較常見(jiàn)但注意不要用寶塔默認(rèn)的每分鐘執(zhí)行改成每天一次避免對(duì)主庫(kù)造成不必要的壓力。5. 卡密系統(tǒng)的高階技巧與排錯(cuò)最后這部分說(shuō)三個(gè)真正影響生產(chǎn)的問(wèn)題離線(xiàn)驗(yàn)證怎么設(shè)計(jì)、性能瓶頸怎么處理、接手老系統(tǒng)時(shí)從哪里開(kāi)始查。5.1 離線(xiàn)驗(yàn)證與在線(xiàn)驗(yàn)證的取舍在線(xiàn)驗(yàn)證要求客戶(hù)端每次啟動(dòng)都聯(lián)網(wǎng)卡密系統(tǒng)能實(shí)時(shí)凍結(jié)但對(duì)單機(jī)軟件不友好。常見(jiàn)做法是首次激活聯(lián)網(wǎng)之后保存一份服務(wù)端簽名的授權(quán)文件。服務(wù)端用 RSA 私鑰對(duì)卡密、到期時(shí)間、設(shè)備哈希簽名客戶(hù)端內(nèi)嵌公鑰驗(yàn)證。這樣即使不聯(lián)網(wǎng)也能判斷有效期。要注意授權(quán)文件里必須包含綁定設(shè)備哈希否則用戶(hù)把授權(quán)文件復(fù)制到另一臺(tái)機(jī)器也能通過(guò)驗(yàn)證。RSA 簽名不需要每次請(qǐng)求后臺(tái)所以對(duì) PHP 服務(wù)的壓力很小。5.2 性能優(yōu)化緩存、鎖與隊(duì)列驗(yàn)證接口如果被高頻調(diào)用數(shù)據(jù)庫(kù)行鎖會(huì)成為瓶頸?？軤顟B(tài)變化不頻繁可以在 Redis 里緩存 status 和 expires_at緩存過(guò)期時(shí)間設(shè)置 60 秒。但激活寫(xiě)路徑必須走數(shù)據(jù)庫(kù)不能跳過(guò) FOR UPDATE。如果日志寫(xiě)入影響主流程性能把 card_verify_logs 的插入放進(jìn) Redis 隊(duì)列由后臺(tái)腳本異步寫(xiě)庫(kù)查詢(xún)?nèi)罩緯r(shí)接受幾秒延遲這樣驗(yàn)證接口的耗時(shí)能控制在 20ms 以?xún)?nèi)。5.3 排錯(cuò)與代碼審計(jì)接手別人留下的卡密系統(tǒng)時(shí)第一件事不是看后臺(tái)界面而是做代碼審計(jì)。重點(diǎn)看三處驗(yàn)證接口有沒(méi)有在做狀態(tài)判斷前更新數(shù)據(jù)庫(kù)、是否用了事務(wù)和行鎖、錯(cuò)誤碼是否正確。常見(jiàn)坑是 PHP 7.0 升級(jí)后 mcrypt 相關(guān)的代碼報(bào)錯(cuò)之前用 mcrypt 加密設(shè)備號(hào)的方案要換成正向哈希。另一個(gè)高發(fā)問(wèn)題是時(shí)區(qū)PHP 的 date_default_timezone_set 和 MySQL 連接時(shí)區(qū)不一致會(huì)導(dǎo)致歸檔的卡密提前過(guò)期。后臺(tái)導(dǎo)出 CSV 時(shí)如果發(fā)現(xiàn)中文亂碼要在輸出前加入 UTF-8 BOM。日志表如果查詢(xún)緩慢先看有沒(méi)有 idx_card_time數(shù)據(jù)量千萬(wàn)級(jí)時(shí)按月份做分區(qū)表比加索引更有效。這些點(diǎn)查完卡密驗(yàn)證系統(tǒng)的正確性和后臺(tái)可用性基本就立住了。本文還有配套的精品資源點(diǎn)擊獲取