企业官网建设流程全解析

追星女孩的收纳盒里，总有一格专门装小卡、徽章和应援周边。可这个圈子的日常交易，说实话挺原始的：要么在超话发帖站内私信，要么进QQ群对暗号，再要么就是挂个链接再私聊敲细节。没有统一分类，没有成色标准，更谈不上交易担保。上半年有位学弟找我做毕设，他自己就是资深追星族，想做一套真正适合周边转卖的商城系统。我们聊了一下午需求，最后敲定这个SSM体系下的追星商城——技术上走 Spring Boot + SpringMVC + MyBatis，既保留SSM清晰的分层，又能省掉一堆繁琐的XML配置。今天就把这个项目的设计思路、核心实现和踩过的坑，完整复盘一遍。

1. 项目整体设计与技术选型

1.1 周边转卖场景到底在痛什么

一开始我有点疑惑：闲鱼不是已经能卖了吗，为什么还要单独做一个平台？学弟给我讲了半小时，我才真正理解周边交易的痛点。

周边商品的核心是小卡、专辑、徽章、应援棒、特典，还有一些手作制品。这些商品有几个共同特点：规格极度不标准，同一位明星的同一张小卡，会因为版本、印刷批次、是否带特典而价格天差地别。而且周边交易非常看重“出身”——有没有原包装、有没有购买小票、是不是初回限定、卡面有没有瑕疵，直接决定这张卡是几百还是几千。普通二手平台的信息字段根本装不下这些细节，卖家只能把情况写在一大段描述里，买家翻半天也翻不到重点。

更深一层是信任问题。周边圈子里的交易大多发生在陌生人之间，买家最怕收到假货、瑕疵品甚至直接付了款被拉黑。通用平台虽然有评价体系，但缺少“成色、凭证、签名”这种周边专属维度，评价也写不出参考价值。所以这个追星商城本质上不是做一个普通电商，而是要把周边交易的规则固化到系统里，用分类、字段、状态机和评价体系，把原来模糊的线下交易，变成清晰的线上行为。

1.2 技术栈：SSM和Spring Boot怎么选

标题里写了“SSM springboot”，说明项目本质还是SSM三层架构，不过落地方式可以灵活选。

传统SSM是 Spring + SpringMVC + MyBatis 手写整合，需要自己配置 Spring 容器、SpringMVC 容器、MyBatis 的 SqlSessionFactory、Mapper 扫描、事务管理器，光把这些配置弄对就能劝退一批新手。Spring Boot 则把这些自动装配掉了，项目结构依然是 Controller-Service-Mapper 三层，但不再需要写那堆 XML，启动也方便，非常适合课程设计和毕业设计这种周期短、要求快的场景。

我最终选择的方案是Spring Boot 2.7 + MyBatis + MySQL 8 + Druid 连接池 + PageHelper 分页 + Bootstrap 前端。如果你所在学校硬性要求提交传统 SSM 工程，本质上只要把 Spring Boot 的部分换成 spring-webmvc 和 mybatis-spring 依赖，其他业务代码完全可以复用。

pom.xml 里的核心依赖大概是这样：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.mybatis.spring.boot</groupId> <artifactId>mybatis-spring-boot-starter</artifactId> <version>2.3.1</version> </dependency> <dependency> <groupId>mysql</groupId> <artifactId>mysql-connector-java</artifactId> <scope>runtime</scope> </dependency> <dependency> <groupId>com.github.pagehelper</groupId> <artifactId>pagehelper-spring-boot-starter</artifactId> <version>1.4.7</version> </dependency> <dependency> <groupId>com.alibaba</groupId> <artifactId>druid-spring-boot-starter</artifactId> <version>1.2.20</version> </dependency>

这些版本我实测能跑通，不是乱写。 具体用哪个版本，留意一下 JDK 版本， JDK 8 用 Spring Boot 2.7 完全没问题，JDK 17 的话建议把 Spring Boot 升到 2.7.18 以上。

1.3 功能模块怎么拆

