企业官网建设流程全解析

如果你正在准备毕业设计，或者想让简历上多一个能打的完整项目，那“商城系统”这四个字大概率绕不开。而这次我整理的这套基于SpringBoot+Vue的猫咪商城管理系统，算是把这个常见选题做得稍微有点辨识度的一套工程化代码。

整套项目不只有源码，还配套了完整的设计文档、答辩PPT和数据库脚本。从后端接口设计、前端页面开发，到Vue打包放进SpringBoot一体化部署，再到订单并发扣减这种容易被追问的细节，我都在这篇博文里把关键思路和实际踩过的坑写清楚。适合对象很明确：正在做Web方向毕业设计的在校生，以及打算用一套全栈项目充实简历的初、中级开发。

1. 选题逻辑与技术选型：这是一套工程化的猫咪商城

1.1 为什么毕业设计或简历项目要选商城

商城系统的经典程度是别的选题比不了的。从用户注册登录、商品展示、购物车，到订单创建、支付模拟、后台管理，几乎覆盖了一个Java后端开发者日常会碰到的所有技术面：增删改查、状态机、事务、并发、文件上传、权限控制。

更关键的是，商城的业务链路足够长，长链路才有东西可写。文档里可以画流程图，答辩时可以讲状态流转，简历上可以写“独立完成从需求分析到部署上线的完整流程”。相比之下，“图书管理系统”这类选题业务太薄，一个普通CRUD就没了，问到并发和事务时很难往深处聊。

我不太建议选“通用商城”这种名字，太容易和网上下载的模板撞车。这套项目叫“猫咪商城”，主题本身就是一个记忆点。商品分类围绕宠物主食、零食、猫砂、玩具做设计，页面文案、分类命名都贴合真实养猫场景，答辩时评委扫一眼截图就能记住这个项目，而不是听完就忘的“某某商城”。

1.2 技术栈版本与选型理由

版本选择这种事，看着简单，其实最容易踩坑。尤其SpringBoot 3.x发布之后，很多人直接跟着网上新教程用3.x，结果本地JDK还是8，编译直接失败。下面是我在这套项目里锁定的版本组合：

选SpringBoot 2.7而不是3.x，是最重要的一次决策。3.x强制JDK17，而很多毕设环境还是JDK8，即便你自己装了JDK17，指导老师电脑上跑不起来也很麻烦。2.7.18是SpringBoot 2.x最后的维护版本，安全更新到2023年底，对于教学和演示场景完全够用。

Vue这块我选了Vue2.7，而不是Vue3。原因很现实：大部分现有商城模板、Element UI组件、答疑帖子都基于Vue2，遇到问题找资料快。Vue2.7虽然还是Options API风格，但已经支持<script setup>，写起来并没有落后太多。

1.3 数据库核心表设计：解决“表怎么建”的问题

数据库设计决定了这个项目能聊多深。我给这套系统规划了十来张核心表，挑几张重点说说设计思路。

• user用户表：除了常规的username、password、phone，加了一个role字段区分普通用户和管理员，权限控制先走角色，不做细粒度权限。
• category分类表：一级分类结构，比如“猫咪主粮”“零食罐头”“猫砂用品”“玩具周边”，用parent_id支持后续无限级扩展。
• goods商品表（SPU层）：存商品标题、主图、详情富文本、销量、上下架状态。价格和库存不放这里，因为同一个商品可能有多个规格。
• goods_sku规格表（SKU层）：一个商品对应多个SKU，例如“鸡肉味2kg”“鱼肉味2kg”“鸡肉味5kg”，每个SKU单独记录price、stock、spec。
• cart购物车表：字段包括user_id、goods_id、sku_id、quantity。主键用自增id，同时给user_id建索引。
• orders订单表：核心字段包括order_sn订单号、user_id、total_amount、freight、pay_type、status、address_snapshot。
• order_item订单明细表：一个订单对应多个商品快照，快照里保存了当时的价格、商品名、规格，避免后续商品改名影响历史订单。
• address收货地址表：默认地址用is_default字段标识，每次只有一个默认地址。

有几个细节值得说明。订单表里的address_snapshot我存的是下单时地址的JSON字符串，而不是外键关联地址表。因为用户改地址不应该影响历史订单的配送信息，快照是订单系统里很常用的做法。order_sn我生成规则是“yyyyMMddHHmmss + 用户ID + 四位随机数”，保证唯一性的同时方便肉眼排查问题。

