企业官网建设流程全解析

简介：基于 Vue 框架的手机批发商城前端源码包，面向毕业设计选题学生、Vue 入门开发者以及需要快速搭建移动端商城界面的前端学习者。项目以商品批发场景为核心，从前端工程层面展示组件拆分、页面跳转和样式组织方式，可作为课程设计或毕业设计的前端基础。压缩包共 113 个文件，整体约 10.43MB，其中包含 9 个 Vue 组件与 6 个 JavaScript 逻辑文件，配合 3 个 CSS 样式文件、2 个字体文件和 2 个 JSON 配置；80 张 JPG 图片多为商品展示素材，另含入口 HTML、站点图标及说明文档，结构上直接体现常见 Vue 项目的目录划分。资源描述中提供了 npm install、npm run serve、npm run build 等标准命令，便于在本地完成依赖安装、开发调试与生产构建。已有 203 人浏览学习。通过该源码可进一步分析移动端商城的信息架构、列表与详情页的组件复用方式，以及 MUI 样式库的引入策略，为毕业设计或商城类实训项目提供可运行的完整前端参考。

1. 拿到这套 vue 手机批发商城前端源码，先分清和零售商城的差异

一套手机批发商城的前端，核心不是“看起来好看”，而是把批发场景里的阶梯价、起批量、多规格SKU、采购单这些概念在数据流里做对。用 vue 实现时，难点集中在商品列表的价格计算、购物车的数量与价格联动上。这套前端源码里你能看到的核心模块就是商品展示、规格选择、购物车、订单提交这一条线。对正在做毕业设计的同学来说，最值得研究的不是某个炫酷交互，而是它的数据组织方式。你在答辩时讲清楚“前端如何管理同一款手机的三个价格档”或“多规格库存联动怎么实现”，比演示动画组件更有说服力。这篇文章按一条完整开发路径展开：从解压源码到本地跑通，再逐模块读代码，最后落到打包部署和排错技巧。

2. 从 zip 到本地能跑：vue 前端源码的环境配置与依赖安装

2.1 先看 package.json，判断 vue 项目用的是哪条构建链路

拿到 zip 解压后，第一件事不是急着 npm install，而是打开 package.json，确认这个 vue 项目是 webpack 构建还是 vite 构建。两者在启动命令、环境变量、打包行为上差异明显。vite 项目的 scripts 里一般是 vite dev、vite build，依赖列表含 vite 和 @vitejs/plugin-vue；vue-cli 项目则是 vue-cli-service serve、vue-cli-service build，依赖里含 @vue/cli-service。这个判断直接决定你后面怎么配代理、怎么改打包路径，不能省略。

{ "scripts": { "serve": "vue-cli-service serve", "build": "vue-cli-service build" }, "dependencies": { "vue": "^2.6.14", "vue-router": "^3.5.1", "vuex": "^3.6.2" }, "devDependencies": { "@vue/cli-service": "~5.0.8" } }

上面是一个典型的 vue2 + vue-cli5 工程依赖结构。vue-router 是 3.x，路由写法是new Router()而不是createRouter()；vuex 是 3.x，状态管理是 options 风格而不是 setup 风格。这些版本信息不是给你背的，是让你查资料时能精准定位，因为 vue3 的写法在这里完全不适用，搜出来的资料如果版本不对，参考价值会大打折扣，动手改代码时也容易把两个时代的语法混在一起。

2.2 安装依赖时常见的 node 版本陷阱

依赖装不上、启动报错，大多数情况是 node 版本和依赖不兼容，而不是源码本身有问题。推荐先执行node -v确认版本，vue-cli5 项目建议用 node14 到 node16，vite5 项目建议 node18 以上。如果你电脑装的是高版本 node，装 vue2 项目时经常遇到 node-sass 编译失败，报错信息里一般带gyp ERR字样，解决方式是把样式相关依赖从 node-sass 换成 dart-sass，改一下 package.json 里的 sass 包名，重新安装即可，不需要动源码逻辑。

