直接進(jìn)入到正題吧。收到這個(gè)標(biāo)題的時(shí)候,我先想到的是又一個(gè)商城項(xiàng)目。但仔細(xì)看關(guān)鍵詞——減肥減脂、輕食品,這個(gè)定位其實(shí)比普通電商網(wǎng)站有意思得多。它不是一個(gè)單純賣貨的商城,而是圍繞熱量管理這個(gè)核心需求來設(shè)計(jì)的。所以整個(gè)項(xiàng)目的數(shù)據(jù)庫(kù)設(shè)計(jì)、頁面交互、下單邏輯都要往這個(gè)方向靠,而不是套一個(gè)通用商城模板就完事。先說結(jié)論:ThinkPHP做后端接口、Vue做前端頁面,這套組合在國(guó)內(nèi)中小型電商項(xiàng)目里非常成熟,坑少、資料多、招人也好招。而且輕食品這種品類,商品屬性天然適合用Web站承載——圖片展示、營(yíng)養(yǎng)參數(shù)、熱量對(duì)比、套餐組合,這些信息在網(wǎng)頁端的表達(dá)效率遠(yuǎn)高于小程序和App。下面我把整個(gè)項(xiàng)目的設(shè)計(jì)與實(shí)現(xiàn)思路完整拆一遍,從架構(gòu)選型到數(shù)據(jù)庫(kù)字段,再到前后端關(guān)鍵代碼,最后是上線排坑,盡量讓你照著就能復(fù)現(xiàn)。1. 網(wǎng)站整體架構(gòu)與設(shè)計(jì)思路拆解1.1 為什么選ThinkPHPVue這對(duì)組合選技術(shù)棧之前,先問自己一個(gè)問題:這個(gè)項(xiàng)目到底要解決什么問題?減肥減脂輕食品網(wǎng)站,用戶的痛點(diǎn)非常明確——不知道怎么吃、懶得算熱量、怕買錯(cuò)高熱量食物。所以網(wǎng)站的核心不是炫酷交互,而是清晰展示熱量數(shù)據(jù)快速完成下單。ThinkPHP作為后端框架,優(yōu)勢(shì)在于:路由配置靈活,MVC結(jié)構(gòu)清晰,內(nèi)置ORM和驗(yàn)證器,非常適合業(yè)務(wù)邏輯偏重的電商項(xiàng)目。開發(fā)效率上,一個(gè)熟練的PHP開發(fā)者用ThinkPHP搭一套R(shí)ESTful接口,三個(gè)工作日基本能把商品、購(gòu)物車、訂單、用戶這四個(gè)核心模塊跑通。Vue這邊選Vue 2還是Vue 3?說實(shí)話,新項(xiàng)目直接上Vue 3是合理的,Composition API在管理購(gòu)物車狀態(tài)、用戶登錄狀態(tài)這種復(fù)雜交互時(shí),代碼組織比Options API清晰得多。但如果你團(tuán)隊(duì)更熟悉Vue 2的語法,用Vue 2也不是不能做,只是后續(xù)維護(hù)成本會(huì)高一些。我的建議是:新項(xiàng)目用Vue 3 Element Plus,組件庫(kù)成熟,表單校驗(yàn)、彈窗、表格這些電商后臺(tái)常用組件開箱即用。前后端分離架構(gòu)下,數(shù)據(jù)交互全靠JSON。ThinkPHP這邊只需要把每個(gè)接口寫好,返回統(tǒng)一格式的數(shù)據(jù)結(jié)構(gòu)。Vue這邊用Axios發(fā)起請(qǐng)求,拿到數(shù)據(jù)后驅(qū)動(dòng)頁面渲染。這套模式的好處是:前端開發(fā)和后端開發(fā)可以并行,萬一以后要加個(gè)小程序端,后端接口可以直接復(fù)用。1.2 項(xiàng)目目錄結(jié)構(gòu)與職責(zé)劃分我不太喜歡把什么都往controller里堆。這個(gè)項(xiàng)目我建議按模塊劃分目錄,結(jié)構(gòu)清晰了,后期維護(hù)不抓瞎。后端(thinkphp6)目錄結(jié)構(gòu)參考:app/controller/ —— 業(yè)務(wù)控制器,按模塊分文件(Index、Goods、Cart、Order、User)app/model/ —— 數(shù)據(jù)模型層(Goods、Cart、Order、OrderItem、User)app/validate/ —— 數(shù)據(jù)驗(yàn)證器(注冊(cè)驗(yàn)證、下單驗(yàn)證、地址驗(yàn)證)app/middleware/ —— 中間件(登錄鑒權(quán)、跨域處理)route/ —— 路由定義文件,統(tǒng)一管理API路徑public/uploads/ —— 商品圖片上傳目錄前端(vue3)目錄結(jié)構(gòu)參考:src/api/ —— 接口請(qǐng)求封裝,按業(yè)務(wù)拆分成goods.js、cart.js、order.js、user.jssrc/router/ —— 路由配置,含動(dòng)態(tài)路由邏輯src/store/ —— Pinia狀態(tài)管理,拆分user、cart、order三個(gè)storesrc/views/ —— 頁面組件,包括首頁、商品列表、商品詳情、購(gòu)物車、結(jié)算頁、訂單列表、用戶中心src/components/ —— 公共組件(商品卡片、篩選欄、分頁器、彈窗)后端按模塊拆分的好處,配合ThinkPHP的多應(yīng)用模式,可以做到一個(gè)project里同時(shí)承載Web前端接口和后臺(tái)管理接口。app/controller/admin下放后臺(tái)管理端的接口,app/controller/api下放C端小程序和Web端的接口,兩者互不干擾。Vue端路由這塊,如果只是為了做展示型商城,靜態(tài)路由就夠了。但如果項(xiàng)目規(guī)劃里有用戶身份差異的需求(比如普通用戶和營(yíng)養(yǎng)師),就得考慮動(dòng)態(tài)路由了。動(dòng)態(tài)路由的核心原理不復(fù)雜:登錄后拿到用戶角色,根據(jù)角色去匹配可訪問的路由表,用router.addRoute動(dòng)態(tài)添加。我實(shí)際開發(fā)中確實(shí)遇到過一個(gè)坑:刷新頁面時(shí)Pinia里的用戶信息會(huì)丟,導(dǎo)致動(dòng)態(tài)路由失效。解決方式是刷新前把用戶信息持久化到localStorage,路由守衛(wèi)里判斷store為空時(shí)先從本地拉取。2. 數(shù)據(jù)庫(kù)設(shè)計(jì)與核心模塊拆解2.1 輕食品商品表的字段設(shè)計(jì)輕食品不是普通商品,它的核心差異化信息是營(yíng)養(yǎng)成分。所以商品表不能只放title、price、image這些基礎(chǔ)字段,還得有熱量、蛋白質(zhì)、脂肪、碳水化物、膳食纖維這些營(yíng)養(yǎng)維度字段。我設(shè)計(jì)商品表(sn_goods)時(shí),核心字段如下:id: 主鍵,自增title: 商品名稱(比如即食雞胸肉 原味 100g)subtitle: 商品賣點(diǎn)短句(如高蛋白低脂肪,每100g僅含1.2g脂肪)category_id: 分類id(關(guān)聯(lián)分類表,分類維度可以是雞胸肉全麥面包代餐奶昔等)price: 售價(jià)(單位分,注意用整數(shù)存,避免浮點(diǎn)誤差)original_price: 劃線價(jià)(展示促銷用)calories: 熱量(大卡/100g)protein: 蛋白質(zhì)(g/100g)fat: 脂肪(g/100g)carbohydrate: 碳水(g/100g)fiber: 膳食纖維(g/100g)recommend_flag: 是否推薦(首頁推薦商品位用)sale_count: 銷量(展示用,也可以從訂單表實(shí)時(shí)統(tǒng)計(jì),但為了性能會(huì)冗余這個(gè)字段)stock: 庫(kù)存images: 商品圖(存多圖JSON格式)status: 上下架狀態(tài)(1上架 0下架)sort: 排序權(quán)重create_time / update_time: 時(shí)間字段price用分存儲(chǔ)是經(jīng)驗(yàn)之談,直接存float在結(jié)算時(shí)會(huì)出現(xiàn)0.10.2不等于0.3的精度問題。前端展示時(shí)再除以100轉(zhuǎn)成元,后端計(jì)算金額時(shí)全部用整數(shù)加減,這是一個(gè)比較穩(wěn)妥的做法。category_id關(guān)聯(lián)分類表,分類表建議做成二級(jí)結(jié)構(gòu),比如第一級(jí)是雞胸肉/牛肉類,第二級(jí)是原味/黑椒/奧爾良。但考慮到輕食品SKU不算多,二級(jí)分類就夠了,不用搞太深。2.2 購(gòu)物車與訂單的關(guān)聯(lián)設(shè)計(jì)購(gòu)物車表(sn_cart)設(shè)計(jì)要點(diǎn):iduser_id: 用戶idgoods_id: 商品idsku_id: SKU id(如果同一商品有不同的口味、規(guī)格,就需要SKU表。比如一袋即食雞胸肉有原味100g和黑椒100g兩個(gè)SKU,它們的營(yíng)養(yǎng)數(shù)據(jù)可能不同)goods_snapshot: 下單快照(JSON,存商品名稱、價(jià)格、圖片、熱量信息)。為什么存快照?因?yàn)樯唐穬r(jià)格和詳情是可能變動(dòng)的,下單后用戶查看歷史訂單時(shí),應(yīng)該看到的是下單那一刻的商品信息,而不是商家后來改過的數(shù)據(jù)num: 數(shù)量checked: 是否勾選(結(jié)算時(shí)只購(gòu)買勾選的商品)create_time / update_time訂單表(sn_order)設(shè)計(jì)要點(diǎn):order_no: 訂單號(hào)(唯一,用時(shí)間戳隨機(jī)數(shù)生成,避免沖突)user_idtotal_price: 總金額(分)pay_price: 實(shí)付金額(分,和total_price的差異是有無優(yōu)惠)total_calories: 總熱量(大卡)——這是輕食品訂單的獨(dú)有字段。用戶下單后能看到本單合計(jì)熱量1230大卡,這個(gè)場(chǎng)景在普通商城是沒有的status: 訂單狀態(tài)(0待支付 1已支付/待發(fā)貨 2已發(fā)貨 3已簽收 4已完成 5已取消)consignee: 收貨人姓名phone: 聯(lián)系電話address: 收貨地址pay_time: 支付時(shí)間ship_time: 發(fā)貨時(shí)間finish_time: 完成時(shí)間create_time子訂單表(sn_order_item):order_id: 關(guān)聯(lián)訂單主表goods_idgoods_snapshot: JSON快照price: 單價(jià)(分)num: 數(shù)量total_price: 小計(jì)calories: 該商品熱量(大卡/份)為什么訂單要拆主表和子表?一個(gè)訂單可能包含多件商品,如果只放一個(gè)商品快照字段,下單后查看詳情會(huì)很別扭。拆成子表后,訂單主表存總信息,子表存每個(gè)商品的明細(xì),查詢時(shí)一次JOIN就能拿到全部?jī)?nèi)容。而且業(yè)務(wù)如果要擴(kuò)展退款、售后,在子表維度操作也會(huì)更靈活。2.3 用戶熱量檔案與個(gè)性化推薦這是輕食品網(wǎng)站區(qū)別于普通商城的地方——用戶不是純隨機(jī)逛,而是帶著控制熱量的目標(biāo)來的。如果只做一個(gè)標(biāo)準(zhǔn)商品展示站,用戶來了看完就走,復(fù)購(gòu)率很難起來。熱量檔案表的設(shè)計(jì)思路:基本信息:身高、體重、年齡、性別、活動(dòng)強(qiáng)度這些基礎(chǔ)生理數(shù)據(jù)計(jì)算邏輯:BMR(基礎(chǔ)代謝率)用Mifflin-St Jeor公式。男性BMR 10×體重(kg) 6.25×身高(cm) - 5×年齡 5。女性是減161。再由BMR乘活動(dòng)系數(shù)得到每日總消耗TDEE日攝入目標(biāo):TDEE減300到500大卡,生成減脂期的每日熱量預(yù)算這份計(jì)算的代碼邏輯可以放在后端單獨(dú)的服務(wù)類里,就叫CalorieService,輸入用戶身體數(shù)據(jù),輸出每日建議攝入熱量。前端用戶中心頁面展示今日目標(biāo)熱量 / 已攝入熱量 / 剩余熱量,已攝入熱量從訂單記錄里算——用戶下單的食品總熱量,自動(dòng)累加到當(dāng)天攝入里。個(gè)性化推薦就更有意思了。我的處理方式:根據(jù)用戶的熱量缺口反推推薦商品。比如用戶今天還能吃340大卡,那在商品列表頁置頂推薦熱量在300大卡上下、蛋白質(zhì)含量高的商品,文案寫為你推薦:今天吃這個(gè)剛好。這個(gè)邏輯不用搞復(fù)雜算法,一個(gè)SQL查詢按abs(calories-剩余熱量)升序排列就能實(shí)現(xiàn),體感上用戶會(huì)覺得這個(gè)網(wǎng)站懂我。3. 后端接口開發(fā)與關(guān)鍵實(shí)現(xiàn)細(xì)節(jié)3.1 ThinkPHP路由定義與接口返回格式接口開發(fā)第一步是定義路由。一個(gè)商城類項(xiàng)目,路由建議全部采用RESTful風(fēng)格,用ThinkPHP的路由定義文件統(tǒng)一管理。一個(gè)簡(jiǎn)單的路由定義示例:// route/app.php use think\\facade\\Route; // 商品相關(guān) Route::get(api/goods, api.Goods/lists); Route::get(api/goods/:id, api.Goods/detail); Route::get(api/goods/search, api.Goods/search); // 購(gòu)物車相關(guān) Route::get(api/cart, api.Cart/index); Route::post(api/cart/add, api.Cart/add); Route::post(api/cart/update, api.Cart/update); Route::post(api/cart/delete, api.Cart/delete); Route::post(api/cart/check, api.Cart/check); // 訂單相關(guān) Route::post(api/order/submit, api.Order/submit); Route::get(api/order/list, api.Order/lists); Route::get(api/order/:order_no, api.Order/detail); Route::post(api/order/cancel, api.Order/cancel); // 用戶相關(guān) Route::post(api/user/register, api.User/register); Route::post(api/user/login, api.User/login); Route::get(api/user/info, api.User/info); Route::post(api/user/profile, api.User/profile);所有接口統(tǒng)一返回JSON格式,結(jié)構(gòu)盡量做成:{ code: 0, msg: success, data: {} }code非0時(shí)表示業(yè)務(wù)錯(cuò)誤,data里可以攜帶錯(cuò)誤詳情。Vue前端封裝一個(gè)統(tǒng)一的請(qǐng)求攔截器,在攔截器里統(tǒng)一處理code不為0的情況,并做用戶未登錄跳轉(zhuǎn)邏輯。這套格式一旦定下來,前后端對(duì)接效率會(huì)高很多。路由注意一個(gè)問題:ThinkPHP的pathinfo模式在nginx部署時(shí),需要在nginx配置里加一句try_files,將所有請(qǐng)求轉(zhuǎn)發(fā)到入口文件,否則路由會(huì)404。本地跑php think run沒問題,一上nginx就各種找不到路由,十有八九就是這里沒配好。3.2 商品搜索、篩選與排序的SQL優(yōu)化商品列表頁是流量最大、SQL壓力最大的地方。輕食品項(xiàng)目的篩選維度其實(shí)更精確:按分類、按熱量區(qū)間、按蛋白質(zhì)含量、按銷量排序、按價(jià)格排序。這個(gè)需求如果直接拼SQL,索引設(shè)計(jì)不好很容易慢查詢。我的建議是:篩選條件通過查詢參數(shù)組合,控制器接收參數(shù)后交給模型層處理。比如按熱量區(qū)間篩選:public function lists(Request $request) { $query Goods::where(status, 1); // 按分類篩選 if ($request-has(category_id) !empty($request-get(category_id))) { $query-where(category_id, $request-get(category_id)); } // 按熱量區(qū)間篩選:傳入calories_min和calories_max if ($request-has(calories_min)) { $query-where(calories, , intval($request-get(calories_min))); } if ($request-has(calories_max)) { $query-where(calories, , intval($request-get(calories_max))); } // 排序 $sort $request-get(sort, default); switch ($sort) { case sales: $query-order(sale_count, desc); break; case price_asc: $query-order(price, asc); break; case price_desc: $query-order(price, desc); break; case calories_asc: $query-order(calories, asc); break; default: $query-order(sort, desc)-order(sale_count, desc); } $list $query-paginate(20); return json([code 0, data $list]); }這里要注意一個(gè)細(xì)節(jié):排序字段和篩選字段要在聯(lián)合索引上有規(guī)劃。如果商品數(shù)據(jù)量上萬,建議在status、category_id、calories這組字段上建聯(lián)合索引,排序字段如果頻繁切換,可以單獨(dú)建索引,但POST不能濫用。前端體驗(yàn)上,篩選欄做成Tab切換形式,熱量區(qū)間用一個(gè)滑條組件,拖到哪個(gè)范圍就發(fā)起一次請(qǐng)求。這里防坑:滑條拖動(dòng)時(shí)間隙率高,需要做debounce防抖,否則一秒能發(fā)幾十個(gè)請(qǐng)求,后端壓力會(huì)突然頂上來。實(shí)際開發(fā)中我在utils里寫了一個(gè)簡(jiǎn)單的防抖函數(shù),每次拖動(dòng)停穩(wěn)300ms后才發(fā)請(qǐng)求,體驗(yàn)和性能都兼顧了。3.3 下單流程與庫(kù)存扣減的事務(wù)處理下單是電商項(xiàng)目的核心流程,也是并發(fā)問題出現(xiàn)最多的地方。用ThinkPHP寫下單接口,必須用事務(wù)來保證一致性。核心的場(chǎng)景是:秒殺或促銷期間,多個(gè)用戶同時(shí)購(gòu)買同一商品,庫(kù)存是有限的,必須保證不能超賣。過程拆解:開啟事務(wù)根據(jù)user_id查購(gòu)物車勾選的商品列表檢查每個(gè)商品的庫(kù)存,是否滿足購(gòu)買數(shù)量扣減庫(kù)存(用UPDATE ... SET stock stock - ? WHERE id ? AND stock ?這種原子操作)生成訂單主表和子表數(shù)據(jù)清空已購(gòu)買的購(gòu)物車記錄提交事務(wù)代碼層面,重點(diǎn)在第4步。如果直接讀stock然后在代碼里扣減再寫回,并發(fā)場(chǎng)景下會(huì)超賣。原子更新語句會(huì)把這一步變成數(shù)據(jù)庫(kù)層面的操作,讓它不可拆分。Db::transaction(function () use ($cartItems) { $orderData []; $totalPrice 0; $totalCalories 0; foreach ($cartItems as $item) { $goods Goods::find($item-goods_id); if ($goods-stock $item-num) { throw new \\Exception(商品[ . $goods-title . ]庫(kù)存不足); } // 原子扣減庫(kù)存 $affected Goods::where(id, $goods-id) -where(stock, , $item-num) -dec(stock, $item-num) -update(); if (!$affected) { throw new \\Exception(商品[ . $goods-title . ]庫(kù)存不足); } $totalPrice $goods-price * $item-num; $totalCalories $goods-calories * $item-num; } $order Order::create([ order_no generateOrderNo(), user_id auth()-id, total_price $totalPrice, pay_price $totalPrice, total_calories $totalCalories, status 0, consignee $request-consignee, phone $request-phone, address $request-address, ]); // 寫入子表、清空購(gòu)物車等 });注意,如果使用的事務(wù)閉包里有異常拋出,閉包外要捕獲并返回錯(cuò)誤信息。用戶在下單頁點(diǎn)了提交訂單之后,按鈕要置為loading狀態(tài),防止重復(fù)提交。后端還要做一個(gè)冪等校驗(yàn):短時(shí)間(比如5秒內(nèi))同一個(gè)用戶重復(fù)提交相同的訂單,直接返回已有的訂單號(hào)而不是新建訂單。這個(gè)小的細(xì)節(jié)能攔截掉一大半的重復(fù)支付問題。訂單號(hào)生成我用的方案是:date(YmdHis) 8位隨機(jī)數(shù)字 用戶ID尾號(hào),再做個(gè)唯一索引兜底。排序方便,而且不會(huì)暴露真實(shí)訂單數(shù)量。4. 前端Vue頁面開發(fā)與交互細(xì)節(jié)4.1 首頁商品流、分類篩選與搜索頁前端部分我用的Vue 3 Vite Pinia Element Plus這套組合。項(xiàng)目初始化這步其實(shí)很多人卡住過,Vite創(chuàng)建Vue項(xiàng)目命令直接打成:npm create vuelatest npm install npm install axios pinia element-plus npm run dev首頁第一屏是分類入口和搜索框,往下是推薦位和商品瀑布流。商品卡片組件我建議單獨(dú)封裝一個(gè)GoodsCard.vue,接收goods對(duì)象作為prop,卡片內(nèi)部展示商品圖片、標(biāo)題、熱量、價(jià)格和加入購(gòu)物車按鈕。組件化之后商品列表頁、首頁推薦位、收藏頁面都能復(fù)用同一個(gè)卡片組件。分類篩選用的是Element Plus的Menu或者Tab組件,點(diǎn)擊分類觸發(fā)路由切換。這里我做了緩存處理:切換分類時(shí),舊的商品列表數(shù)據(jù)先保留,新數(shù)據(jù)請(qǐng)求到了才替換掉,避免頁面閃一下空白。Vue的KeepAlive組件可以緩存列表頁的滾動(dòng)位置,體驗(yàn)提升很明顯。代價(jià)是內(nèi)存占用略高,但商品列表頁數(shù)據(jù)量不大,完全劃算。搜索頁在路由上定義為/search,通過query參數(shù)keyword和Vue組件建立連接。搜索接口除了匹配標(biāo)題,我建議把副標(biāo)題也匹配進(jìn)去。比如用戶搜高蛋白,副標(biāo)題是高蛋白低脂肪,也能被搜出來。后端可以直接用LIKE %keyword%拼接,商品量幾萬條以內(nèi)沒問題,業(yè)務(wù)簡(jiǎn)單就不過度設(shè)計(jì)搜索中間件了。4.2 購(gòu)物車與結(jié)算頁的狀態(tài)管理購(gòu)物車建議用Pinia管理,因?yàn)橘?gòu)物車數(shù)據(jù)在多個(gè)頁面共用——商品詳情頁點(diǎn)加入購(gòu)物車、首頁右下角懸浮購(gòu)物車角標(biāo)、購(gòu)物車頁增減數(shù)量,這些組件都需要讀取同一份數(shù)據(jù)。如果不用狀態(tài)管理,各組件自己維護(hù)一份LocalStorage的拷貝,同步邏輯會(huì)寫得很痛苦。購(gòu)物車store的核心結(jié)構(gòu):export const useCartStore defineStore(cart, { state: () ({ items: [], checkedItems: [], totalCount: 0, totalPrice: 0 }), actions: { async fetchCart() { const res await api.getCart() this.items res.data this.calcuTotal() }, async addToCart(goodsId, num) { await api.addCart(goodsId, num) this.fetchCart() }, toggleCheck(itemId) { // 更新勾選狀態(tài) }, calcuTotal() { const checked this.items.filter(i i.checked) this.totalCount checked.reduce((sum, i) sum i.num, 0) this.totalPrice checked.reduce((sum, i) sum i.num * i.price, 0) } } })結(jié)算頁要展示重量和熱量匯總這個(gè)輕食品特色的信息。從store的checkedItems里拿到所有勾選商品,用goods_snapshot中的calorie字段乘以數(shù)量累加,得出本次合計(jì)熱量,放在價(jià)格旁邊突出顯示。文案可以做成本單總計(jì)XXX大卡,占您每日推薦攝入量的XX%,這個(gè)比例數(shù)據(jù)需要從后端用戶熱量檔案接口拉取。地址選擇這塊,如果不想集成第三方地圖SDK,就做一個(gè)簡(jiǎn)單的省市區(qū)三級(jí)聯(lián)動(dòng)組件。Element Plus的Cascader級(jí)聯(lián)可以快速實(shí)現(xiàn),數(shù)據(jù)源從后端一個(gè)靜態(tài)JSON接口拉取。收貨人姓名、手機(jī)號(hào)、詳細(xì)地址,加上一個(gè)設(shè)為默認(rèn)地址的開關(guān)就可以了。移動(dòng)端適配時(shí)注意鍵盤彈出遮擋問題,給底部提交按鈕欄加一個(gè)safe-area-inset-bottom的padding。4.3 用戶中心與訂單狀態(tài)流轉(zhuǎn)用戶中心頁面主要包含:個(gè)人資料編輯、熱量檔案卡片、訂單列表Tab(全部/待支付/待發(fā)貨/待收貨/已完成)、地址管理、退出登錄。訂單列表頁的核心是狀態(tài)流轉(zhuǎn)。不同狀態(tài)下展示不同按鈕:待支付顯示去支付和取消訂單,待發(fā)貨顯示查看物流(這里可以對(duì)接快遞100之類的第三方物流查詢API),待收貨顯示確認(rèn)收貨,已完成顯示再次購(gòu)買(點(diǎn)擊后把商品重新加入購(gòu)物車)。確認(rèn)收貨這個(gè)操作有個(gè)小坑:接口要加一個(gè)用戶身份校驗(yàn),防止有人拿別人的訂單號(hào)去調(diào)這個(gè)接口。校驗(yàn)邏輯并不復(fù)雜,訂單詳情接口返回?cái)?shù)據(jù)前先判斷order.user_id是否等于當(dāng)前登錄用戶的id,不一致就返回?zé)o權(quán)訪問的錯(cuò)誤碼。前端路由守衛(wèi)配置上,未登錄用戶訪問購(gòu)物車、訂單、用戶中心,直接跳轉(zhuǎn)登錄頁。登錄頁用Element Plus的表單校驗(yàn),手機(jī)號(hào)格式、密碼長(zhǎng)度這些在提交前先攔一遍,減少無謂的接口請(qǐng)求。關(guān)于Token的保存方式,我直接放在localStorage里,請(qǐng)求攔截器統(tǒng)一帶上Authorization頭。后端ThinkPHP在中間件里解析Token。這里有個(gè)痛點(diǎn):如果Token過期,前端收到401后要做統(tǒng)一的登出跳轉(zhuǎn),不要在每個(gè)請(qǐng)求里分別處理。我在Axios的響應(yīng)攔截器統(tǒng)一判斷HTTP狀態(tài)碼,遇到401就清除本地用戶信息,跳轉(zhuǎn)到登錄頁并帶上redirect參數(shù),登錄成功后回到之前的頁面。5. 環(huán)境搭建、常見問題與性能優(yōu)化5.1 本地環(huán)境搭建與聯(lián)調(diào)配置ThinkPHP運(yùn)行環(huán)境最省事的是用PHPStudy或Laragon這類集成環(huán)境,一鍵裝好PHP 8.0和MySQL。然后用Composer創(chuàng)建項(xiàng)目:composer create-project topthink/think tpVue項(xiàng)目也用Vite初始化:npm create vuelatest。兩個(gè)項(xiàng)目分開目錄存放,后端跑在8000端口,前端跑在5173端口。跨域是前后端分離第一個(gè)遇到的問題,Vite的devServer可以配proxy代理,把/api的請(qǐng)求轉(zhuǎn)發(fā)到后端的8000端口:server: { proxy: { /api: { target: http://localhost:8000, changeOrigin: true } } }這樣開發(fā)時(shí)前端頁面和后端接口就在同一個(gè)域名下,不用理跨域。如果嫌寫后端接口慢,可以先用Mock方案模擬接口數(shù)據(jù)。Vite的插件vite-plugin-mock能把Mock文件掛在devServer上,前端先按Mock數(shù)據(jù)結(jié)構(gòu)開發(fā)頁面,后端接口寫完后把baseURL切回真實(shí)地址,頁面基本不需要大改。生產(chǎn)環(huán)境部署時(shí),前端npm run build打出來的靜態(tài)文件,可以放在Nginx里指向一個(gè)站點(diǎn)目錄。Nginx配置里把location /指向前端dist目錄,location /api/反向代理到后端PHP服務(wù)。要注意配置Nginx的try_files,不然前端路由如果用history模式,刷新子頁面會(huì)報(bào)404。解決方法是加try_files $uri $uri/ /index.html。5.2 項(xiàng)目開發(fā)中遇到的典型問題和解決方案我梳理幾個(gè)這個(gè)項(xiàng)目中容易踩的坑,每個(gè)都是真實(shí)遇到過:問題一:Vue項(xiàng)目npm install時(shí)卡住或報(bào)錯(cuò)。原因通常是Node版本和依賴版本不匹配,或者網(wǎng)絡(luò)問題。解決方案:優(yōu)先用nvm管理Node版本,Vue 3 Vite要求Node 16以上。npm install遇到報(bào)錯(cuò)先刪掉package-lock.json和node_modules,重新安裝。實(shí)在不行換用pnpm或cnpm源。問題二:Vue頁面渲染空白,控制臺(tái)報(bào)錯(cuò)TypeError: Cannot read properties of undefined。這個(gè)多半是接口返回的數(shù)據(jù)結(jié)構(gòu)里,某個(gè)嵌套字段不存在,頁面直接渲染了。解決方式:模板里用可選鏈或者v-if判斷,比如goods?.images?.[0] || defaultImg。我習(xí)慣在接口封裝層就做一層數(shù)據(jù)映射,把后端可能為空的字段兜底成默認(rèn)值,前端頁面就不需要到處判斷了。問題三:ThinkPHP接口返回中文亂碼。排查方向:數(shù)據(jù)庫(kù)連接配置的charset要設(shè)為utf8mb4,框架的默認(rèn)字符集設(shè)置和表的字符集保持一致。問題四:提交訂單時(shí)偶發(fā)超賣。這個(gè)基本就是沒有使用原子扣減導(dǎo)致的。上面代碼里已經(jīng)展示了解決方案,用where(stock, , $num)-dec(stock, $num)一步完成。還有一個(gè)殘留問題:事務(wù)里如果同時(shí)扣減多個(gè)商品,其中一個(gè)商品庫(kù)存不足拋異常后,事務(wù)整體回滾是正常的,但要注意拋出異常前不要再執(zhí)行其他寫操作,尤其不要在事務(wù)里調(diào)用支付接口,因?yàn)橹Ц督涌诔３Ｓ凶约旱幕卣{(diào)邏輯,容易和事務(wù)串臺(tái)。問題五:圖片不顯示。檢查后端上傳目錄的URL是否正確。ThinkPHP的本地路徑和訪問URL是兩回事,建議統(tǒng)一用公共函數(shù)生成圖片的完整URL,存庫(kù)時(shí)只存相對(duì)路徑,顯示時(shí)拼接host。5.3 性能優(yōu)化與后續(xù)功能擴(kuò)展商品圖片是流量大頭。Web端圖片建議統(tǒng)一用WebP格式,壓縮率高,首屏能快不少?？梢园褕D片處理服務(wù)用七牛云或阿里云OSS的圖片處理參數(shù)來實(shí)時(shí)轉(zhuǎn)換,沒上云的先用本地thumbnails目錄存壓縮圖。懶加載用Vue的v-lazy插件,商品列表滾動(dòng)時(shí)才加載圖片,首屏壓力會(huì)小很多。后端做一層緩存:商品列表接口的響應(yīng)數(shù)據(jù)緩存到Redis,鍵名用分類排序參數(shù)的md5值。商品庫(kù)存更新、上下架就主動(dòng)刪掉對(duì)應(yīng)緩存。這個(gè)方案在小項(xiàng)目中改動(dòng)不大,收益卻很直觀。熱點(diǎn)商品的訂單接口也可以緩存用戶ID對(duì)應(yīng)購(gòu)物車,減少數(shù)據(jù)庫(kù)查詢頻率。后續(xù)擴(kuò)展方向上提幾個(gè)想法:營(yíng)養(yǎng)檔案導(dǎo)出功能:將用戶一周內(nèi)的訂單熱量數(shù)據(jù)導(dǎo)出成圖表,動(dòng)態(tài)生成一個(gè)熱量曲線圖,前端用ECharts渲染。熱搜詞里vue中用echarts畫兩個(gè)柱狀統(tǒng)計(jì)圖說明這個(gè)需求真的很常見輕食品套餐組合:系統(tǒng)根據(jù)用戶日攝入目標(biāo),自動(dòng)推薦一份一日三餐輕食套餐,一鍵加購(gòu)定時(shí)提醒:用ThinkPHP的定時(shí)任務(wù),在用戶設(shè)定的用餐時(shí)間推送提醒通知這些擴(kuò)展聽起來很多,但架構(gòu)上把該拆的模塊拆好,后續(xù)按模塊加就是了。每一項(xiàng)的改動(dòng)邊界都很清晰,不會(huì)動(dòng)到核心下單鏈路。6. 上線前的自查清單最后分享一個(gè)上線自查清單,算是踩坑換來的:后端環(huán)境PHP版本和ThinkPHP要求一致,生產(chǎn)環(huán)境如果用nginx,路由兼容配置測(cè)試完整數(shù)據(jù)庫(kù)表字段的字符集統(tǒng)一使用utf8mb4前端構(gòu)建的dist文件中,靜態(tài)資源路徑用相對(duì)路徑還是絕對(duì)路徑,取決于部署方式,提前確認(rèn)登錄接口要加失敗次數(shù)限制,防止暴力破解下單接口的生產(chǎn)環(huán)境要加請(qǐng)求頻率限制,防止惡意刷單商品表圖片的完整域名要配置好,HTTP和HTTPS不要混用,混合內(nèi)容會(huì)導(dǎo)致瀏覽器攔截接口的異常處理要返回友好提示,不要直接把SQL錯(cuò)誤信息拋給用戶后臺(tái)管理端記得做權(quán)限控制,普通用戶和管理員的角色要分開我在搭建和調(diào)試過程中最大的體會(huì)是,電商項(xiàng)目的大部分問題都集中在并發(fā)和狀態(tài)一致性上,比如庫(kù)存、訂單狀態(tài)、支付回調(diào)。這塊的代碼寧可多寫幾層防御,也不要圖省事。而前端大部分問題集中在數(shù)據(jù)格式和狀態(tài)管理上,建議在接口封裝層就把數(shù)據(jù)結(jié)構(gòu)約定好,前后端各自省心不少。如果你正打算用ThinkPHP和Vue做類似的電商項(xiàng)目,希望這篇能幫你少踩幾個(gè)坑。當(dāng)然,每個(gè)人的業(yè)務(wù)場(chǎng)景不同,數(shù)據(jù)庫(kù)字段和接口設(shè)計(jì)還是要根據(jù)實(shí)際需求來調(diào)整。關(guān)鍵是把握住輕食品這個(gè)品類的特點(diǎn)——熱量數(shù)據(jù)貫穿始終,它不只是一個(gè)賣貨的商城,還是一個(gè)幫用戶管理飲食的工具。把這個(gè)核心價(jià)值做透了,項(xiàng)目就立住了。