商品表和SKU表分离这件事，很多人容易忽略。如果只用一个商品表，把“价格”“库存”塞进去，遇到多规格商品就会非常痛苦：改一个规格的价格要更新整个商品，购物车也没法精确记录用户选的是哪个规格。拆出SKU表之后，商品详情页的规格选择、购物车快照、订单明细都有据可循。

2. SpringBoot后端：用户认证、商品查询与订单状态机

2.1 工程分层与统一返回结构

后端工程我按照标准的分层结构组织：controller、service、mapper、entity、dto、config、common。controller层只做参数接收和结果包装，不写业务逻辑；service层处理具体业务；mapper层用MyBatis-Plus的BaseMapper，单表操作基本不用写SQL。

一个容易被忽略但很影响代码质量的点，是统一返回结构。我定义了一个Result<T>类，所有接口返回格式固定为{code, message, data}。前端axios响应拦截器只需要判断code是否等于200，不用每个接口单独写一套错误处理。

public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { ... } public static <T> Result<T> error(String message) { ... } }

配合全局异常处理器@RestControllerAdvice，业务异常、参数校验异常、兜底异常都能统一转成Result格式。这样做的好处是：前端联调时减少80%的“这个接口返回格式怎么不一样”类问题，后端的错误堆栈也不会直接暴露给用户。

2.2 用户登录注册与JWT刷新方案

登录认证这块，我抛弃了传统的Session方案，改用JWT。核心原因有两个：前后端分离架构下，Session跨域处理麻烦；商城后台需要区分用户角色，JWT可以把用户ID和角色写进token里，后端解析一次就能拿到全部身份信息。

密码存储用BCrypt加密，代码里只需要一行：

String encodedPassword = BCrypt.hashpw(rawPassword, BCrypt.gensalt());

注册时把加密后的密码写入数据库，登录时用BCrypt.checkpw(rawPassword, encodedPassword)校验。BCrypt是自带盐的哈希算法，同一密码两次加密结果不同，安全性比MD5加固定盐高一个数量级。面试或者答辩时如果被问到“密码明文存储会有哪些风险”，这是一个可以直接答上来的加分项。

JWT这块我用的java-jwt库，生成token时把userId和role放进payload：

String token = JWT.create() .withClaim("userId", user.getId()) .withClaim("role", user.getRole()) .withExpiresAt(new Date(System.currentTimeMillis() + 2 * 60 * 60 * 1000)) .sign(Algorithm.HMAC256(secretKey));

后端写一个拦截器统一校验请求头里的token，校验通过后把userId放到ThreadLocal里供后续Service使用。这里有两个实战细节：一是放行登录、注册、商品列表、商品详情这些公开接口，其余接口全部需要token；二是过期时间我设了2小时，前端在axios响应拦截器里发现401就直接跳登录页，并清除本地登录态。

2.3 购物车合并思路与商品列表接口

购物车有经典的两种实现路线：纯前端本地存储，或者后端接口同步。我在这套系统里做了一个折中方案：未登录时购物车数据存到浏览器LocalStorage，登录后点击购物车时，前端先把本地购物车数据提交到后端，由后端合并到数据库购物车表，并清空本地数据。

合并逻辑按SKU维度进行：前端传来的本地购物车数据逐条检查数据库里是否已有相同user_id加sku_id的记录，有就累加quantity，没有就插入新记录。这个方案兼顾了未登录用户的购物体验和登录后的数据持久化，毕设答辩时还能作为“本地缓存与服务端数据同步”的案例来讲。

商品列表接口我做了三个条件：分类ID、关键字模糊搜索、价格排序。直接用MyBatis-Plus的LambdaQueryWrapper拼条件：

LambdaQueryWrapper<Goods> wrapper = new LambdaQueryWrapper<>(); if (categoryId != null) { wrapper.eq(Goods::getCategoryId, categoryId); } if (keyword != null && !keyword.isEmpty()) { wrapper.like(Goods::getTitle, keyword); } wrapper.orderByDesc(Goods::getSales);

分页用MyBatis-Plus内置的分页插件，前端传current和size，后端返回total和当前页数据。这样列表页可以直接交给Element UI的分页组件渲染。

2.4 订单创建的事务边界与超时关单