npm install --registry=https://registry.npmmirror.com npm install --legacy-peer-deps

第一条指定国内镜像源，避免网络超时。第二条跳过 peerDependencies 的版本冲突检查。为什么需要第二条？因为老项目的 eslint 或 sass 间接依赖之间的 peerDependencies 比较严，npm 7 以后默认严格校验，会导致安装失败，加上这个参数就按宽松模式处理。如果你用的是 yarn，对应的是 yarn install，冲突情况较少，但遇到时可以给 package.json 显式添加 resolutions 字段固定间接依赖的版本。依赖装完后，启动命令按 scripts 里的来。前端工程在开发阶段跑在内存里，只有 build 才输出静态 dist 文件夹，开发调试阶段接口请求依赖 devServer 的代理配置，这也是很多人本地页面能打开但数据不显示的原因。

2.3 配置 devServer 代理解决本地跨域

手机批发商城的前端和后端大概率不是同一个端口。比如前端跑在 8080，后端接口跑在 8090，直接 axios.get('http://localhost:8090/api/goods') 会被浏览器同源策略拦截。实际工程里的标准做法是在 vue.config.js 里配置 devServer.proxy，让所有 /api 开头的请求转发到后端服务地址。

module.exports = { devServer: { port: 8091, proxy: { '/api': { target: 'http://localhost:8090', changeOrigin: true, pathRewrite: { '^/api': '' } } } } }

这段配置的逻辑是：当前开发服务器监听 8091 端口，页面里请求 /api/goods 时，本地服务器把请求转发给 target 地址，pathRewrite 里的^/api表示去掉 URL 里的 /api 前缀再转发。如果你的后端接口本身就带 api 前缀，pathRewrite 就写空对象或者不写。改完 vue.config.js 后必须重启 npm run dev 才会生效，这是高频踩坑点，不少同学改了配置发现没反应，就是因为没有重启开发服务。

3. 基于 vue 的商品列表与多规格 SKU 选择实现

3.1 商品列表页的数据结构与最低价计算

手机批发商城的商品和零售商城最大的区别在价格模型和库存模型。零售通常是单 SKU 单价格，批发是多个规格、多个价格档。前端源码里商品数据一般这样组织：

const goodsItem = { id: 1001, title: 'Redmi Note 12 8+256G', cover: require('@/assets/redmi-note12.jpg'), skus: [ { spec: '黑色', price: 1150, stock: 200 }, { spec: '白色', price: 1160, stock: 150 } ], priceLevel: [ { min: 1, max: 9, price: 1180 }, { min: 10, max: 49, price: 1150 }, { min: 50, max: null, price: 1120 } ] }

商品列表骨架用 v-for 遍历渲染即可。每个商品卡片要有三个核心信息：起批量、阶梯价范围、当前规格可售库存。列表页不能只显示第一个 SKU 的价格，要在多个规格和多个价格档里取出最低的那个价，这个逻辑决定列表页展示的成本是否直观。

const minPrice = computed(() => { const tierPrices = goodsItem.value.priceLevel.map(item => item.price) return Math.min(...tierPrices) })

用计算属性求最低价，只要 goodsItem 是响应式的，价格会随数据变化自动更新。需要注意 computed 的依赖收集机制，如果你把 map 出来的数组存成中间变量再用，要保证中间变量也是响应式的或不依赖异步数据，否则会出现价格不刷新的情况，页面看起来就没反应。

3.2 多规格选择组件的状态管理

多规格选择是毕设答辩时最容易讲清楚、也最容易写乱的模块。常见做法是一个商品有多个规格维度，比如手机批发场景里的“颜色”和“内存”，每个维度下有若干选项。用户每选中一个维度，要联动判断另一个维度里哪些选项当前不可选，因为某些组合没有库存。

前端实现时用一个二维结构表示可选项：

const specGroups = [ { name: '颜色', values: ['黑色', '白色', '蓝色'] }, { name: '内存', values: ['8+128G', '8+256G', '12+256G'] } ] const selectedSpecs = reactive({ '颜色': '', '内存': '' }) const stockMap = { '黑色-8+256G': 120, '白色-8+256G': 0 }

