簡介本資源是一套基于Vue.js開發(fā)的完整購物商城網(wǎng)站源碼面向前端初學(xué)者與中級(jí)開發(fā)者用于快速掌握Vue單頁應(yīng)用開發(fā)流程及電商類項(xiàng)目實(shí)戰(zhàn)結(jié)構(gòu)。資源涵蓋用戶登錄注冊、首頁展示、商品列表與詳情、購物車等核心模塊代碼獨(dú)立解耦、邏輯清晰可直接運(yùn)行預(yù)覽或按需復(fù)用組件。壓縮包共2000個(gè)文件主體為1596個(gè)JavaScript文件實(shí)現(xiàn)業(yè)務(wù)邏輯與Vue組件、190個(gè)Markdown文檔含說明與注釋、181個(gè)JSON配置文件如路由、商品數(shù)據(jù)模擬輔以少量HTML、CSS及XML文件整體大小27.59MB。目前已有26466人學(xué)習(xí)下載適合希望構(gòu)建真實(shí)感項(xiàng)目經(jīng)驗(yàn)、理解Vue路由管理、狀態(tài)處理與組件通信機(jī)制的學(xué)習(xí)者。 做前端這些年被問得最多的一類項(xiàng)目就是購物商城。不管是面試造輪子還是自己想接個(gè)私活練手“用Vue實(shí)現(xiàn)一個(gè)商城”幾乎是繞不開的坎。我自己從Vue 2一路做到Vue 3商城項(xiàng)目前前后后寫了不下五版從最早的jQuery版本到現(xiàn)在的組合式API踩過的坑能寫滿一本筆記本。這篇分享我就以“VUE實(shí)現(xiàn)購物商城網(wǎng)站源碼”為題把這幾年做商城項(xiàng)目的完整思路、技術(shù)選型、核心代碼和排查經(jīng)驗(yàn)一次性說清楚。內(nèi)容適合兩類人看一是剛把Vue基礎(chǔ)過完、想找個(gè)完整項(xiàng)目練手的前端新人二是有一定經(jīng)驗(yàn)、想把商城項(xiàng)目做得更規(guī)范的中級(jí)開發(fā)者。我會(huì)盡量把每一步“為什么這么做”也講明白而不是只丟一堆代碼讓你復(fù)制。1. 項(xiàng)目整體設(shè)計(jì)與技術(shù)選型思路1.1 為什么是 Vue 3 Vite 而不是 Vue 2 Webpack先聊項(xiàng)目底座。現(xiàn)在再開新商城項(xiàng)目我首選就是 Vue 3 Vite這個(gè)組合已經(jīng)成為當(dāng)前前端項(xiàng)目的事實(shí)標(biāo)準(zhǔn)。Vue 3 的 Composition API 讓邏輯復(fù)用變得干凈尤其是商城這種功能模塊分散、狀態(tài)共享頻繁的項(xiàng)目用setup語法寫起來比 Options API 舒服太多。Vite 的優(yōu)勢在開發(fā)體驗(yàn)上體現(xiàn)得非常直接——冷啟動(dòng)毫秒級(jí)熱更新幾乎無感。以前用 Webpack 跑一個(gè)中型商城項(xiàng)目冷啟動(dòng)要等十幾秒改一行代碼編譯兩三秒那種等待感非常折磨人。換到 Vite 之后啟動(dòng)項(xiàng)目基本就是秒開保存代碼瀏覽器立刻刷新整個(gè)開發(fā)節(jié)奏快了一倍不止。如果你手里是 Vue 2 的老商城項(xiàng)目我的建議是如果項(xiàng)目要長期維護(hù)盡早規(guī)劃升級(jí)如果是個(gè)人學(xué)習(xí)或新項(xiàng)目直接 Vue 3別再猶豫。Vue 3 的生態(tài)現(xiàn)在已經(jīng)非常成熟Element Plus、Vant 4、Pinia、Vue Router 4 全都跟上了不存在“生態(tài)不完善”的問題了。1.2 組件樹怎么拆從頁面到組件的層級(jí)設(shè)計(jì)商城項(xiàng)目的組件拆分核心原則就一句話頁面組件管路由業(yè)務(wù)組件管功能基礎(chǔ)組件管展示。這個(gè)原則我踩過幾次坑才悟出來的。早期寫商城我把所有東西塞進(jìn)一個(gè)巨型組件一個(gè)GoodsList.vue寫了上千行改一個(gè)篩選條件就要在 data、computed、methods 之間來回跳改完還要擔(dān)心影響其他功能。后來我按“頁面 → 業(yè)務(wù)組件 → 基礎(chǔ)組件”三層來拆結(jié)構(gòu)就清晰多了。以商城的核心頁面為例頁面層Home.vue、GoodsList.vue、GoodsDetail.vue、Cart.vue、OrderConfirm.vue、UserCenter.vue業(yè)務(wù)層SearchBar.vue、FilterPanel.vue、GoodsCard.vue、SkuSelector.vue、CartItem.vue、AddressPicker.vue基礎(chǔ)層BaseButton.vue、BaseInput.vue、BaseDialog.vue、BaseToast.vue、BaseEmpty.vue這樣的拆分邏輯是頁面組件只負(fù)責(zé)從路由拿參數(shù)、往業(yè)務(wù)組件傳數(shù)據(jù)、處理頁面級(jí)跳轉(zhuǎn)業(yè)務(wù)組件接收 props 和事件內(nèi)部管理自己的交互狀態(tài)基礎(chǔ)組件則完全不感知業(yè)務(wù)純粹做 UI 展示和交互反饋。好處是每個(gè)組件職責(zé)單一測試和排錯(cuò)都很方便后續(xù)加功能也不會(huì)牽一發(fā)動(dòng)全身。1.3 狀態(tài)管理購物車數(shù)據(jù)為什么不放在組件里購物車是商城項(xiàng)目里狀態(tài)管理最典型的場景。購物車?yán)锏臄?shù)據(jù)商品列表頁要用顯示加入狀態(tài)、詳情頁要用直接加購、購物車頁面要用增刪改查、訂單確認(rèn)頁也要用讀取結(jié)算商品如果這些數(shù)據(jù)各自存在組件里就會(huì)出現(xiàn)一個(gè)商品在兩個(gè)頁面狀態(tài)不一致的情況。我用的是 Pinia 來管全局共享數(shù)據(jù)。對比 VuexPinia 省掉了 mutation 這一層API 更簡潔TypeScript 支持更好而且 Vue 3 官方推薦就是它。購物車、用戶登錄態(tài)、收貨地址這三塊數(shù)據(jù)我全部放進(jìn) Pinia 的 store 里統(tǒng)一管理。選 Pinia 還有一個(gè)原因devtools 的調(diào)試體驗(yàn)非常好。商城這種狀態(tài)修改頻繁的項(xiàng)目用 devtools 的時(shí)間旅行功能回溯狀態(tài)變化排查 bug 的效率能提高不少。后面我會(huì)詳細(xì)展示購物車 store 的完整寫法。2. 核心功能模塊的細(xì)節(jié)實(shí)現(xiàn)2.1 商品列表篩選、排序、分頁的三種狀態(tài)商品列表頁是商城的第一張臉功能上無非就是搜索、分類篩選、排序、分頁但實(shí)現(xiàn)起來有幾個(gè)關(guān)鍵決策點(diǎn)。第一點(diǎn)是篩選條件的組織。我把篩選條件分成兩類受控于URL的和組件內(nèi)部自管理的。分類ID、關(guān)鍵詞、排序方式、頁碼這些條件必須同步到 URL 的 query 上因?yàn)橛脩羲⑿马撁嬷笮枰３趾Y選狀態(tài)而且分享鏈接給別人的時(shí)候?qū)Ψ酱蜷_看到的應(yīng)該是一模一樣的列表。做法是用vue-router的router.push更新 query頁面再通過route.query初始化篩選條件。第二點(diǎn)是排序的實(shí)現(xiàn)。商城的排序一般有綜合、銷量、價(jià)格升序、價(jià)格降序、新品前端拿到排序條件后要么傳給后端做排序要么前端本地排序。我的做法是優(yōu)先傳給后端因?yàn)檎鎸?shí)商城的數(shù)據(jù)量是十萬級(jí)以上的前端排序只適合 mock 數(shù)據(jù)的小項(xiàng)目。如果你做的是純前端 demo那就在computed里用sort方法處理。script setup import { ref, computed, watch } from vue import { useRoute, useRouter } from vue-router const route useRoute() const router useRouter() const goodsList ref([]) const categoryId ref(route.query.categoryId || ) const keyword ref(route.query.keyword || ) const sortBy ref(route.query.sortBy || default) const page ref(Number(route.query.page) || 1) const pageSize 12 function updateQuery(params) { router.push({ query: { ...route.query, ...params } }) } function handleFilterChange() { page.value 1 updateQuery({ categoryId: categoryId.value, keyword: keyword.value, sortBy: sortBy.value, page: 1 }) fetchList() } const sortedList computed(() { let list [...goodsList.value] if (sortBy.value price_asc) list.sort((a, b) a.price - b.price) if (sortBy.value price_desc) list.sort((a, b) b.price - a.price) if (sortBy.value sales) list.sort((a, b) b.sales - a.sales) return list }) async function fetchList() { // 請求后端接口傳 categoryId / keyword / sortBy / page / pageSize const { data } await api.getGoodsList({ categoryId: categoryId.value, keyword: keyword.value, sortBy: sortBy.value, page: page.value, pageSize }) goodsList.value data.list } /script第三點(diǎn)是分頁。我做商城分頁一直遵循一個(gè)原則分頁器永遠(yuǎn)不要自己手寫組件直接用 Element Plus 的el-pagination或者自己封裝一層因?yàn)榉猪撈鞯倪吔缜闆r太多了——總頁數(shù)計(jì)算、頁碼超出范圍、數(shù)據(jù)為空、快速點(diǎn)擊連發(fā)請求手寫很容易漏。我自己封裝了一個(gè)BasePagination內(nèi)部包了el-pagination外面只暴露page和pageSize兩個(gè) v-model內(nèi)部自動(dòng)處理跳頁和重置。2.2 商品詳情SKU 選擇和規(guī)格聯(lián)動(dòng)商品詳情頁是商城交互復(fù)雜度最高的地方核心難點(diǎn)就在 SKU庫存量單位選擇。SKU 選擇器的本質(zhì)是多個(gè)規(guī)格維度顏色、尺寸、版本互相約束選中某個(gè)規(guī)格后其他規(guī)格的可選項(xiàng)要根據(jù)庫存情況動(dòng)態(tài)禁用或恢復(fù)。我的實(shí)現(xiàn)邏輯是先把規(guī)格數(shù)據(jù)拆成兩級(jí)規(guī)格選項(xiàng)樹和SKU組合列表。規(guī)格選項(xiàng)樹用于渲染前端選擇面板SKU組合列表用于判斷某個(gè)選項(xiàng)是否可點(diǎn)。判斷某個(gè)選項(xiàng)是否能選要看“選了它之后是否存在一個(gè) SKU 組合包含當(dāng)前所有已選規(guī)格包括這個(gè)選項(xiàng)”如果存在就可選否則置灰。script setup import { ref, computed } from vue const props defineProps({ product: { type: Object, required: true } }) const selectedSpecs ref({}) const skuList props.product.skuList const specTree computed(() { const result [] for (const group of props.product.specGroups) { const options group.options.map(opt { const canSelect skuList.some(sku { const skuSpecs sku.specs // 當(dāng)前組選中該選項(xiàng)后與已選的其他組規(guī)格組合看是否存在有效 SKU const temp { ...selectedSpecs.value, [group.id]: opt.id } return Object.entries(temp).every(([key, val]) skuSpecs[key] val) }) return { ...opt, disabled: !canSelect } }) result.push({ ...group, options }) } return result }) function handleSelectSpec(groupId, optionId) { if (!optionId) { delete selectedSpecs.value[groupId] } else { selectedSpecs.value[groupId] optionId } } /script這個(gè)方案的核心思路在面試?yán)镆步?jīng)常被問到叫做“根據(jù)當(dāng)前已選規(guī)格反查可達(dá)性”理解了這層邏輯SKU 聯(lián)動(dòng)就不是難題。另外一個(gè)細(xì)節(jié)是選中所有規(guī)格后要立刻展示對應(yīng)的 SKU 信息價(jià)格、庫存、商品編號(hào)這里用computed去匹配當(dāng)前selectedSpecs對應(yīng)的 sku 對象。還有一個(gè)體驗(yàn)點(diǎn)我后來才補(bǔ)上用戶沒有選完規(guī)格就點(diǎn)“加入購物車”應(yīng)該彈提示而不是靜默失敗。這個(gè)小交互看似簡單但直接影響用戶對商品頁面的信任感。2.3 購物車computed 驅(qū)動(dòng)金額計(jì)算購物車頁面的邏輯核心是“選擇狀態(tài)”和“金額計(jì)算”。先說金額計(jì)算這里必須用 Vue 的computed因?yàn)橘徫镘嚨慕痤~不是一個(gè)確定值——勾選哪個(gè)商品、改了多少數(shù)量、有沒有優(yōu)惠券、有沒有滿減都會(huì)影響最終結(jié)果。把這些因子全部做成響應(yīng)式依賴computed會(huì)自動(dòng)追蹤并重新計(jì)算。購物車?yán)镂揖S護(hù)了三個(gè)核心狀態(tài)cartList購物車商品列表每項(xiàng)包括checked、count、skuInfo、isAllChecked全選狀態(tài)、totalPrice合計(jì)金額。// stores/cart.js import { defineStore } from pinia import { ref, computed } from vue export const useCartStore defineStore(cart, () { const cartList ref([]) const checkedList computed(() cartList.value.filter(item item.checked)) const totalCount computed(() checkedList.value.reduce((sum, item) sum item.count, 0)) const totalPrice computed(() checkedList.value.reduce((sum, item) sum item.price * item.count, 0) ) const isAllChecked computed(() cartList.value.length 0 cartList.value.every(item item.checked) ) function toggleAll(checked) { cartList.value.forEach(item { item.checked checked }) } function updateCount(id, count) { const item cartList.value.find(i i.id id) if (item) item.count Math.max(1, count) } function removeItem(id) { cartList.value cartList.value.filter(i i.id ! id) } return { cartList, checkedList, totalCount, totalPrice, isAllChecked, toggleAll, updateCount, removeItem } })computed的一個(gè)隱藏優(yōu)勢是性能優(yōu)化。如果沒有 computed每次界面刷新都要重新遍歷購物車數(shù)組有了 computed只有當(dāng)cartList或checked狀態(tài)真正變化時(shí)才會(huì)重新計(jì)算Vue 的響應(yīng)式系統(tǒng)保證了這個(gè)過程的精確性。這在購物車商品數(shù)量上百時(shí)差距非常明顯。另一個(gè)容易踩坑的是item.checked直接放在ref數(shù)組的對象屬性上修改item.count時(shí)需要用item.count newValue而不是重新賦值整個(gè)對象否則響應(yīng)式會(huì)丟失。用ref 對象屬性修改時(shí)Vue 3 會(huì)按需處理但為了保險(xiǎn)起見更新購物車條目時(shí)最好保持對象引用不變。2.4 訂單流程與用戶登錄路由守衛(wèi)和 token 管理商城的訂單流程通常涉及“加入購物車 → 確認(rèn)訂單 → 填寫地址 → 提交訂單 → 支付 → 查看訂單”這幾個(gè)頁面之間靠路由跳轉(zhuǎn)銜接。這里有兩個(gè)關(guān)鍵技術(shù)點(diǎn)路由守衛(wèi)和登錄狀態(tài)管理。我的做法是在路由配置里給需要登錄的頁面加meta: { requiresAuth: true }然后在全局前置守衛(wèi)里檢查用戶 token 是否存在。如果用戶未登錄且訪問了需要登錄的頁面就重定向到登錄頁并帶上redirect參數(shù)登錄成功后自動(dòng)跳回原頁面。// router/index.js router.beforeEach((to, from, next) { const token localStorage.getItem(token) if (to.meta.requiresAuth !token) { next({ path: /login, query: { redirect: to.fullPath } }) } else { next() } })登錄模塊本身的實(shí)現(xiàn)邏輯是用戶提交賬號(hào)密碼 → 后端返回 token → 前端把 token 存到 localStorage 和 Pinia 的用戶 store → 根據(jù)redirect參數(shù)跳轉(zhuǎn)。這里有一個(gè)容易被忽略的點(diǎn)token 過期處理。如果后端返回 401前端要統(tǒng)一攔截清理本地 token跳轉(zhuǎn)到登錄頁。我在 axios 的響應(yīng)攔截器里統(tǒng)一處理這件事情而不是每個(gè)頁面單獨(dú)判斷。接私活和面試的時(shí)候很多朋友問我“token 存 localStorage 安全嗎”。坦白講XSS 風(fēng)險(xiǎn)是存在的但商城項(xiàng)目如果只是 demo 或中小型項(xiàng)目localStorage 請求攔截器的方案是業(yè)界的常見妥協(xié)。更安全的方案是放到 httpOnly cookie 里但那就涉及前后端聯(lián)調(diào) CSRF 防護(hù)成本高不少。做項(xiàng)目要根據(jù)實(shí)際體量做取舍這個(gè)我會(huì)在后面問題排查里再展開。3. 實(shí)操過程從零搭一個(gè) Vue 商城3.1 環(huán)境準(zhǔn)備與腳手架初始化開始之前先把環(huán)境準(zhǔn)備好。Node.js 版本建議 18 以上因?yàn)?Vite 5 要求 Node 18老版本裝依賴會(huì)直接報(bào)錯(cuò)。用node -v確認(rèn)版本不夠就去官網(wǎng)重新裝一個(gè)。初始化項(xiàng)目我用 Vite 官方腳手架npm create vitelatest vue-shop -- --template vue cd vue-shop npm install npm run dev這里注意一個(gè)細(xì)節(jié)Vite 創(chuàng)建項(xiàng)目的時(shí)候雖然也能選 TypeScript但我自己更建議用 JavaScript 起步尤其是第一次做商城項(xiàng)目。TS 的類型約束在大型項(xiàng)目里是省力器但對新手來說類型報(bào)錯(cuò)會(huì)打斷學(xué)習(xí)和開發(fā)的節(jié)奏。我的習(xí)慣是個(gè)人練手用 JS 先把功能跑通接到正規(guī)項(xiàng)目或者團(tuán)隊(duì)協(xié)作再切 TS。裝完基礎(chǔ)依賴后繼續(xù)安裝核心庫npm install vue-router4 pinia axios element-plusElement Plus 是按需引入還是全量引入我的建議是開發(fā)階段先全量引入app.use(ElementPlus)一行搞定功能全部可用不用考慮組件樣式加載問題。等項(xiàng)目跑通、后面要優(yōu)化首屏速度了再換成unplugin-vue-components做按需引入。不要一上來就配置按需引入坑多且收益在開發(fā)階段看不見。3.2 目錄結(jié)構(gòu)與核心依賴規(guī)劃項(xiàng)目創(chuàng)建完我習(xí)慣先規(guī)劃目錄結(jié)構(gòu)否則寫幾天之后組件、store、工具函數(shù)混在一起找文件找到懷疑人生。我常用的商城項(xiàng)目目錄是這樣的src/ ├── api/ # 接口請求模塊 │ ├── goods.js │ ├── cart.js │ ├── user.js │ └── order.js ├── assets/ # 靜態(tài)資源 ├── components/ # 通用組件 │ ├── base/ # 基礎(chǔ)組件按鈕、輸入框、彈窗 │ └── business/ # 業(yè)務(wù)組件商品卡片、SKU選擇器、購物車條目 ├── router/ # 路由配置 │ └── index.js ├── stores/ # Pinia store │ ├── cart.js │ ├── user.js │ └── order.js ├── utils/ # 工具函數(shù)格式化、存儲(chǔ)、驗(yàn)證 ├── views/ # 頁面組件 │ ├── Home.vue │ ├── GoodsList.vue │ ├── GoodsDetail.vue │ ├── Cart.vue │ ├── Login.vue │ ├── Order.vue │ └── UserCenter.vue ├── App.vue └── main.js這個(gè)目錄結(jié)構(gòu)也是在很多中型 Vue 項(xiàng)目里驗(yàn)證過的組織方式。核心邏輯是api 負(fù)責(zé)所有網(wǎng)絡(luò)請求組件不直接調(diào)用 axiosstores 管理全局狀態(tài)組件通過 store 讀寫數(shù)據(jù)views 只做組裝不寫復(fù)雜業(yè)務(wù)邏輯。遵守這個(gè)約定之后你改接口返回結(jié)構(gòu)的時(shí)候只需要?jiǎng)?api 目錄界面和狀態(tài)完全不用碰。3.3 封裝請求層與接口約定axios 封裝是我做商城項(xiàng)目最先做的事因?yàn)楹竺嫠许撁娑家盟?。封裝的核心是統(tǒng)一 baseURL、統(tǒng)一超時(shí)時(shí)間、統(tǒng)一處理 token、統(tǒng)一錯(cuò)誤提示。// utils/request.js import axios from axios import { ElMessage } from element-plus import router from /router const request axios.create({ baseURL: /api, timeout: 10000 }) // 請求攔截器自動(dòng)攜帶 token request.interceptors.request.use(config { const token localStorage.getItem(token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 響應(yīng)攔截器統(tǒng)一處理業(yè)務(wù)碼和 401 request.interceptors.response.use( response { const res response.data if (res.code ! 200) { ElMessage.error(res.message || 請求失敗) return Promise.reject(new Error(res.message)) } return res }, error { if (error.response?.status 401) { localStorage.removeItem(token) router.push({ path: /login, query: { redirect: router.currentRoute.value.fullPath } }) ElMessage.error(登錄已過期請重新登錄) } else { ElMessage.error(error.message || 網(wǎng)絡(luò)異常) } return Promise.reject(error) } ) export default request接口文件示例// api/goods.js import request from /utils/request export function fetchGoodsList(params) { return request.get(/goods/list, { params }) } export function fetchGoodsDetail(id) { return request.get(/goods/detail/${id}) } export function addToCart(data) { return request.post(/cart/add, data) }這里我用的是/api前綴 Vite 代理的方式解決開發(fā)環(huán)境跨域。生產(chǎn)環(huán)境則由 nginx 統(tǒng)一轉(zhuǎn)發(fā)/api到后端服務(wù)前端代碼不用改。這個(gè)方案是前后端分離項(xiàng)目里最成熟的實(shí)踐避免了 CORS 配置的麻煩也讓接口路徑在環(huán)境切換時(shí)保持穩(wěn)定。3.4 購物車核心代碼實(shí)例購物車頁面是整站功能密度最高的地方我把核心交互代碼完整貼出來并逐段解釋。template div classcart-page div v-foritem in cartStore.cartList :keyitem.id classcart-item el-checkbox v-modelitem.checked / img :srcitem.image classitem-image / div classitem-info p classitem-name{{ item.name }}/p p classitem-sku{{ item.skuText }}/p /div div classitem-price￥{{ item.price }}/div el-input-number v-modelitem.count :min1 :maxitem.stock changehandleCountChange(item) / el-button typedanger link clickhandleRemove(item.id)刪除/el-button /div div classcart-footer el-checkbox :model-valuecartStore.isAllChecked changecartStore.toggleAll 全選 /el-checkbox div classtotal 已選 span classcount{{ cartStore.totalCount }}/span 件 合計(jì)span classtotal-price￥{{ cartStore.totalPrice }}/span /div el-button typedanger :disabled!cartStore.totalCount clickgoCheckout 去結(jié)算 /el-button /div /div /template script setup import { useRouter } from vue-router import { useCartStore } from /stores/cart import { updateCartCount, removeCartItem } from /api/cart import { ElMessage } from element-plus const router useRouter() const cartStore useCartStore() async function handleCountChange(item) { try { await updateCartCount(item.id, item.count) } catch (e) { ElMessage.error(更新數(shù)量失敗) } } async function handleRemove(id) { await removeCartItem(id) cartStore.removeItem(id) } function goCheckout() { router.push(/order/confirm) } /script這里面有幾個(gè)實(shí)現(xiàn)細(xì)節(jié)值得注意。第一個(gè)是el-checkbox v-modelitem.checked如果item.checked在初始數(shù)據(jù)里不存在v-model會(huì)幫我們自動(dòng)補(bǔ)上這個(gè)屬性但有個(gè)隱含問題新增購物車商品時(shí)如果后端返回的數(shù)據(jù)里沒有checked字段需要先給每個(gè) item 補(bǔ)上checked: false。我在 store 里從接口拉數(shù)據(jù)的時(shí)候會(huì)用map統(tǒng)一處理function setCartList(list) { cartList.value list.map(item ({ ...item, checked: item.checked ?? false })) }第二個(gè)是el-input-number的change它的觸發(fā)時(shí)機(jī)是在輸入框失焦或者點(diǎn)擊加減按鈕之后不會(huì)在輸入過程中反復(fù)觸達(dá)后端。這個(gè)控件的另一個(gè)特性是如果手動(dòng)輸入了一個(gè)超范圍的值它會(huì)先自動(dòng)鉗制到min或max范圍再觸發(fā) change 事件所以不需要在事件里再判斷一次邊界。最后是金額計(jì)算的精度問題。商城涉及價(jià)格計(jì)算直接浮點(diǎn)運(yùn)算會(huì)出現(xiàn)0.1 0.2 0.30000000000000004這種經(jīng)典問題。我的處理是后端返回的價(jià)格用“分”為單位存儲(chǔ)整數(shù)前端展示時(shí)再除以 100 保留兩位小數(shù)前端計(jì)算金額時(shí)全部用分做整數(shù)運(yùn)算最后展示時(shí)再格式化。這個(gè)約定一定要前后端一起定好否則接口一對接全是金額對不上的 bug。4. 常見問題與排查技巧實(shí)錄4.1 依賴安裝和 node_modules 相關(guān)的坑先聊一個(gè)很多新手會(huì)卡住的報(bào)錯(cuò)The project can not found node_modules或者提示You can: 1. use npm install -g vue/cli。這兩種報(bào)錯(cuò)本質(zhì)都是一個(gè)原因——項(xiàng)目依賴沒裝完整或者裝的時(shí)候被中斷了。解決方式分三步走第一步確認(rèn)項(xiàng)目根目錄下有package.json在項(xiàng)目根目錄執(zhí)行npm install等待安裝完成。如果安裝過程中出現(xiàn)紅色報(bào)錯(cuò)優(yōu)先看錯(cuò)誤信息里有沒有EACCES權(quán)限相關(guān)字樣有的話在 Linux/Mac 上執(zhí)行sudo npm installWindows 上用管理員身份打開終端。第二步如果npm install反復(fù)失敗先刪掉node_modules和package-lock.json然后重新安裝。有時(shí)候是鎖文件損壞導(dǎo)致的這種情況下npm cache clean --force清理緩存后再裝成功率會(huì)高很多。第三步項(xiàng)目能跑起來之后如果npm run dev報(bào)端口沖突Vite 默認(rèn)端口是 5173被占用時(shí)會(huì)在終端提示Port 5173 is in use按提示輸入y自動(dòng)換一個(gè)端口就行不用手動(dòng)改配置。這個(gè)問題的本質(zhì)是Vite 腳手架創(chuàng)建項(xiàng)目時(shí)不會(huì)自動(dòng)安裝依賴npm create vite只是生成了目錄和配置文件后續(xù)要靠npm install把package.json里記錄的依賴全部拉下來。所以“創(chuàng)建項(xiàng)目后先裝依賴”這個(gè)步驟千萬別跳。4.2 跨域問題前端代理的正確姿勢前后端分離的商城項(xiàng)目前端跑在localhost:5173后端跑在localhost:8080前端直接請求后端接口會(huì)觸發(fā)瀏覽器的同源策略限制也就是常見的 CORS 報(bào)錯(cuò)。很多初學(xué)者一看到跨域報(bào)錯(cuò)就去后端加 CORS 配置加了一堆CrossOrigin注解能通但很亂。我建議的開發(fā)姿勢是開發(fā)環(huán)境用 Vite 代理生產(chǎn)環(huán)境用 nginx 代理。前端代碼里只寫相對路徑/api/xxx具體請求打到哪由代理層決定。// vite.config.js export default defineConfig({ plugins: [vue()], server: { proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })這里changeOrigin: true必須加否則后端收到請求的Host頭還是前端地址有些后端框架會(huì)基于Host做校驗(yàn)導(dǎo)致請求失敗。rewrite是因?yàn)槲仪岸私y(tǒng)一加了/api前綴而后端接口路徑本身沒有/api所以代理時(shí)要把前綴剝掉。如果把開發(fā)環(huán)境代理配置好了還是報(bào)跨域排查順序是先看瀏覽器 Network 面板的請求是不是走通了看請求頭里的Origin和后端返回的響應(yīng)頭里有沒有Access-Control-Allow-Origin大概率是代理沒生效而不是代碼問題。4.3 keep-alive 和列表狀態(tài)恢復(fù)商城商品列表頁有個(gè)高頻交互需求用戶瀏覽商品列表往下翻了好幾頁點(diǎn)進(jìn)某個(gè)商品詳情然后點(diǎn)返回期望回到之前瀏覽的位置而不是回到列表頂部重新加載。這個(gè)需求我一開始用keep-alive包住列表頁組件確實(shí)能緩存組件狀態(tài)。但后來發(fā)現(xiàn)配合el-table時(shí)有個(gè)問題切換路由回來表格雖然還在但滾動(dòng)位置經(jīng)常被重置到頂部。這個(gè)現(xiàn)象在熱詞里也出現(xiàn)了——keep-alive 切換路由子組件 el-table 滾回頭部。原因在于keep-alive緩存的是組件的data和狀態(tài)但el-table的滾動(dòng)位置是 DOM 的原生屬性keep-alive激活組件時(shí)會(huì)重新渲染 DOM導(dǎo)致滾動(dòng)位置丟失。解決思路一般是在組件deactivated生命周期里記錄當(dāng)前滾動(dòng)位置在activated生命周期里恢復(fù)滾動(dòng)位置。import { onActivated, onDeactivated } from vue const scrollTop ref(0) onDeactivated(() { scrollTop.value document.querySelector(.el-table__body-wrapper)?.scrollTop || 0 }) onActivated(() { nextTick(() { document.querySelector(.el-table__body-wrapper)?.scrollTo({ top: scrollTop.value }) }) })這里要知道onActivated里恢復(fù)滾動(dòng)位置要在nextTick之后執(zhí)行因?yàn)榻M件剛被激活時(shí) DOM 還沒完全更新直接設(shè)置滾動(dòng)位置會(huì)不生效。還有一種更省事的方案不用keep-alive改用把列表查詢條件同步到 URL query 的方案返回時(shí)從 URL 讀取條件重新查詢。這種方式代碼簡單、共享方便適合列表參數(shù)不多的情況。4.4 Vue 3 升級(jí)帶來的老坑如果你是從 Vue 2 的項(xiàng)目遷移過來有幾個(gè)變化必須了解。第一個(gè)是Vue.prototype.$xxx的全局屬性方式?jīng)]了Vue 3 用app.config.globalProperties.xxx替代。很多老項(xiàng)目里封裝的this.$http、this.$utils遷移后全部會(huì)變成undefined排查起來容易懵。第二個(gè)是filter過濾器被移除了。Vue 3 里不能再用{{ price | formatPrice }}這種寫法必須改用 computed 或者函數(shù)調(diào)用。我遷移的時(shí)候是把所有過濾器統(tǒng)一改成工具函數(shù)在 setup 里導(dǎo)入使用比如formatPrice(price.value)。第三個(gè)是v-model的用法有變化。v-model在自定義組件上默認(rèn)是modelValueupdate:modelValueVue 2 里的.sync修飾符也被 v-model 的參數(shù)形式替代了。如果你從網(wǎng)上復(fù)制老代碼看到:visible.sync這種寫法要改成v-model:visible。第四個(gè)坑是Vue is not defined。這個(gè)報(bào)錯(cuò)除了少引入vue更常見的原因是代碼里有new Vue()這種 Vue 2 寫法Vue 3 里要改成createApp(App).mount(#app)。關(guān)于 Vue 3 的調(diào)試我強(qiáng)烈建議裝 Vue Devtools 插件。它可以看到組件樹、Pinia store 的變化、路由跳轉(zhuǎn)記錄排查響應(yīng)式數(shù)據(jù)問題非常管用。很多狀態(tài)“明明改了卻不更新”的詭異問題打開 devtools 看一遍響應(yīng)式依賴關(guān)系基本能定位到是不是在ref包裹的數(shù)組里直接通過下標(biāo)修改了數(shù)據(jù)。5. 性能優(yōu)化與上線部署的實(shí)戰(zhàn)經(jīng)驗(yàn)商城項(xiàng)目做完功能不叫完事性能優(yōu)化和上線部署才是真正考驗(yàn)工程能力的地方。我這里挑三個(gè)優(yōu)先級(jí)最高的優(yōu)化點(diǎn)講這三點(diǎn)做完首屏加載速度能有肉眼可見的提升。第一個(gè)是路由懶加載。用import函數(shù)動(dòng)態(tài)導(dǎo)入組件讓首屏只加載當(dāng)前頁面需要的代碼其他頁面的代碼在路由跳轉(zhuǎn)時(shí)才按需加載。const routes [ { path: /, component: () import(/views/Home.vue) }, { path: /goods/:id, component: () import(/views/GoodsDetail.vue) }, { path: /cart, component: () import(/views/Cart.vue) } ]這個(gè)做法的效果非常直接首頁不再需要加載購物車、訂單、用戶中心這些頁面的全部代碼JS 體積能減掉 30% 到 50%。構(gòu)建產(chǎn)物里會(huì)按路由拆出獨(dú)立的 chunk 文件用戶訪問哪個(gè)頁面就加載哪個(gè)頁面的代碼。第二個(gè)是圖片懶加載。商城列表頁的圖片數(shù)量動(dòng)輒幾十上百張全部一次性加載會(huì)拖慢頁面渲染。Element Plus 的el-image自帶懶加載能力加一個(gè)lazy屬性即可。如果你自己寫img標(biāo)簽可以用原生的loadinglazy屬性現(xiàn)代瀏覽器都支持。第三個(gè)是構(gòu)建層面的優(yōu)化。npm run build打包后用vite-plugin-compression開啟 gzip 壓縮部署到 nginx 后配合gzip on配置傳輸體積能再降 60% 以上。一般來說就算不做代碼層面的極致優(yōu)化這三板斧下來首屏已經(jīng)很快了。部署流程我一般是這樣前端npm run build生成dist目錄把 dist 里的文件上傳到服務(wù)器的靜態(tài)資源目錄nginx 配置里把/指到dist/index.html把/api反向代理到后端服務(wù)。關(guān)鍵是 nginx 需要做try_files $uri $uri/ /index.html否則用戶直接在瀏覽器地址欄輸入路由地址比如/cart訪問時(shí)nginx 找不到對應(yīng)的物理文件會(huì)返回 404。server { listen 80; server_name your-domain.com; root /var/www/vue-shop/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://localhost:8080/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }這一段 nginx 配置是我每個(gè)商城項(xiàng)目都要用到的模板改下域名和后端地址就能直接用。try_files那一行是 SPA 應(yīng)用部署的精髓不理解這行的作用部署完路由跳轉(zhuǎn)會(huì)各種 404。做商城項(xiàng)目這幾年我最大的體會(huì)是這類項(xiàng)目的價(jià)值不在于某個(gè)技術(shù)點(diǎn)有多深而在于把幾十個(gè)常見功能串起來的工程能力。從環(huán)境搭建、組件拆分、狀態(tài)管理、接口封裝到路由權(quán)限、性能優(yōu)化、最后部署上線每一步單獨(dú)拿出來都能寫一篇教程但真正讓你成長的是把它們整合在一起、在真實(shí)場景里解決一個(gè)又一個(gè)具體問題的過程。如果你正準(zhǔn)備拿一個(gè) Vue 商城項(xiàng)目來練手或應(yīng)對面試我的建議是不要上來就找完整源碼直接跑一定自己動(dòng)手敲一遍核心模塊——購物車和 SKU 選擇器這兩個(gè)功能手寫一遍比看十遍源碼都管用。寫完這兩個(gè)模塊你對 Vue 的響應(yīng)式、computed、組件通信的理解會(huì)上一個(gè)臺(tái)階。后面再遇到什么問題歡迎在評論區(qū)留言交流。本文還有配套的精品資源點(diǎn)擊獲取