从业务上，我把系统拆成前台商城和后台管理两大块。前台面向买家和卖家，包括用户注册登录、商品浏览与搜索、商品详情、购物车、下单支付、订单管理、个人中心、评价模块；后台面向管理员，包括商品审核、商品分类管理、用户管理、订单管理、数据统计。

为什么要单独做一个商品审核模块？一开始学弟觉得没必要，但我坚持加了。因为周边交易假货和纠纷太多，如果所有商品发布出来就立即上架，平台很快就变成骗子聚集地。管理员在后台审核通过后商品才会在前台展示，这个设计在答辩时也是加分项。

首页考虑到大家的使用习惯，我没有做成简单的商品列表，而是加了分类导航、热门推荐、最新发布和销量排行几个区块。分类导航按“明星团体”二级分类走，比如某个组合下的成员、专辑、小卡、应援物，这样用户进首页能快速定位到自己追的圈子，而不是像闲鱼那样全靠搜索。

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

2.1 用户表与三种角色

先建用户表，我用了单表加 role 字段的方案，而不是分成买家表、卖家表、管理员表。小项目拆太细只会增加关联复杂度，一个 user 表存三类角色，靠 role 区分，管理员也可以通过后台把普通用户角色置为卖家，非常方便。

CREATE TABLE `user` ( `id` int NOT NULL AUTO_INCREMENT, `username` varchar(50) NOT NULL, `password` varchar(128) NOT NULL, `nickname` varchar(30) DEFAULT NULL, `avatar` varchar(255) DEFAULT NULL, `phone` varchar(20) DEFAULT NULL, `role` tinyint NOT NULL DEFAULT '0' COMMENT '0买家 1卖家 2管理员', `status` tinyint NOT NULL DEFAULT '1' COMMENT '1正常 0禁言/禁用', `created_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

密码字段我建议给到 varchar(128)，因为加密后的字符串比较长。如果你用 BCrypt，存储长度至少 60 位，MD5 加盐也需要预留足够空间。用户头像直接存相对路径，不用存 base64。

角色设计有一个坑：前端页面很多地方要区分“买家视角”和“卖家视角”。比如同一个人既可以是买家也可以是卖家，下单时他是买家，发布商品时他是卖家。我的方案是在 user 表上就存一个 role，如果 role=1 表示他是卖家，同时他也拥有买家功能。如果需要更复杂的身份，可以另建 seller 申请表，但当前这个项目的规模，role 字段足够了。

2.2 商品表：把“周边味”做出来

商品表是整个系统的核心，也是最能体现“追星商城”不同于普通二手平台的地方。我在标准商品字段之外，特意加了一批周边交易专属字段。

CREATE TABLE `goods` ( `id` int NOT NULL AUTO_INCREMENT, `seller_id` int NOT NULL, `category_id` int DEFAULT NULL, `title` varchar(100) NOT NULL, `description` text, `price` decimal(10,2) NOT NULL, `original_price` decimal(10,2) DEFAULT NULL, `cover_image` varchar(255) DEFAULT NULL, `images` varchar(1000) DEFAULT NULL, `goods_condition` varchar(20) DEFAULT NULL COMMENT '全新/近全新/轻微使用/明显瑕疵', `is_signature` tinyint DEFAULT '0' COMMENT '是否带签名', `has_proof` tinyint DEFAULT '0' COMMENT '是否有购买凭证', `version_info` varchar(50) DEFAULT NULL COMMENT '普通版/初回限定/特典版', `stock` int DEFAULT '1', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待审核 1上架 2下架 3拒绝', `view_count` int DEFAULT '0', `created_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_seller` (`seller_id`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

为什么要单独设计 goods_condition（成色）？周边圈子里，一张小卡是全新未拆还是仅对光看过，价格能差出一倍。成色不是一个可以用普通文本描述的属性，必须有固定枚举值，这样用户搜索筛选时才能直接按成色过滤。

is_signature 和 has_proof 是我和学弟反复讨论后确定的两个关键字段。签名版周边有很高的溢价，有没有签名直接决定这张卡是不是“贵卡”；购买凭证则是证明正品最重要的依据，很多资深买家只收带凭证的。这两个字段在普通二手平台上都没有，却是周边交易的核心信任锚点。

images 字段我用逗号拼接的方式存多张图片路径，首图单独存到 cover_image。这种方式简单直接，查询时按逗号 split 就能拿到图集。如果图片量大可以改成关联表，但当前阶段没必要。

2.3 订单表与交易状态机

订单表设计时，我特意把卖家和买家的 ID 都冗余进来，而不是只存商品 ID 再反查。理由很简单：订单列表页需要频繁展示买卖双方信息，如果只存商品 ID，每次都要 join 一次商品表再 join 一次用户表，SQL 写起来啰嗦，也容易出现性能问题。冗余 seller_id 之后，卖家在个人中心查“我卖出的订单”就是一条简单的等值查询。

CREATE TABLE `orders` ( `id` int NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL, `user_id` int NOT NULL, `seller_id` int NOT NULL, `goods_id` int NOT NULL, `goods_title` varchar(100) DEFAULT NULL, `goods_image` varchar(255) DEFAULT NULL, `price` decimal(10,2) NOT NULL, `quantity` int DEFAULT '1', `amount` decimal(10,2) NOT NULL, `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待支付 1待发货 2待收货 3已完成 4已取消 5退款中', `receiver_name` varchar(30) DEFAULT NULL, `receiver_phone` varchar(20) DEFAULT NULL, `receiver_address` varchar(255) DEFAULT NULL, `remark` varchar(255) DEFAULT NULL, `pay_time` datetime DEFAULT NULL, `ship_time` datetime DEFAULT NULL, `finish_time` datetime DEFAULT NULL, `created_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user` (`user_id`), KEY `idx_seller` (`seller_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单状态机是这个项目的核心业务规则，我按电商主流流程设计：用户下单创建订单，此时状态是 0 待支付；调用模拟支付接口后状态变为 1 待发货；卖家在“我卖出的订单”里点击发货，状态变为 2 待收货；买家点击确认收货，状态变为 3 已完成。另外还有两个边界状态：4 已取消，对应买家支付前取消订单；5 退款中，对应收货后申请退款。

状态流转一定要在代码里校验，不能想怎么改就怎么改。比如一笔状态为 1 待发货的订单，买家不能直接改成已完成。我在 OrderService 里写了一个状态流转校验方法，每次更新状态前先查旧状态，只在允许的状态转移表里放行。这个设计能挡掉很多手滑或者接口被刷的问题。

2.4 购物车与评价表设计

购物车表比较常规，核心是一个唯一键：同一用户加同一商品，重复添加时购买数量加一，而不是插两条脏数据。

CREATE TABLE `cart` ( `id` int NOT NULL AUTO_INCREMENT, `user_id` int NOT NULL, `goods_id` int NOT NULL, `quantity` int DEFAULT '1', `created_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_goods` (`user_id`,`goods_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

评价表关联三个对象：评价人、订单、商品。评价内容包括星级评分和文字内容，后面还可以扩展追评，但当前版本先不做。评价的核心意义不仅仅是晒单，而是给后续买家提供真实参考。我在商品详情页做了“大家都在说”区块，展示该商品所有历史评价，配合成色、签名这些属性字段，整个信任链就闭合了。

CREATE TABLE `comment` ( `id` int NOT NULL AUTO_INCREMENT, `order_id` int NOT NULL, `user_id` int NOT NULL, `goods_id` int NOT NULL, `score` tinyint DEFAULT '5', `content` varchar(500) DEFAULT NULL, `created_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_goods` (`goods_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

3. 核心功能实现与实操要点

3.1 登录注册与权限拦截

密码加密我直接用了 BCrypt。 很多教程还在用 MD5，但 MD5 在暴力破解面前基本等于裸奔，BCrypt 每次加密会随机加盐，同样密码每次密文都不同，安全性和成本都在可接受范围。

管理系统我选择了 Session 方案，Spring Boot 内嵌 Tomcat 自带 HttpSession，简单直接。拦截器只处理登录状态和角色权限，不碰业务。

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { Object loginUser = request.getSession().getAttribute("loginUser"); if (loginUser == null) { // 判断是否为ajax请求 String xr = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(xr)) { response.setContentType("application/json;charset=utf-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录\"}"); } else { response.sendRedirect("/login"); } return false; } return true; } }

注册拦截器时要注意放行规则：登录页、注册页、静态资源、商品列表和商品详情这些公开页面必须放行，否则游客连首页都看不到。管理员的接口和页面单独用一套 AdminInterceptor，校验登录用户 role 是否等于 2。

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(new LoginInterceptor()) .addPathPatterns("/**") .excludePathPatterns("/login", "/register", "/css/**", "/js/**", "/images/**", "/upload/**", "/", "/index", "/goods/list", "/goods/detail/**", "/category/**"); registry.addInterceptor(new AdminInterceptor()) .addPathPatterns("/admin/**"); } }

这里有一个很典型的坑：很多同学会把静态资源也拦截，导致页面样式全丢。记住要 exclude 掉 css、js、images 和上传目录。如果是 Spring Security，这些属于 permitAll 的范畴，原理是一样的。

3.2 图片上传与访问映射

周边交易特别依赖实物图，所以图片上传是刚需。我做了单图上传和多图上传两套，单图用于用户头像和商品封面，多图用于商品详情图集。

先说上传路径。开发环境我在 application.yml 里配置了一个变量：

upload: path: D:/projects/fan-mall/upload/

项目运行时用 UUID 重命名文件，避免文件名冲突和中文乱码。然后把 upload 目录映射成虚拟路径 /upload/**，前端直接用相对路径访问图片。

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

注意一个细节：生产环境换成 Linux 时，上传路径一定要改成绝对路径，比如/data/fan-mall/upload/，不要把 Windows 的盘符路径写死在代码里。我习惯把路径放到配置文件，不同环境切换 yml 即可。

上传工具方法的实现很常规，但有几个细节必须注意：文件名后缀用原始文件名的后缀，避免图片格式丢失；上传目录不存在时要先创建；对文件大小做限制，Spring Boot 默认单文件 1MB，我在配置里调到了 5MB。

public String uploadFile(MultipartFile file, String path) { if (file == null || file.isEmpty()) { throw new RuntimeException("文件为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String newName = UUID.randomUUID().toString().replace("-", "") + ext; File dir = new File(path); if (!dir.exists()) { dir.mkdirs(); } File target = new File(dir, newName); try { file.transferTo(target); } catch (IOException e) { throw new RuntimeException("文件上传失败", e); } return "/upload/" + newName; }

3.3 商品发布与多图处理

商品发布页我设计成两部分：基本信息区填标题、分类、价格、成色、版本等，图片区专门传封面和详情图。

Controller 接收 MultipartFile 数组，第一张图作为封面，所有图片拼接存储到 images 字段。

@PostMapping("/goods/publish") public String publish(Goods goods, @RequestParam("files") MultipartFile[] files, HttpSession session) { User seller = (User) session.getAttribute("loginUser"); goods.setSellerId(seller.getId()); if (files != null && files.length > 0) { StringBuffer sb = new StringBuffer(); for (int i = 0; i < files.length; i++) { if (files[i] != null && !files[i].isEmpty()) { String url = uploadFile(files[i], uploadPath); if (i == 0) { goods.setCoverImage(url); } sb.append(url).append(","); } } goods.setImages(sb.toString()); } goods.setStatus(0); goods.setViewCount(0); goodsService.addGoods(goods); return "redirect:/my/goods"; }

商品发布之后进入审核状态，管理员在后台审核通过，商品才会在前台展示。这里有一个体验优化点：发布成功后跳转到“我的发布”页面，这个页面用列表展示当前卖家所有商品及审核状态，让卖家明确知道商品处于什么环节，不会以为发布失败。

3.4 购物车与下单流程

购物车核心逻辑就是前面表设计提到的唯一键。加入购物车的 Service 方法先按 user_id 和 goods_id 查记录，存在就 update 数量，不存在就 insert。

下单流程是整个系统最需要严谨对待的地方，我用了事务和状态双重校验。核心逻辑在 OrderService 的 createOrder 方法里：

@Transactional(rollbackFor = Exception.class) public Long createOrder(Order order, Long userId) { Goods goods = goodsMapper.selectById(order.getGoodsId()); if (goods == null) { throw new BizException("商品不存在"); } if (goods.getStatus() != 1) { throw new BizException("商品已下架或未审核"); } if (goods.getStock() <= 0) { throw new BizException("商品已售罄"); } order.setUserId(userId); order.setSellerId(goods.getSellerId()); order.setGoodsTitle(goods.getTitle()); order.setGoodsImage(goods.getCoverImage()); order.setAmount(goods.getPrice().multiply(new BigDecimal(order.getQuantity()))); order.setOrderNo(generateOrderNo()); order.setStatus(0); orderMapper.insert(order); int rows = goodsMapper.reduceStock(goods.getId()); if (rows == 0) { throw new BizException("库存扣减失败，请重试"); } return order.getId(); }

这里有两个容易踩的坑。第一个是事务必须加 rollbackFor = Exception.class，否则运行时异常虽然默认回滚，但某些自定义异常可能不被 Spring 识别为回滚条件，导致库存扣了订单没建。第二个是库存扣减用了原子 SQL：UPDATE goods SET stock = stock - 1 WHERE id = ? AND stock > 0，而不是先查再改。先查再改在高并发下会出现超卖，虽然毕设项目并发量不大，但好习惯要养成。

生成订单号我这里用的是时间戳加随机数：

private String generateOrderNo() { SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss"); String time = sdf.format(new Date()); String random = String.valueOf((int) ((Math.random() * 9 + 1) * 1000)); return time + random; }

正式商城会用雪花算法，但当前规模这个完全够用，答辩时能讲清楚生成逻辑即可。

3.5 订单状态流转与评价闭环

订单创建后，买家进入“我的订单”列表，点击“去支付”，模拟支付接口只做一件事：把订单状态从 0 改成 1，并记录支付时间。真实项目要对接微信或者支付宝沙箱，这里为了演示方便做了模拟。

卖家发货是在“我卖出的订单”里操作，需要填写物流单号，但我简化成仅记录发货时间并变更状态为 2。买家确认收货后状态变为 3，同时弹出评价入口。评价接口会校验订单确实属于当前用户且状态为 3，防止有人乱刷评价。

一个我在实际开发中处理的细节：买家取消订单和卖家发货之间要有一个时间窗口保护。如果订单待支付超过 30 分钟，系统自动取消并返还库存，这个我用 Spring 的 @Scheduled 定时任务实现，每分钟扫一次待支付超时订单。这个功能能讲出深度，建议保留。

4. 常见问题与踩坑记录

4.1 分页插件 PageHelper 的诡异问题

PageHelper 是分页神器，但也最容易出问题。最常见的是分页查询返回的 List 总条数不对，或者第二页数据跟第一页完全一样。原因基本是两个：一是分页插件拦截了两次查询，二是没有配置 reasonable 参数。解决方法是加上这个配置：

pagehelper: reasonable: true support-methods-arguments: true

reasonable 的作用是当页码超出总页数时，自动修正为最后一页或第一页。另外要注意 PageHelper.startPage() 必须紧跟第一条查询语句，中间不能插入其他 SQL 操作，否则分页会作用到错误的查询上。

4.2 前端时间显示成一串数字

后端返回 Date 类型给前端，如果没有处理，JSON 序列化出来是毫秒时间戳。我第一次联调就遇到这个问题，整个页面全是 1718开头的数字，看起来非常不专业。

解决办法有两个：一是在实体类的日期字段上加注解：

@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8") private Date createdTime;

二是在 application.yml 里配置全局时间格式：

spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8

建议两种都加，实体注解优先于全局配置。

4.3 数据库连接乱码与时区问题

MySQL 8 连接时有两个必坑点：乱码和时区错误。database URL 配置必须写完整：

jdbc:mysql://localhost:3306/fan_mall?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

建表时统一用 utf8mb4 而不是 utf8，因为 utf8mb4 才能完整支持四字节字符，比如 emoji 和部分生僻字。数据库连接和建表字符集统一后，基本不会出现插入数据变成问号的问题。

另一个容易忽略的是项目本身编码。IDEA 里统一把文件编码设置为 UTF-8，编译器也设置成 UTF-8，否则会出现本地正常部署乱码的诡异问题。

4.4 图片上传到服务器的路径问题

我在本地测试一切正常，部署到 Linux 服务器后图片全挂。排查了半天，发现是上传路径写的是D:/projects/fan-mall/upload/，在 Linux 上根本没有 D 盘。修改配置为/data/fan-mall/upload/后正常。

这个问题建议大家从一开始就把上传路径外部化到配置文件，并且不要在代码里写死。数据库里存的是访问相对路径/upload/xxx.jpg，磁盘上存的是配置的绝对路径，两者通过静态资源映射关联。如果前端用 Nginx，可以再把/upload/直接指向磁盘目录，连应用层映射都省了。

4.5 扫描Controller却报找不到Service

这个问题在纯 SSM 配置环境很常见：SpringMVC 的容器扫描了@Service，Spring 容器也扫描了@Service，导致 Service 被实例化两次，事务注解经常不生效。解决办法是明确划分扫描范围：spring 配置文件只扫 service 和 dao，springmvc 配置文件只扫 controller。

在 Spring Boot 里这个问题几乎没有，因为整个应用共用一个容器。但如果你是照着传统 SSM 教程改的，就要格外小心。还有一个类似的坑：MyBatis 的 Mapper 接口没有加@Mapper注解，导致启动时报找不到 Bean。我的习惯是在启动类上加@MapperScan("com.xxx.mapper")，一劳永逸。

4.6 模拟支付接口被重复请求

支付操作是幂等性问题。如果用户手点两次支付，就会重复更新状态，虽然代码里加了状态校验，第二次会把“状态已是待发货”当成正常处理返回成功，看起来没问题，但逻辑上不严谨。

我在 OrderService 的 updateStatus 方法里加入状态机校验后，这样重复支付时第二次会被拒绝。看起来只是一个小细节，但能保证整个系统状态的一致性，也比单纯 if-else 判断更加规范。

5. 项目扩展方向

做完这个项目之后，我感觉还有几个方向值得继续深入。第一个是接入真实支付，支付宝和微信都有沙箱环境，替换掉模拟支付接口并不复杂，还能把对账流程一并做出来。第二个是增加私信聊天功能，周边交易里买卖双方有大量沟通需求，砍价、看细节图、确认发出方式，内置聊天能让平台更有社区感。第三个是做成小程序端，小程序的传播属性比 Web 端强得多，追星群体非常依赖社群分享。

除了这些，后台数据统计也是一个可以深挖的点。我现在只做了简单的订单量和营业额统计，用 ECharts 画折线图展示近七天趋势。后续想做得专业一点，可以加入商品热度分析、用户增长统计、卖家信用评分体系，这些都是数据可视化和数据分析课程的天然素材。

这个项目做完一遍，我最大的体会是：垂直领域的电商系统，关键不是技术栈多新多炫，而是有没有把用户真正在意的规则做进系统里。周边转卖这件事，成色、凭证、签名、交易流程，这些细节才是用户信任的基础。如果看到这篇文章的你也准备做类似项目，我建议先从数据库表设计入手，把业务里专属的字段想清楚，后面的开发会顺畅很多。