然后在模板里给每个规格选项绑定点击事件，点击时更新 selectedSpecs，用 getStockCount(specA, specB) 查组合库存，库存为 0 的选项直接置灰：

function isOptionDisabled(groupName, optionValue) { const temp = { ...selectedSpecs, [groupName]: optionValue } const keys = Object.keys(temp).map(key => temp[key]).filter(Boolean).join('-') const count = stockMap[keys] return count === undefined || count === 0 }

这段逻辑说明一下：点击某个规格时，临时复制一份当前已选中的规格，用当前点击的值覆盖对应维度，拼成组合键去查库存表。如果该组合不存在或库存为 0，该选项禁用。你可以扩展成接口返回可用规格组合，前端只需遍历所有维度、选出不冲突的选项即可。这个概念和电商前台的 SKU 计算是同一套思路，毕设答辩能说透这套联动就是亮点。注意这个函数是纯前端计算，接口返回的库存数据结构越规整，前端联动代码越简单，所以先和后端约定组合键格式，比前端写复杂适配更省事。

3.3 阶梯价的展示与实时档位标识

批发商城的列表页详情页都离不开阶梯价，常见展示形态是“1-9台 / 10-49台 / 50台以上”，价格逐级降低。前端要做的是把 priceLevel 数组逐行渲染，同时根据当前购物车里的数量实时标出“当前已达到哪个阶梯价”。这个实时标识依赖全局的选购数量，所以状态不能只放在组件内部，要放进 vuex 或 pinia。vue2 项目里用 vuex，常规写法是定义 state.cartItems，getters 里写 getTierByGoodsId 和 cartTotalPrice。

state: { cartItems: [ { goodsId: 1001, spec: '黑色 8+256G', quantity: 15, unitPrice: 1150 } ] }, getters: { goodsTotalQuantity: (state) => (goodsId) => { const items = state.cartItems.filter(item => item.goodsId === goodsId) return items.reduce((sum, item) => sum + item.quantity, 0) }, cartTotalPrice: (state) => { return state.cartItems.reduce((sum, item) => sum + item.unitPrice * item.quantity, 0) } }

这里要注意，unitPrice 最好是加入购物车那一瞬间根据当前数量的阶梯价计算出来的快照，而不是等结算时再重新计算。因为用户加入购物车后如果又去改数量，再回来结算，价格应该按最新数量对应的阶梯价重算。所以购物车项里存 unitPrice 之外，还要在数量变更的 action 里触发一次价格重新计算。这种“快照+重计算”的策略在批发采购场景里很实用，也是很多前端源码里做得粗糙的地方。还有一点：getters 返回的总价在批量场景下可能因为“阶梯价变化”突然跳动，要在 UI 上给出价格变化的来源提示，比如“数量超过 10 台，单价降为 1150 元”，不然用户会以为系统算错了。

4. 基于 vue 的购物车、批量采购单与路由权限

4.1 购物车里数量加减时的价格联动与库存校验

购物车在批发商城里的角色更像“采购单”，每调整一次数量，都要重新确认阶梯价是否变化、当前 SKU 的剩余可买库存是否够、有没有低于单台下限。这三件事如果分开做容易出 bug，比较好的组织方式是把它们收敛在同一个函数里。

function changeQuantity(cartIndex, action, maxStock) { const item = cartItems.value[cartIndex] const newQty = action === 'increment' ? item.quantity + 1 : item.quantity - 1 if (newQty < item.minQty) { ElMessage.warning('低于起批量，请重新选择') return } if (newQty > maxStock) { ElMessage.warning('超过库存上限') return } item.quantity = newQty item.unitPrice = getPriceByQuantity(item.goodsId, newQty) recalcCart() }