订单创建是整套系统里业务逻辑最密集的一段，涉及的步骤包括：校验收货地址、组装订单明细、计算总价、扣减SKU库存、生成订单号和明细记录、清空对应购物车。整个过程必须在一个事务里，任何一步失败都不能留下半截订单和已经被扣掉的库存。

我在订单Service方法上加@Transactional注解，同时把操作顺序设计为：先扣库存，再插入订单。扣库存使用了一条带条件的更新语句：

int rows = skuMapper.deductStock(skuId, quantity); if (rows == 0) { throw new BizException("库存不足"); }

对应的SQL核心逻辑是：

UPDATE goods_sku SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{skuId} AND stock >= #{quantity}

stock >= #{quantity}是防止超卖的第一道防线。SpringBoot中的@Transactional默认遇到RuntimeException会回滚，所以只要扣库存失败抛了异常，前面插入的数据会一起回滚，不会出现订单失败但库存少了的情况。

订单状态我用整型字段表示，比字符串更省空间也更方便比较：0待付款、1已付款、2已发货、3已完成、4已取消、5已关闭。用户下单后状态是0，点击“模拟支付”后变成1，这个模拟支付按钮是我刻意为之的——毕业设计场景对接真实微信/支付宝支付需要商户号，门槛高且审核麻烦，用模拟支付把状态流转跑通，核心流程不受影响，真要上线时只需要替换支付回调这一个接口。

超时未支付订单的关闭，我写了一个Spring定时任务，每5分钟扫描一次创建超过30分钟且状态为0的订单，批量改为已关闭，同时把扣掉的库存加回去。这个“释放库存”的逻辑很关键，不然超时订单会一直占着库存。

3. Vue前端：路由守卫、组件插槽与商城页面落地方案

3.1 Vue2.7与Element UI的生态选择

前端这层的选型我前面提过，Vue2.7加Element UI。需要多说一句的是，Element UI虽然官方已经不再更新，但它的表单组件、表格组件、分页组件、弹窗组件在管理端场景里依然非常好用，尤其是数据表格配合自定义列模板，写后台商品管理页面比手撸原生HTML高效十倍。

整套前端分成两个大界面：商城用户端和管理员后台。

用户端包含首页、商品列表、商品详情、购物车、结算页、我的订单、登录注册；管理员后台包含商品管理、分类管理、订单管理、用户管理、数据统计。两部分我放在同一个Vue工程里，用路由前缀区分：/mall开头的是用户端页面，/admin开头的是管理端页面。

3.2 页面路由设计：静态路由加动态权限路由

路由这块用了Vue Router，默认使用history模式。项目里的路由分为两部分：静态路由是所有登录用户都能访问的，比如首页、商品列表、登录注册；动态路由是管理员专属的，比如后台的商品管理、订单管理、数据统计页面。

// 静态路由 const routes = [ { path: '/login', component: Login }, { path: '/', component: Home }, { path: '/goods', component: GoodsList }, { path: '/goods/:id', component: GoodsDetail } ] // 动态路由：登录后根据用户角色追加 if (role === 'admin') { router.addRoute({ path: '/admin', component: AdminLayout, children: [...] }) }

登录成功后把用户信息存进Vuex，页面路由守卫beforeEach里判断当前路由是否需要登录，需要登录但本地没有token时统一跳转登录页，并带上redirect参数。

商品详情页的路由传参，我用了/goods/:id这种路径参数方式，而不是?id=xxx的query方式。路径参数更语义化，刷新页面不会丢失，订单页和结算页之间跳转则用query方式，方便携带多个参数。两种方式的使用场景我已经在实际项目里分得很清楚：单一ID用params，多个查询条件用query。

3.3 商品卡片组件复用与slot插槽

商城用户端有一个高频复用组件：商品卡片。首页的猜你喜欢、商品列表页、搜索结果的每一件商品都用同一套卡片来渲染。我把它抽成组件后，只暴露三个props：商品对象、是否显示标签、是否显示销量。

组件内部用Element UI的卡片组件，商品主图用懒加载指令，价格高亮显示。为了满足不同页面的个性化展示需求，我在卡片底部预留了一个插槽slot。首页会在插槽里显示一个“新品”角标，列表页会在插槽里显示促销倒计时，组件本身不关心插槽内容是什么，只需要替外部预留好位置。

