企业官网建设流程全解析

每年一到毕业季，“基于Java的XX管理系统”就会成为各种选题列表里的常客。汉服商城管理系统就是其中辨识度非常高的一类：它有清晰的角色划分，包含前台购物和后台管理两条完整链路，功能上覆盖了商品、购物车、订单、支付、权限等电商系统的核心模块，技术点上能串起Java Web开发的大部分知识点，用来做毕设或者简历项目都非常合适。这篇东西我会按自己实际做过的思路，把整个项目从设计到实现完整拆开讲一遍，不绕弯子，直接给能复现的方案。

1. 项目概述与整体设计思路

1.1 核心需求解析

汉服商城管理系统，本质上是一个垂直品类的B2C电商系统。汉服这个品类相比普通服装有几个特殊之处，这些细节直接决定了数据库和业务逻辑怎么写，不要把它当成普通的商品增删改查来做。

第一个特点是SKU维度多。一套汉服通常包含上衣、下裙、披帛、配饰等多个部件，每个部件的尺码和颜色可能不同，排列组合下来SKU数量会非常多。如果设计表结构时没考虑清楚SPU和SKU的分离，后面做购物车和库存管理会很被动。

第二个特点是商品详情信息重。汉服的商品详情页需要展示平铺图、模特上身图、面料细节、尺码对照表、形制说明等多类信息，这意味着图片资源和富文本内容的管理要从一开始就纳入设计范围，而不是简单用一个图片字段应付。

第三个特点是存在预售和分批发货的场景。一些热门汉服款是预约制或者限时返场，发货周期长，订单状态比普通服饰店要复杂一些，所以订单状态机的设计要留足扩展余地。

系统的核心用户分为三类：游客可以浏览商品但不能下单；注册用户可以完成完整的购物流程、查看订单、管理收货地址；管理员负责商品管理、订单处理、用户管理和数据概览。权限模型沿用了最常见的RBAC思路，但做了一些简化，没有引入细粒度的菜单权限，而是用角色字段区分管理员和普通用户，这样在答辩时也能讲清楚简化背后的道理。

1.2 技术选型与架构风格

技术栈方面，我选用的是Spring Boot 2.7 + MyBatis Plus 3.5 + MySQL 8 + Redis + Vue 3 + Element Plus这套组合。先解释一下为什么要这么选，因为这是答辩时第一个会被问到的问题。

后端没有用传统的SSM三大框架手写整合，而是用Spring Boot。两者的区别在于，Spring Boot通过自动配置大幅减少了XML配置，内置Tomcat让部署变得简单。对商城这类业务逻辑清晰、重CRUD的项目，Spring Boot能让开发重心放在业务代码而不是配置文件上，这是效率层面的考量。

持久层选了MyBatis Plus而不是纯MyBatis，原因也很现实：商城项目80%以上的数据库操作都是单表CRUD，MyBatis Plus的BaseMapper可以直接省掉大量重复的XML映射文件，让代码量下降非常明显。剩下那20%涉及到多表联查的部分，MyBatis Plus照样支持自定义SQL，并不会成为瓶颈。

ORM框架的对比这里顺带说一句，JPA/Hibernate虽然也是主流选择，但在国内电商项目中使用比例明显低于MyBatis系列，加上MyBatis Plus的文档和社区资料都更丰富，遇到问题能搜到的解决方案更多，对于正在做毕设或者初入行的同学来说更友好。

前端采用前后端分离架构，Vue 3负责页面渲染和数据交互，后端只提供JSON格式的RESTful API。为什么不继续用JSP做服务端渲染？答案很简单：前后端分离可以让后端专注于业务逻辑，同时首页加载体验更好，而且开发和调试效率更高，开发者工具里能直接看到每一个请求的状态和返回内容，这是JSP时代很难做到的。

Redis在这个项目里承担了三个职责：一是存储登录令牌的会话信息，二是缓存首页的分类和热门商品数据，三是实现购物车功能（购物车放Redis在电商项目里非常常见，能天然解决登录状态下的购物车同步问题，后面章节会详细展开）。

1.3 功能模块拆解

整个系统按角色拆分成两个端，前台商城和后端管理。