recalcCart 内部再去计算整个购物车总数量和总价。建议用 reducers 分组按 goodsId 聚合，因为同一个 goodsId 可能会有多个规格，聚合后得到“某款手机总订货量”，再拿这个量去匹配阶梯价。很多前端新人只按购物车条目的 quantity 去对应阶梯，导致同款手机两个颜色加起来足够达到批发门槛，却没有享受批发价。这在商业逻辑上是错的，毕业设计里一定要避免。核对方式也很简单：在页面上把两个颜色的数量各调到 6 和 7，看单价是否按 13 台对应的档位计算，不是就有问题。

4.2 路由权限：游客与登录用户看到不同页面

手机批发商城的典型用户是 B 端采购商，通常需要登录才能看到批发价和提交订单。前端路由用 vue-router 的全局前置守卫来控制。vue-router3 的写法是 beforeEach，判断 to.meta.requiresAuth 和 vuex 里的 token 状态。

const router = new Router({ mode: 'history', routes: [ { path: '/login', component: Login, meta: { title: '登录' } }, { path: '/goods', component: GoodsList, meta: { title: '商品列表' } }, { path: '/cart', component: Cart, meta: { requiresAuth: true } }, { path: '/order/confirm', component: OrderConfirm, meta: { requiresAuth: true } } ] }) router.beforeEach((to, from, next) => { const token = localStorage.getItem('phone_mall_token') if (to.meta.requiresAuth && !token) { next({ path: '/login', query: { redirect: to.fullPath } }) } else { next() } })

逻辑不复杂，但有一个细节容易被忽略：登录时 vuex 里的 token 会重置，刷新页面后 vuex 数据丢失，所以要在 main.js 或 store 初始化的地方从 localStorage 恢复登录态。这段代码用 query 里的 redirect 记录跳转来源，登录完成后 push 回去，体验会完整很多。如果你是 vue3 + vue-router4，写法基本一样，只是 createRouter 和 createWebHistory 的导入来源不同。还有一点要留意：mode: 'history'在本地开发没问题，部署到服务器后必须配合 nginx 的 try_files 配置，否则刷新子路由会 404，这一点在最后一章展开。

4.3 创建订单页的数据组装逻辑

下单页需要把购物车数据组装成后端要的 JSON 结构。前端不只是展示购物车，要按后端接口文档的要求把数据结构整理出来，通常是一个订单主表加一个订单明细数组。前端要把 skuId、数量、单价快照、小计都算清楚，再传给后端。

function buildOrderPayload() { return { customerId: currentUser.customerId, totalQuantity: cartTotalQuantity.value, totalAmount: cartTotalAmount.value, items: cartItems.value.map(item => { return { skuId: item.skuId, quantity: item.quantity, price: item.unitPrice, subtotal: item.unitPrice * item.quantity } }) } }

订单下完以后要清空购物车里对应的条目，不能整单清空所有商品，因为购物车里可能有几种商品分属不同供应商，本次下单只提交一部分。清空时通过 skuId 过滤即可。这一步做得干净的源码，后端的对账逻辑会省很多事，也是工程质量很直观的体现。还有一个细节：提交订单请求发出后，前端要防重复点击，常见做法是给提交按钮加一个 loading 状态并禁用点击，等接口响应后再恢复，不然用户双击会生成两笔订单。

5. 打包后布局异常排查、nginx 部署与 menu 按钮定位技巧

5.1 打包后页面空白、CSS 丢失：先查 publicPath 和资源路径

本地开发正常，npm run build 之后部署到服务器，打开页面空白或者样式全丢，这是 vue 前端项目最经典的打包后布局异常场景。最常见原因是没有配置 publicPath，打包后的 index.html 里引用的资源是绝对路径 /js/app.js，如果你部署在服务器的子目录 /mall/ 下，这些资源就 404 了。排查方法是打开浏览器开发者工具看 Network，观察 js/css 的请求路径，与页面实际部署路径对照，通常一眼就能看出路径对不上。

// vue.config.js module.exports = { publicPath: './', outputDir: 'dist', assetsDir: 'static' }