<template> <el-card> <img :src="goods.mainImage" /> <div class="price">￥{{ goods.price }}</div> <div class="title">{{ goods.title }}</div> <slot name="tag"></slot> </el-card> </template>

这种组件拆分带来的收益在开发后期非常明显：需要调整商品展示样式时只改一个地方，全站所有商品卡片同步生效。答辩时如果被问到“组件化开发怎么理解”，这是一个可以直接指向的代码实例。

3.4 购物车与结算页的前端状态管理

购物车页面是前端状态最复杂的页面：多选、全选、数量加减、删除、合计金额，这些状态全部联动。我用Vuex管理购物车状态，state里存一个购物车商品数组，mutations负责加减数量、切换选中，getters负责计算选中的商品数量和总金额。

结算页会做三步处理：一是从购物车读取选中的商品；二是请求后端地址列表，让用户选择或新增收货地址；三是点击“提交订单”后调后端接口创建订单。整个流程中后端只信任自己数据库里的数据，前端购物车里的金额只做展示，不参与最终价格计算，后端会根据SKU表里的真实价格重新计算一次总价。

4. 前后端联调阶段：跨域、上传与鉴权三件坎

4.1 开发环境代理与后端CORS配置如何取舍

前后端分离项目联调时，第一个遇到的就是跨域。前端跑在http://localhost:8081，后端跑在http://localhost:8080，浏览器直接发请求必然被CORS拦截。

我给了两套方案：

• 开发环境用Vue CLI的devServer.proxy配置代理，前端请求/api前缀自动转发到http://localhost:8080，浏览器看到的是同源请求，不存在跨域。
• 生产环境前端被打包进后端，本身就是同端口访问，没有任何跨域问题。

后端我也加了一个CorsFilter配置作为兜底，但优先级最低。开发时优先走前端代理，这样不用每次改动都去后端加跨域配置。有的同学习惯直接在后端@CrossOrigin注解解决跨域，也能跑通，但生产环境如果域名做了变化，这些硬编码的跨域配置反而会成为隐患。

4.2 图片上传的本地落盘与静态映射

商品图片上传我采用了最简单也最适合毕设的本地存储方案。后端接收MultipartFile，按日期生成目录，文件名用UUID避免重复，保存到项目根目录的uploads目录，数据库存相对路径如/uploads/2024/06/xxx.jpg。