前台商城面向普通用户，包含以下模块：用户注册与登录、商品浏览（分类筛选、关键词搜索、商品详情）、购物车、订单确认与提交、模拟支付、订单管理（待付款/待发货/待收货/已完成）、个人中心（个人信息、收货地址管理）。

后台管理系统面向管理员，包含以下模块：数据概览（统计商品数、订单数、用户数、销售额）、商品管理（SPU维度维护商品基本信息，SKU维度维护具体规格库存）、分类管理、订单管理（查看订单明细、发货操作）、用户管理（启用/禁用账号）。

两个端共用一个后端服务，通过JWT令牌中的角色信息区分请求权限。后台管理接口统一使用/admin/**前缀，通过拦截器校验管理员身份，避免普通用户越权操作管理接口。

2. 数据库设计与核心表结构

数据库是整个商城系统的地基，这块如果设计得不好，后面写代码会特别别扭。我在设计时是以“一次购物完整生命周期”为主线来梳理的：用户注册登录 -> 浏览商品 -> 加入购物车 -> 生成订单 -> 模拟支付 -> 订单发货。沿着这条线，可以得到六张核心业务表外加两张辅助表。

2.1 核心表结构详解

用户表的设计比较常规，核心字段包含用户名、密码、手机号、头像、角色标识等。密码存储使用了BCrypt加密，而不是MD5或者SHA，因为BCrypt每次加密结果都不同，并且内置了盐值处理，能有效对抗彩虹表攻击，这也是面试时值得一提的细节。

商品相关的表是重点。我拆成了商品表（SPU）和商品规格表（SKU）两张。商品表保存标题、副标题、主图、详情图、形制分类、销量等共通信息；商品规格表保存具体某一个规格组合的独特信息，比如颜色、尺码、价格、库存、编码。用经典的“一SPU对多SKU”模型。

订单链路涉及三张表：订单表、订单商品明细表、收货地址表。订单表只保存订单号、用户ID、总金额、状态、支付方式等一次性信息，订单里涉及的具体商品快照则放进订单明细表。这里必须说明为什么要做“快照”：因为商品的价格和名称可能会调整，如果订单直接关联商品表，历史订单显示的价格会和用户实际支付的价格不一致，做快照才能保证订单数据的历史真实性。

购物车表我采用了Redis存储的方案，但这个方案在答辩时容易被问到“数据持久化”的问题，所以还需要预留一张购物车表做数据兜底，或者在以后的版本迭代说明中提及。Redis方案的核心思路是：每个用户的购物车用cart:用户ID作为Key，Hash结构存储SKU ID和数量，这样读写速度极快，天然避免了数据库行锁竞争。

为了让你对表结构有更直观的认知，这里给出商品表和订单表的简化建表语句。

-- 商品SPU表 CREATE TABLE `product` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '商品ID', `title` varchar(200) NOT NULL COMMENT '商品标题', `subtitle` varchar(500) DEFAULT NULL COMMENT '副标题', `category_id` bigint NOT NULL COMMENT '分类ID', `main_image` varchar(500) NOT NULL COMMENT '主图地址', `detail_images` text COMMENT '详情图地址，JSON数组', `detail_html` longtext COMMENT '商品详情富文本', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态：0下架 1上架', `sales_count` int NOT NULL DEFAULT '0' COMMENT '销量', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category` (`category_id`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品SPU表'; -- 商品SKU表 CREATE TABLE `product_sku` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT 'SKU ID', `product_id` bigint NOT NULL COMMENT '所属SPU ID', `sku_code` varchar(50) NOT NULL COMMENT 'SKU编码', `color` varchar(50) DEFAULT NULL COMMENT '颜色', `size` varchar(20) DEFAULT NULL COMMENT '尺码', `price` decimal(10,2) NOT NULL COMMENT '售价', `stock` int NOT NULL DEFAULT '0' COMMENT '库存', `image` varchar(500) DEFAULT NULL COMMENT '规格图', `status` tinyint NOT NULL DEFAULT '1' COMMENT '状态', PRIMARY KEY (`id`), UNIQUE KEY `uk_sku_code` (`sku_code`), KEY `idx_product` (`product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品SKU表';

订单表额外说明一个细节：订单号不建议直接用数据库自增ID，因为订单号会暴露每天的订单量，支付回调时也容易被遍历猜测。我采用了“时间戳+随机数”的生成方式，格式大致是20250423153000123456，时间精确到秒，后面加四位随机数，基本可以保证并发场景下不重复。如果项目后续要做分库分表，带上时间的订单号也更有利于按时间维度归档和查询。

2.2 表关系与设计取舍

表之间的关系用一句话概括：用户1对多订单，订单1对多订单明细，商品1对多SKU，订单明细和SKU是多对一但通过快照字段解耦。

几个设计取舍值得重点说：

为什么订单表不直接存用户地址快照？我确实这么做了。用户在提交订单时，会把收货地址的完整信息（省市区、详细地址、收件人、手机号）复制到订单表中，形成地址快照。这样即使用户后续修改了地址或者删除了地址，已产生的订单不受影响。很多初级项目在订单表只存一个地址ID，导致修改地址之后历史订单的收获信息跟着变了，这显然是不合理的。

为什么分类表不做无限级？汉服商城的分类层级比较固定，基本就是“襦裙/深衣/配饰”这种一层结构，最多加一个二级分类。用parent_id做无限级分类虽然灵活，但对这个项目来说增加了递归查询的复杂度，收益却不大。最终选择的是扁平化的一级分类，后续如果真要扩展层级，只需要加一个parent_id字段，对现有代码几乎零侵入。

库存字段应该放在哪一层？库存放在SKU表中，和价格同级。这里需要注意一个高频问题：“超卖”。简单的实现是在下单时执行UPDATE product_sku SET stock = stock - 1 WHERE id = ? AND stock > 0，通过SQL层面的条件判断来防止库存扣成负数。这是乐观锁思路的一种变体，不需要额外加version字段，效率高且足够安全。商品表的销量字段不承担库存的实时扣减，而是通过定时任务或者在事务内同步累加，避免两张表频繁联动。

3. 后端核心功能实现

3.1 项目分层与初始化

后端采用经典的四层结构：Controller层负责接收请求和参数校验，Service层处理业务逻辑，Mapper层负责和数据交互，Entity/DTO层做数据载体。这种做法可以保证各层职责单一，联调时快速定位问题在哪个环节。

项目初始化时重点配置三个地方：数据库连接池（我用的HikariCP，Spring Boot 2.x默认自带）、MyBatis Plus的分页插件和逻辑删除配置、Redis连接信息。MyBatis Plus的逻辑删除功能非常实用，在实体类的逻辑删除字段上加@TableLogic注解就可以实现“删除”记录时自动变成UPDATE deleted = 1，对订单和用户这类需要保留痕迹的表很关键。

一个建议：新项目一开始就统一响应结构。我定义了一个Result类，包含code、message、data三个字段，成功返回200，业务异常返回500，权限不足返回401。前后端约定好这套结构后，前端的axios拦截器就可以统一处理错误提示，不用每个接口单独写错误分支。

以下是统一返回结构的核心代码：

@Data public class Result<T> { private Integer code; private String message; private T data; public static <T> Result<T> success(T data) { Result<T> result = new Result<>(); result.setCode(200); result.setMessage("success"); result.setData(data); return result; } public static <T> Result<T> error(String message) { Result<T> result = new Result<>(); result.setCode(500); result.setMessage(message); return result; } }

3.2 登录鉴权与JWT实现

登录功能看起来简单，但它是整个系统安全性的第一道门，值得认真做。方案上选择了JWT + Redis的结合方式：用户登录成功后，后端生成一个JWT令牌返回给前端，同时把令牌写入Redis，设置过期时间。每次请求携带令牌，后端拦截器验签之后，再从Redis确认该令牌是否有效。

为什么要用JWT，而不是 session？因为前后端分离架构下，前端可能部署在另一个域名或端口，使用session需要处理跨域携带Cookie的问题，比较麻烦。JWT基于Token机制，天然支持跨域，也便于未来的移动端接入。

JWT的生成可以引入jjwt库，核心逻辑如下：

public String createToken(Long userId, String username, String role) { return Jwts.builder() .setSubject(String.valueOf(userId)) .claim("username", username) .claim("role", role) .setIssuedAt(new Date()) .setExpiration(new Date(System.currentTimeMillis() + EXPIRE_TIME)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact(); }

JWT可以做的细节优化：密钥不要硬编码在代码里，而是放到application.yml配置文件中；过期时间根据项目场景设置，后台管理系统可以设置8小时，前台商城可以设置7天，方便用户保持登录状态。另外，用户修改密码或者被管理员禁用的场景，需要让旧令牌立刻失效，这就是引入Redis的原因——在Redis记录一个黑名单或者一个版本号，拦截器里比对一下即可。

3.3 商品列表与筛选查询

商品列表是前台访问量最高的接口，这里需要支持的筛选条件包括：分类、关键词、价格区间、排序方式（默认综合排序、销量排序、价格升序降序），同时支持分页返回。

一开始我是通过一个复杂的XML SQL来实现多条件动态查询，用<if>标签拼SQL，代码可读性很差而且容易写错。后来全部改成了MyBatis Plus的LambdaQueryWrapper，代码收敛了很多，动态条件的拼装也变得更直观：

LambdaQueryWrapper<Product> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(keyword)) { wrapper.like(Product::getTitle, keyword); } if (categoryId != null) { wrapper.eq(Product::getCategoryId, categoryId); } if (minPrice != null) { wrapper.ge(Product::getSkuMinPrice, minPrice); } wrapper.eq(Product::getStatus, 1); Page<Product> page = productMapper.selectPage(new Page<>(pageNum, pageSize), wrapper);

这里有个性能细节：商品列表页如果每次查询都实时关联SKU表计算最低价，会有性能损耗。我的方案是在商品SPU表中冗余了sku_min_price和sku_max_price字段，每次SKU价格调整时同步更新SPU表的价格区间，这样列表查询只走单表查询即可。

首页的热门推荐数据还做了Redis缓存，缓存Key是home:hotProducts，过期时间设置30分钟。后台编辑商品时删除对应缓存，避免用户看到脏数据。

3.4 购物车与订单提交链路

购物车使用Redis Hash实现，核心命令如下：

HSET cart:userId skuId quantity HGETALL cart:userId HDEL cart:userId skuId

前端每次进入购物车页面时请求一次购物车详情接口，后端遍历Hash中所有的SKU ID，批量查询SKU信息和商品SPU信息，组装后返回。这里需要注意价格展示逻辑：购物车中的价格必须实时从数据库读取，不允许使用前端传入的价格，防止用户篡改请求把商品价格改掉。

订单提交是整个系统中最核心也最容易出问题的环节。我的实现思路是后端一次性接收购物车勾选的SKU ID列表、收货地址ID、用户备注，然后在事务中完成以下操作：

第1步，根据SKU ID批量查询商品信息，核对商品状态和库存是否满足购买数量；第2步，计算订单总金额，这个金额完全由后端根据数据库价格算出，前端传入的金额直接丢弃；第3步，扣减库存（使用前面提到的带条件UPDATE）；第4步，生成订单主表和订单明细表记录，订单状态置为待支付；第5步，清空购物车中已下单的商品；第6步，提交事务。

整个链路必须加上@Transactional注解，任一步骤失败则整体回滚，否则会出现库存扣了但订单没生成的严重数据不一致问题。这块是项目里技术含量最高的部分，也是面试时最容易深挖的点，务必理解事务的边界控制。

3.5 订单状态机与超时处理

订单状态我用一个整数字段表示，状态之间的流转关系如下：

• 状态0：待支付
• 状态1：待发货（已支付）
• 状态2：待收货（已发货）
• 状态3：已完成（已收货）
• 状态4：已取消（超时或用户主动取消）

用户主动取消限定了状态为待支付时才能操作。管理员发货操作限定订单必须处于待发货状态。这种状态机的约束放在了Service层处理，并没有依赖数据库的状态检查约束，通过代码逻辑进行状态流转管控，思路简单清晰，也方便日志记录操作历史。

待支付订单的超时关闭是电商系统的一个经典问题。我实现了两种方案：一种是使用Spring的@Scheduled定时任务，每30秒扫描一次超过30分钟未支付的订单，将其状态置为已取消并回补库存；另一种是在用户查询订单时顺带判断是否过期。定时任务方案存在延迟，但实现成本低，对这个项目完全够用。如果后续想做到秒级关闭，就需要引入延迟队列或者Redis的过期监听事件，那是另一个复杂度的讨论了。

4. 前端商城实现与前后端联调

4.1 前端技术栈与页面结构

前端使用Vue 3 + Vue Router + Pinia + Element Plus + Axios这套标准组合，通过Vite构建。Vue 3的组合式API（Composition API）在组织业务代码时比选项式API更灵活，尤其是购物车、订单这类涉及多个状态和方法的模块，逻辑可以按照业务维度聚合，而不是被分散在data、methods、watch各个区块中。

页面结构上，前台商城遵循“首页 -> 商品列表页 -> 商品详情页 -> 购物车 -> 结算页 -> 订单中心”这条主线。首页的视觉要求比较高，因为汉服本身是一个强视觉的品类，页面审美直接会影响用户对项目的评价。这里用了一个比较取巧的办法：用Element Plus的卡片组件结合自定义CSS实现瀑布流风格的推荐区域，图片资源统一走图片服务器的URL预览，前端代码里面不写死任何图片地址。

后台管理系统复用同一套组件库，使用侧边栏+顶栏的整体布局，菜单根据路由自动生成，配置好路由表后新增页面非常方便。

4.2 axios封装与鉴权处理

前后端分离项目里，axios需要统一封装。我的做法是在请求拦截器中从Pinia状态或者localStorage读取token，加到请求头的Authorization字段；在响应拦截器中统一处理后端返回的错误码，例如401跳转到登录页，500弹出错误提示。

// request.js const service = axios.create({ baseURL: '/api', timeout: 10000 }); service.interceptors.request.use(config => { const token = localStorage.getItem('token'); if (token) { config.headers.Authorization = `Bearer ${token}`; } return config; }); service.interceptors.response.use( response => { const res = response.data; if (res.code === 200) { return res.data; } if (res.code === 401) { router.push('/login'); return Promise.reject(new Error('登录已过期')); } ElMessage.error(res.message); return Promise.reject(new Error(res.message)); }, error => { ElMessage.error('网络请求异常'); return Promise.reject(error); } );

这里有一个容易踩的坑：前端的开发环境通常通过Vite的代理转发请求到后端，避免跨域问题。代理配置里需要将/api前缀转发到后端的http://localhost:8080，同时后端也要允许跨域的预检请求。但后端的跨域配置不能开放到所有人都能访问的成都无差别状态，需要限定来源域名。

4.3 购物车与订单确认页的交互细节

购物车页面的核心交互逻辑是要同步勾选状态、数量变化和价格计算。数据结构上，我定义了一个响应式的购物车数组，每一项包含SKU信息、数量、是否勾选三个字段。当勾选状态或者数量变化时，计算选中的商品总价，在结算栏实时更新。这里需要特别注意：商品数量不能为0而且不能超过库存上限，否则显示购买失败的提示并阻断提交。

订单确认页从购物车跳转过来，通过路由参数传递选中的SKU ID列表。页面加载时根据这些ID请求后端接口，获取实时的商品信息和价格。页面包含三个区块：收货地址选择、商品清单确认、金额明细展示。收货地址如果为空，需要引导用户先新增地址。提交订单按钮点击后，前端需要防重复提交，我在按钮上加了一个loading状态，请求结束后恢复；后端也会用Redis做幂等处理，同一用户短时间内重复提交相同的SKU列表只生成一个订单，这个细节能体现出对并发场景的思考。

5. 常见问题与排查技巧

5.1 开发联调期的经典问题集

项目做完之后，我把开发过程中遇到的典型问题整理了一张速查表，这些问题大概率也是你会遇到的：

其中分页插件不生效的问题非常隐蔽，很多新手排查半天发现是忘了加@Configuration配置类。这里是标准配置代码：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

5.2 并发场景下的几个坑

除了上面这些常规问题，有几类并发场景的问题值得单独拿出来说，因为它们不是报错能直接看到的，但会导致数据的严重错误。

第一个是超卖问题。我前面提到的带条件UPDATE就是解决方案之一。但它不是万能的，如果并发请求同时扣减同一个SKU的库存，MySQL默认的隔离级别下仍然可能出现行锁竞争导致的死锁。解决方式一个是让扣库存的SQL顺序一致，避免多个事务以不同顺序获取锁；另一个是对高并发场景引入Redis的原子操作（如DECR）做库存预扣。这个项目里扣库存操作统一在订单事务中执行，顺序一致不会有死锁问题。

第二个是购物车合并问题。用户在未登录状态下把商品加入了本地购物车，登录之后应该把本地购物车和Redis购物车做合并，数量取两个来源的和。这个逻辑如果在后端做合并时没有考虑边界，很容易出现数量覆盖。我实现的合并策略是：以Redis购物车为基准，遍历本地购物车中的SKU，如果Redis中已存在则数量累加，否则新增。

第三个是前端价格显示与后端计算不一致的问题。用户在结算页停留时间较长，后端的商品价格可能已经调整，导致前端显示的价格和后端下单价不一致。方案是在提交订单时后端重新计算价格，并以弹窗形式告诉用户最新的价格，在用户确认后才真正生成订单。这个实现有助于避免售后纠纷，也体现了一个商城系统的严谨度。

6. 从项目到面试：如何讲出亮点

项目做完只是第一步，真正让这个项目加分的是你怎么把它讲给面试官听。根据我过去两年参与技术面试的经历，关于这类商城管理系统，面试官通常不会逐行问你代码怎么写，而是围绕几个核心问题来考察你的设计思维和问题排查能力。

比较高频的问题包括：“为什么用Redis存购物车而不是MySQL？”“库存超卖你怎么解决？”“订单状态是怎么管理的？”“JWT过期了怎么办？”“如果并发量变大，你觉得系统瓶颈在哪里？”这些问题前面章节基本都覆盖了，关键是你得能把设计思路用“遇到什么问题 -> 为什么这么选 -> 有没有考虑其他方案 -> 还存在什么局限”的逻辑链条讲清楚。

举一个例子。如果面试官问“购物车为什么不用MySQL”，直接回答“Redis快”是不够的。你可以这样展开：

购物车这个场景的特点是读写比例极高、单个用户的数据量很小、数据临时性强。如果放到MySQL里，每次加购和修改数量都是一次数据库写操作，在高频操作下会产生大量行锁和磁盘I/O，而Redis基于内存，单线程模型天然避免了并发竞争，读写性能可以到每秒数万级别。另外，购物车数据即便丢了也不会对业务造成核心损失，Redis的缓存的定位正好匹配它的非关键性。当然Redis方案也有风险，比如数据持久化依赖RDB/AOF配置，所以后续可以考虑引入MySQL表来做兜底持久化和多端同步。

这种回答方式展示了你的思考链路，而不是背答案。面试官追问下去也不怕，因为每一个选型背后你都有真实的踩坑经历支撑。

另外，项目里几个“加分项”可以主动展开。比如自定义统一响应结构、使用LambdaQueryWrapper避免SQL拼接错误、通过订单号冗余设计避免遍历风险、利用Redis的复杂数据结构解决业务问题等。这些细节说明你不是在机械地调用框架，而是在主动做工程设计。

项目扩展的一些想法

这个项目目前满足“完整可用”是没问题的，但距离生产级系统还有明显的差距。如果学有余力，我认为有几个方向值得扩展：一是接入真实的第三方支付，替换掉当前的模拟支付逻辑；二是引入消息队列（比如RabbitMQ或Kafka）处理订单超时和库存回补的异步任务；三是增加秒杀场景，然后专门去优化热点SKU的库存扣减逻辑；四是对图片资源接入对象存储服务，替换掉本地上传方案。任何一个方向深入做下去，都可以作为一次技术升级的好素材，也能让这个项目从“课程设计级别”向“面试亮点级别”迈进一大步。

我个人在完成这个项目后最大的收获是明白了一件事：一个成熟的系统不是功能堆出来的，而是各种取舍平衡之后的结果。数据库要不要冗余字段、缓存选什么粒度、状态机怎么设计，每一个决策背后都要能说出理由。带着这种思路去做项目，答辩和面试都会轻松很多。