publicPath 设置为 './' 后，构建出的 index.html 会把资源路径改成相对路径，比如 static/js/app.js。这样只要 index.html 所在目录结构不被破坏，放到任意子目录都能运行。assetsDir 指定静态资源输出的目录名，方便部署时和后端放在一起做静态托管时区分。对于图片放在 src/assets 里的场景，要确定图片是 import 或 require 引入的，webpack 才会参与处理；如果你写在 url() 里，注意相对路径要基于当前文件而不是页面，否则打包后图片会 404。

5.2 部署到 nginx 后刷新页面 404：history 路由模式的 try_files 配置

如果路由用了 mode: 'history'，本地开发没问题，部署到 nginx 后刷新一个 /goods/1001 页面会报 404。原因是 nginx 找不到对应路径的物理文件，需要配置 try_files 将请求回退到 index.html。常规做法是在 nginx 配置里的 location / 下加一行：

location / { root /opt/mall/dist; index index.html; try_files $uri $uri/ /index.html; }

最后一行的意思是：如果 URI 没对应到实际文件，就返回 index.html，让前端路由自己解析当前路径。此时页面内 API 请求会落到同一个 nginx 域名下，需要再给后端接口单独配一个 location 做转发，比如 location /api { proxy_pass http://127.0.0.1:8090; }。这里要特别说明：开发时你在 vue.config.js 里配的 proxy 只对 devServer 生效，打包后不会再有 node 服务帮你转发，部署阶段必须由 nginx 完成接口转发，这是很多人上线后才发现的坑。你可以用一个简单方式确认：打包后在本地起一个静态服务，点链接正常，刷新 404，基本就是 nginx 的 try_files 没配。

5.3 用环境变量区分开发、测试、生产接口地址

前端源码里如果只有一份写死的 axios baseURL，换环境就得改代码重新打包，不优雅。推荐方式是利用 vue-cli 的环境变量文件。

# 根目录 .env.development VUE_APP_API_BASE=/api # 根目录 .env.production VUE_APP_API_BASE=https://mall.example.com/api

在代码里通过 process.env.VUE_APP_API_BASE 取接口前缀。因为 npm run serve 默认加载 .env.development，npm run build 默认加载 .env.production，这样同一份源码可以用不同配置打包，不需要手动注释代码。注意自定义变量名必须以 VUE_APP_ 开头，否则不会暴露到客户端代码里。打包前确认一下 dist 目录里的 js 文件没有残留本地后端地址，检查方式是全局搜 http://localhost，只要出现就是没有正确替换环境变量，需要检查 .env.production 是否放在了项目根目录而不是 src 下。

5.4 快速自查优先级：网页按钮定位异常时的依赖排查顺序

遇到打包后页面按钮位置错乱或点击区域偏移这类布局异常，先看有没有引入全局 CSS 被压缩后顺序变化。有些源码在 main.js 里同时引入 element-ui 的样式和自定义覆盖样式，打包后 CSS 合并顺序和开发时不一致，会导致按钮、弹窗错位。解决办法是在 public/index.html 里用 link 标签显式引入第三方样式，再在 main.js 里 import 自定义样式，可以规避绝大部分样式覆盖顺序问题。如果页面某个“确认下单”按钮点击后没有反应，打开控制台看报错是不是来自某个异步方法未处理，比如 token 过期后接口返回 401，按钮回调里没有统一拦截提示。

axios.interceptors.response.use( response => response, error => { if (error.response && error.response.status === 401) { router.push({ path: '/login', query: { redirect: router.currentRoute.fullPath } }) } return Promise.reject(error) } )

这段拦截器的用途是统一处理 401，避免每个页面都写一遍 token 失效逻辑。可以看到这个排查顺序是：先确认静态资源路径正确，再确认路由 fallback 配置，再看接口请求是否被转发到正确地址，最后看全局异常是否被捕获。按这个顺序走下来，绝大多数打包后布局异常和交互失效都能定位到具体环节，这也是我在接手任何一套 vue 前端源码时固定会做的一轮排查路径。

本文还有配套的精品资源，点击获取