关键在后端静态映射。SpringBoot默认只映射classpath:/static/目录，我要让/uploads/**也能被直接访问，于是写了一个配置类：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/uploads/**") .addResourceHandler("file:" + uploadDirPath); } }

如果省略这段配置，图片上传后前端通过http://localhost:8080/uploads/xxx.jpg访问会直接404，这是本地图片方案最常见的坑。另外要注意SpringBoot的multipart.max-file-size默认只有1MB，我在配置文件里调到了10MB，不然上传商品主图会报“文件大小超出限制”。

4.3 401响应拦截与登录态统一处理

前端axios封装里，请求拦截器统一从localStorage取token，放进请求头的Authorization字段。响应拦截器统一处理后端返回的code，这里有一个很实用的细节：当后端返回401表示token过期时，前端需要先清掉本地存储的登录信息，再跳转登录页，同时用一个全局变量防止多个接口同时报401导致重复弹跳。

service.interceptors.response.use( (response) => { const res = response.data if (res.code !== 200) { Message.error(res.message || '请求出错') return Promise.reject(new Error(res.message)) } return res }, (error) => { if (error.response.status === 401) { localStorage.clear() router.push('/login') } return Promise.reject(error) } )

这里要注意，401跳转时不能简单window.location.href = '/login'，否则会丢失当前路由地址，没法在登录后跳回原页面。我用router.push({path:'/login', query:{redirect: router.currentRoute.fullPath}})保存来源地址。

4.4 联调排错的经验套路

联调阶段遇到问题，我习惯按固定顺序排查：

1. 打开浏览器Network面板，看这个请求到底发出去了没有，接口路径和后端Controller里的@RequestMapping值是否完全一致。
2. 看请求状态码：404一般是路径不对；500一般是后端代码报错；401是token缺失或过期；405一般是GET/POST方法对不上。
3. 看后端控制台日志，SpringBoot默认会打印异常堆栈，先找到第一行java.lang.Exception，再看具体在哪个Service方法抛出的。
4. 如果是参数为null的问题，大概率是前端字段名和后端实体字段名对不上，比如前端传userName，后端实体类字段是username。

这套排查套路帮我在实际开发中省了很多时间。遇到问题先不要急着改代码，先把“到底是哪一层的问题”确认清楚，再动手。

5. Vue打包进SpringBoot的集成部署与404排查

5.1 为什么建议做成单端口一体化部署

Vue工程开发完，有两种部署路线：一是单独部署Nginx，反向代理后端接口；二是把Vue构建产物放进SpringBoot的static目录，打成一个大Jar包直接运行。

我在这套项目里选了第二种。原因有两方面：从使用场景看，毕设答辩要在一台电脑上快速启动演示，装Nginx、改配置、代理后端，对临时环境来说是徒增负担；从部署方式看，一个java -jar命令解决问题，演示前只需要确认Java环境存在，风险点最少。

两种方案的对比，我在文档里也写了一段：

5.2 前端构建到后端静态目录的操作流程

实际操作流程分四步：

第一步，前端工程修改接口地址。开发时请求的是http://localhost:8080/api，打包后前端页面和后端接口同源，我统一改成相对路径/api，这样无论部署到8080还是80端口都能自适应。

第二步，执行构建命令：

npm run build

构建完成后在dist目录生成index.html、css、js、static等文件。

第三步，把dist目录里的全部内容复制到SpringBoot的src/main/resources/static目录下。这里有个小注意点：复制前先清空static目录里的旧文件，否则旧资源残留可能导致缓存错乱。

第四步，后端执行打包：

mvn clean package -DskipTests

拿到target目录下的jar包后，java -jar直接运行，浏览器访问http://localhost:8080/就能看到首页。

5.3 刷新页面404的完整排查链路

这个坑我印象太深了。首次部署完成后，从首页点进商品详情页一切正常，但只要在商品详情页按F5刷新，页面就变成一个白屏加404错误。当时的第一反应是前端路由问题，但本地开发环境刷新明明没这个问题。

完整的排查链路是这样的：

先打开浏览器Network面板，刷新时发现请求的URL是http://localhost:8080/goods/1，响应状态404，响应体是SpringBoot默认的Whitelabel Error Page。这说明浏览器根本没有拿到前端的index.html，而是把/goods/1当成后端接口请求了。

再想一下本地开发为什么正常：Vue CLI的devServer对history模式做了兜底，所有没有匹配到静态资源的路径都会自动返回index.html，所以本地刷新没问题。但SpringBoot默认的静态资源映射没有这个逻辑，找不到/goods/1这个静态资源就直接404。

根因找到了，解决方案是在后端加一个视图控制：所有非/api开头且不是静态资源的路径，都转发到index.html，由前端路由接管。我写了一个配置类：

@Configuration public class SpaForwardConfig implements WebMvcConfigurer { @Override public void addViewControllers(ViewControllerRegistry registry) { registry.addViewController("/{path:[^\\.]*}") .setViewName("forward:/index.html"); } }

这段配置的意思是：路径中不包含点号的请求全部转发到index.html，因为静态资源一般都会带.js、.css、.png后缀，带后缀的请求走正常静态映射，不带后缀的交给前端路由。

这个转发配置是SpringBoot集成Vue history路由的必备方案。如果看完能理解“为什么本地启动没事、部署到后端就404”的原因，以后再遇到同类问题基本上可以一眼定位。

5.4 启动脚本与常见运行期问题

我习惯在项目根目录放一个启动说明文档，里面写清楚三个常见问题的解法：

• 端口被占用：java -jar启动时提示Port 8080 was already in use，除非换端口，否则先找到占用进程。Windows下用netstat -ano | findstr 8080查看PID，再去任务管理器结束进程。
• 数据库连接失败：SpringBoot启动报Communications link failure，大概率是MySQL没启动，或者数据库名、账号密码和application.yml里不一致。
• 图片路径丢失：jar包部署后，上传图片保存到的是jar包同级的目录，如果后续在别的机器上重新部署，需要把uploads目录一起拷贝，否则历史图片全部失效。

6. 并发扣减、订单幂等与答辩材料整理

6.1 库存扣减：从超卖事故到乐观锁方案

商城项目最容易被深挖的就是并发场景。我当时在做压测时故意模拟了50个用户同时下单同一件库存只有10件的商品，结果数据库里出现了库存负数的订单。复现过程是这样的：两个请求同时读到库存10，都判断库存充足，一起执行update stock = stock - 1，最后库存变成8，但生成了两条订单。虽然最终数据不精确，但足以证明“先查库存再扣减”的逻辑在并发下会超卖。

我采用的方案是把判断库存和扣减库存合并成一条SQL：

UPDATE goods_sku SET stock = stock - #{quantity} WHERE id = #{skuId} AND stock >= #{quantity}

数据库的行锁和条件判断保证了并发安全：同一时刻只有一个事务能更新这个SKU行，stock >= #{quantity}条件又保证了库存不足时不执行扣减。如果更新影响行数为0，说明库存不足，订单事务直接回滚。

在此基础上我又加了一列version做乐观锁，更新时带上version = #{oldVersion}，防止ABA问题。对于毕设场景，这个方案已经完全够用。真要在秒杀场景支撑更大并发，再去考虑Redis预扣库存、异步队列等更重的方案，我也在文档里写了这部分扩展思路。

6.2 防重复提交：前端置灰与后端幂等

除了超卖，另一个容易被刁难的问题是重复下单。用户快速点击“提交订单”两次，系统如果生成了两条一模一样的订单，就是典型的非幂等。

我的处理分两层：

• 前端提交按钮在点击后立即置灰并显示loading，直到后端返回结果才恢复。这一层挡掉大多数误触。
• 后端生成订单号时用order_sn做唯一索引，插入订单前先查询是否存在相同order_sn，插入时依靠数据库唯一索引兜底。真正执行创建订单的接口里，判断当前用户是否在60秒内有相同金额的进行中订单，有就直接返回已存在订单。

底层思路很好理解：防止用户产生重复数据，不能只靠前端，后端也要有拦截能力。数据库唯一约束是最后一道保底防线，三层叠加才能保证“无论请求怎么进来，订单都只有一条”。

6.3 文档、PPT、源码三件套的整理技巧

很多人把精力全放在写代码上，最后文档和PPT草草了事，结果答辩被问得手忙脚乱。这套项目我配套整理了一份设计文档，文档结构调整为：需求分析、系统架构设计、数据库设计、接口设计、核心业务流程、测试报告、总结与展望。

其中“数据库设计”和“接口设计”这两章，是评委最爱翻的部分。数据库设计里除了表结构字段说明，我还画了实体关系说明，重点标注外键关系和索引设计思路。接口设计表列了URL、请求方式、请求参数、返回结果，整理成接口文档后，前端联调和评委阅读体验都好很多。

PPT控制在14页左右，整体逻辑是：选题背景、需求分析、技术选型、系统架构图、功能模块图、数据库设计、核心流程、页面截图、亮点说明、总结。页面截图要挑最有代表性的首页、商品详情、购物车结算、后台商品管理、数据统计这五张，每张图配两三句说明，讲清楚页面的功能和实现方式。

源码交付这块我做了一个非常重要的整理动作：清点完整工程目录，确认Vue前端和SpringBoot后端代码齐全，数据库脚本db_cat_mall.sql单独放在根目录，README.md写清楚环境要求、启动步骤、默认账号密码。很多人的源码交上去跑不起来，问题往往不是代码不对，而是缺少数据库脚本或者默认端口冲突。我在README里写了默认管理员账号admin/admin123，测试用户user/user123，演示时直接登录，省去现场注册的时间。

写在最后

整套猫咪商城从最初搭建骨架到文档PPT整理完毕，最耗时的地方其实不在某个具体页面的实现，而在于把每个功能背后的“为什么”想清楚。比如订单状态为什么这样流转、库存扣除为什么用条件更新、Vue为什么必须加路由兜底配置，这些问题如果只是照抄代码是看不出来的，但一旦在答辩或简历中被问起，能不能讲清楚才是项目有没有真正变成自己的关键分界线。

如果要给正在做同类项目的朋友一个建议，我会说：优先把代码跑通，但一定不要停在跑通这一步。数据库表之间的关系、订单事务的边界、前端路由守卫的执行时机，这些“看不见的部分”反而决定了项目的含金量。源码、文档、PPT只是交付物，你脑子里的那套完整技术推理，才是这套项目带给你最核心的东西。