企业官网建设流程全解析

先说个真实的事。我一朋友在热门手游里卖账号，帖子挂出去不到半小时就有人加QQ，对方发了个看起来跟闲鱼一模一样的链接，他一点没怀疑，付款之后人就消失了。游戏虚拟物品交易最大的问题从来不是缺买家和卖家，而是缺信任机制。我后来做的这套“基于SpringBoot + Vue的游戏交易系统”，说白了就是把“信任”两个字做成产品：买家敢付钱、卖家敢交货、平台能在中间安全地抽成。

这套系统用Java全栈里最主流的两套框架——后端SpringBoot、前端Vue，做游戏币、账号、皮肤、道具这类虚拟商品的担保交易。它要解决三个核心问题：买家的钱怎么不被骗，卖家的货怎么不被白拿，平台的手续费怎么稳定落袋。这三个问题会贯穿整个系统的表结构设计、订单状态机设计和前后端交互设计。如果你正在写类似的毕设、小组项目，或者打算自己搭一个小型交易平台，这篇文章可以帮你绕开我踩过的坑。

1. 先想清楚：游戏交易系统到底在“交易”什么

1.1 三种业务模式，决定系统复杂度天花板

游戏交易不是把淘宝搬家到游戏里就完事。虚拟商品有几个让平台头疼的特性：交付不可逆（账号密码一旦给出去就很难召回）、价值波动快（一件皮肤今天值三百，下周可能白送都没人理）、真实交割发生在游戏内（平台无法像实物电商那样控制快递物流）。

因此市面上的游戏交易平台，核心模式基本就三种：

1. 寄售模式：卖家把货先交给平台托管。游戏币可以直接交易给平台在游戏里的收货角色，账号类商品甚至要改绑到平台邮箱，买家下单付款后系统自动发货。优点是全自动、体验好，缺点是平台必须有能力在对应游戏里建仓收货，很多游戏和品类做不了。
2. 担保模式：买卖双方都信平台，买家把钱付给平台，卖家在游戏内把货交给买家，买家确认收货后平台再打款给卖家。优点是不挑游戏、几乎全品类覆盖，缺点是订单状态复杂，必然需要客服介入处理纠纷。
3. 求购模式：买家挂出自己想买的商品和预算，卖家看到后决定是否接单。这是前两种模式的补充，能明显提高冷门商品的成交率，但需要注意押金防骚扰。

我做的系统选了“担保为主，寄售少量支持”的混合方案。理由很直接：在毕设/团队项目阶段，我们没有能力在几十款游戏里都搞收货仓库，担保交易只需要平台把订单和资金管好，不需要碰游戏内部机制。如果你打算全做寄售，请先确认自己能搞定游戏侧的自动化发货接口。

1.2 从下单到打款：担保交易的核心链路

担保交易的完整链路，我梳理为八步：

1. 卖家发布商品，填写游戏区服、商品类型、标题、图文详情、价格、库存
2. 管理员审核通过，商品上架
3. 买家浏览、搜索、下单
4. 买家付款到平台（真实场景走第三方支付，演示项目可模拟支付）
5. 平台通知卖家发货（站内信+卖家中心待办）
6. 卖家上传发货凭证或联系买家完成游戏内交割
7. 买家确认收货
8. 平台扣除手续费后，将剩余款项打入卖家账户

这里面有六类角色：游客、买家、卖家、审核员、客服（处理申诉）、超级管理员。第4步和第8步是资金安全的关键，第5到第7步是订单状态机的核心，系统设计时这两部分要投入最多的精力。

2. SpringBoot + Vue为什么是这套组合，而不是别的

2.1 后端选型：SpringBoot + MyBatis-Plus的理由

很多教程喜欢把后端做成SSM（Spring + SpringMVC + MyBatis）手写配置，但我个人强烈建议直接用SpringBoot。它解决了自动配置和起步依赖的问题，内嵌Tomcat，打一个jar包就能跑。交易系统这类业务逻辑偏重的项目，最浪费时间的就是环境配置和对象映射，SpringBoot的starter机制把这些琐事砍掉了一大半。

持久层我选了MyBatis-Plus，理由跟交易系统的SQL特点有关：商品列表要按分类、价格区间、关键词、区服等多条件动态过滤，订单查询要按状态、时间、买家/卖家维度组合查，这些场景用MyBatis-Plus的LambdaQueryWrapper写起来非常顺手。真正复杂的统计SQL再手写XML，也不妨碍。

为什么不直接上微服务？一句话：单体足够，就绝不上微服务。课程设计或小团队项目里，拆服务带来的分布事务问题、服务通信成本，远大于收益。先把单体做扎实，才是健康的演进路径。

2.2 前端选型：Vue3 + Vite + Pinia全家桶

前后端分离已经是主流，Vue作为前端框架的市场占有率也一直很高。如果现在从0开始，我不建议再去学Vue2那套旧体系，直接上Vue3配合Vite构建工具、Pinia做状态管理，理由很简单：Vue3的组合式API（Composition API）对交易系统这种多页面、多组件复用的项目非常合适。

实际开发中你会发现，商品卡片这个组件在首页、搜索列表页、推荐位、收藏页都会出现。Vue3的组合式函数（Composables）可以把商品卡片的状态和操作逻辑抽成独立文件，多个页面引用同一个逻辑函数，比Vue2的mixin清晰得多。结合Element Plus组件库，后台管理页面很快就能搭起来。

2.3 中间件与辅助组件清单

除了数据库MySQL，我引入了Redis做三件事：登录令牌黑名单、热点商品缓存、下单防重复提交。图片存储用本地磁盘加静态资源映射，没有上OSS，因为项目阶段没必要引入额外成本。整个技术栈清单如下：

这套组合还有一个额外的好处：招人或查资料方便。SpringBoot和Vue的社区活跃度都很高，遇到问题基本都能搜到现成答案，对项目推进效率影响巨大。

3. 数据库建模：交易流水比商品信息更值得认真设计

3.1 八张核心表，从用户到资金流水

游戏交易系统的表结构可以分成三层：用户层、商品层、交易资金层。我最终沉淀了八张核心表：

• user（用户表）：id、用户名、密码（BCrypt加密）、手机号、头像、余额、状态、注册时间
• game_category（游戏分类表）：游戏名、图标、排序、状态
• goods（商品表）：卖家id、分类id、标题、描述、价格、库存、封面图、轮播图、状态、销量、浏览数
• orders（订单表）：订单号、商品id、卖家id、买家id、商品快照、成交价、手续费、状态、支付时间、发货时间、收货时间
• order_logs（订单状态日志表）：订单id、操作前状态、操作后状态、操作人、备注
• wallet（钱包表）：用户id、可用余额、冻结余额、累计充值、累计提现
• trade_record（资金流水表）：用户id、订单id、变动金额、变动类型（充值/支付/收款/退款/手续费/提现）、余额快照
• appeal（申诉表）：订单id、申诉人、申诉类型、描述、证据图、客服处理结果

这套设计的核心思路是：任何用户余额变动都必须对应一条trade_record，任何订单状态变更都必须对应一条order_logs。这样出了问题可以完整追溯，而不是对着数据库里被改过的金额发呆。

3.2 订单状态机：订单表里最关键的一个字段

订单表里最重要的不是价格，而是status字段。担保交易至少需要这些状态：

别小看这张表，实际开发中最容易出Bug的地方就是状态流转没控制好，比如买家在已完成后还能点“取消订单”，或者卖家在待付款状态就看到了买家的联系方式。我的做法是：在前端只显示当前状态允许的操作按钮，在后端用状态机校验每个动作的合法性，两层都堵，才敢说这单不会乱。

3.3 索引、唯一约束与金额字段的坑

三个经验教训：

1. 订单号必须唯一索引：用时间戳+用户id+随机数的方案生成订单号，在高并发下可能碰撞，我用了Redis incr生成自增序列拼进去，彻底解决。
2. 金额字段用Decimal，绝不用float/double：钱的计算误差在交易系统里是不可接受的。Java侧用BigDecimal，MySQL侧用DECIMAL(10,2)。
3. goods表里的price和orders表里的成交价要做快照：商品价格会变，下单后订单里必须存一份下单时的价格快照，否则后续改价会引发纠纷。

4. 后端核心实现：登录、下单、支付回调一条龙

4.1 JWT登录态与axios的配合

登录接口返回两个值：token和用户基本信息。前端把token存到localStorage，axios的请求拦截器自动加Authorization: Bearer <token>头。后端用一个拦截器统一校验：

@Component public class JwtInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String auth = request.getHeader("Authorization"); if (StringUtils.isBlank(auth) || !auth.startsWith("Bearer ")) { throw new BusinessException(401, "未登录或登录已过期"); } // 解析token，内部会校验签名和过期时间 Integer userId = JwtUtil.parseToken(auth.substring(7)); // 将用户id放入ThreadLocal，后续业务直接取 UserContext.set(userId); return true; } }

这里有三个容易被忽略的点：登出时要让token失效（我把token的jti存入Redis黑名单，拦截器里先查黑名单再验签）；token有效期建议设短一些（比如2小时），配合前端路由守卫在页面刷新时自动校验；管理员的token里要加角色字段，权限拦截器单独判断。

4.2 商品发布与审核状态流转

商品表的status字段我设计了四态：1待审核、2在售、3下架（违规）、4已售罄。卖家发布商品后状态默认1，管理员在后台审核通过后变为2。这里有个容易忽略的问题：审核通过时如果库存为0，应该直接置为4售罄，而不是2在售，否则会出现一个“在售但无法购买”的矛盾状态。

卖家下架自己商品的逻辑同理：下架之前要检查有没有未完成的订单，如果有待发货订单，必须先处理完订单再允许下架，否则买家付款后卖家把商品删了，资金就悬空了。

4.3 下单核心逻辑与防超卖的SQL

下单是并发风险最高的操作。最初始的写法是先查库存再UPDATE，这种写法在并发下必然超卖。正确做法是用一条原子SQL完成库存扣减：

UPDATE goods SET stock = stock - 1 WHERE id = #{goodsId} AND stock > 0 AND status IN (2, 4)

MyBatis受影响行数大于0才说明扣减成功，否则直接抛出“库存不足或商品已下架”。这套基于行锁的方案简单可靠，不用引入分布式锁。实际项目中我的下单Service逻辑是这样组织的：

@Transactional(rollbackFor = Exception.class) public Long createOrder(Long userId, Long goodsId) { // 1. 原子扣减库存 int rows = goodsMapper.reduceStock(goodsId, 1); if (rows == 0) { throw new BusinessException("商品库存不足或已下架"); } // 2. 查询商品信息，生成订单快照 Goods goods = goodsMapper.selectById(goodsId); Order order = Order.builder() .orderNo(generateOrderNo()) .goodsId(goodsId) .sellerId(goods.getSellerId()) .buyerId(userId) .price(goods.getPrice()) .status(1) .build(); orderMapper.insert(order); // 3. 记录订单日志 orderLogMapper.insert(new OrderLog(order.getId(), 0, 1, userId, "创建订单")); return order.getId(); }

4.4 支付回调幂等与订单对账

如果接真实第三方支付，回调接口必须做三件事：验签、判幂等、更新状态。我项目里提供了模拟支付接口，但代码结构是按真实支付设计的。核心点在于“幂等处理”：

支付回调第一次进来时，订单状态从1（待付款）变成2（已支付待发货）。第二次重复回调时，订单状态已经是2，不能再往状态日志里插一次“支付成功”。我的做法是加一个乐观锁更新：

UPDATE orders SET status = 2, pay_time = NOW() WHERE id = #{orderId} AND status = 1

影响行数为0就说明订单状态已经变更过，直接返回成功，不会重复处理。每天再写一个定时任务对账，把所有支付成功但订单未更新的订单捞出来重新核对，双保险处理掉漏单问题。

5. 前端页面链路：从商品浏览到订单操作

5.1 初始化项目与路由设计

用Vite创建项目的命令很简单：

npm create vite@latest game-trade-web -- --template vue

安装依赖后，我按页面模块规划路由，使用了Vue Router的懒加载，避免首屏一次性加载全部页面：

const routes = [ { path: '/', component: () => import('@/views/home/Home.vue') }, { path: '/goods/:id', component: () => import('@/views/goods/GoodsDetail.vue') }, { path: '/publish', component: () => import('@/views/goods/PublishGoods.vue'), meta: { requiresAuth: true } }, { path: '/orders', component: () => import('@/views/order/OrderCenter.vue'), meta: { requiresAuth: true } }, { path: '/login', component: () => import('@/views/user/Login.vue') }, ];

路由守卫统一处理登录态：访问需要登录的页面时，如果localStorage没有token就跳登录页；后端接口返回401时，前端清除本地登录信息并回到首页。

5.2 商品列表页与详情页的组件复用

商品卡片我抽成一个GoodsCard.vue组件，首页推荐、列表页、搜索结果页全都复用它。组件内部显示商品图、标题、价格、销量，点击跳到详情页。这样改动一个样式，全站商品展示同步更新。

详情页做三件事：展示商品轮播图，显示卖家信息和商品描述，判断登录状态后显示下单或咨询按钮。这里有个小细节：商品详情数据要用props从路由参数拉取，不要在组件里直接sessionStorage.setItem搞全局垃圾，容易造成数据不同步。

5.3 下单流程与订单中心的前端交互

下单按钮点击后，前端调用创建订单接口，拿到订单id后跳转到收银台页面。收银台展示订单金额和支付方式，点击支付调用支付接口。模拟支付直接成功，真实支付则需要唤起支付二维码或跳转支付页面。

订单中心分为“我买到的”和“我卖出的”两个Tab，每条订单展示订单号、商品缩略图、价格、状态和操作按钮。前端按订单状态渲染按钮：

• 待付款：显示“去支付”和“取消订单”
• 待发货：买家显示“等待卖家发货”，卖家显示“去发货”
• 待收货：买家显示“确认收货”和“申请退款”，卖家显示“查看发货信息”
• 已完成：显示“查看评价”或“申请售后”

这个按钮渲染逻辑单独抽成一个函数，不散落在模板里，代码可读性好很多。

5.4 后台管理页面的表格化设计

后台管理系统我用Element Plus的el-table配合el-dialog实现。用户管理、商品审核、订单管理、申诉管理四个模块结构类似：顶部筛选区、中间表格、底部翻页。

商品审核页核心操作是“通过”和“拒绝”。通过调用上架接口，拒绝要填写理由并同步通知卖家。申诉详情页做成时间线形式，把订单日志和申诉记录按时间排列，客服一眼就能看出问题出在哪个环节。

6. 开发过程中真实踩过的坑与处理方式

6.1 超卖问题：从判断库存到原子扣减

第一次测并发时，我用JMeter模拟50个用户同时抢购一个库存只有10的商品，下单成功记录居然有30多条。原因典型的不能再典型：先SELECT stock再UPDATE stock，并发请求全查到了旧库存，依次更新时后面的请求照样成功。

把扣库存改成一条原子SQL后，请求数量压到100仍然只有10条成功。核心理解：数据库的行锁比应用层的代码判断可靠得多，UPDATE ... WHERE stock > 0这一步自带“判断+扣减”的事务语义。如果以后要支撑更大并发，再考虑Redis加Lua脚本预扣库存的方案，但单体项目完全没必要一开始就上。

6.2 跨域、自定义Header与Token丢失

前后端分离项目第一个绕不开的问题是跨域。后端配置CORS时，很多人只配置了allowedOrigins，忘了allowedHeaders里加上Authorization，导致前端每次请求都带上了token但后端根本收不到。正确配置：

registry.addMapping("/**") .allowedOriginPatterns("*") .allowedMethods("GET", "POST", "PUT", "DELETE", "OPTIONS") .allowedHeaders("*") .maxAge(3600);

另外预检请求（OPTIONS）不能被拦截器拦截，否则前端调接口时会拿不到数据。处理方式是在拦截器里加一行判断：if ("OPTIONS".equals(request.getMethod())) return true;

6.3 图片上传大小限制与静态资源映射

上传商品图片时报错“FileSizeLimitExceededException”是最常见的问题。SpringBoot默认单文件1MB，商品图往往超了。我调整到5MB：

spring.servlet.multipart.max-file-size=5MB spring.servlet.multipart.max-request-size=20MB

更隐蔽的问题是图片上传到本地磁盘后，浏览器访问不到。需要配置静态资源映射，把磁盘目录映射成URL路径：

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

上传时我用UUID重命名文件，防止中文文件名乱码和路径穿越问题。图片稍多后建议前端做懒加载，用loading="lazy"配合缩略图，能明显减少首屏流量。

7. 部署上线、性能优化与后续演进

7.1 Maven打包与Nginx前后端部署

后端打包用Maven：

mvn clean package -DskipTests

打出的jar在target目录，用nohup java -jar game-trade-server.jar &后台启动。前端打包：

npm run build

生成dist目录，交给Nginx托管。关键是Vue Router用history模式时，直接访问/orders这类二级路由会404，必须配置回退到index.html：

server { listen 80; server_name trade.example.com; # 前端静态资源 root /opt/game-trade/dist; index index.html; # 路由回退 location / { try_files $uri $uri/ /index.html; } # 后端API反向代理 location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } # 上传文件访问 location /upload/ { alias /opt/game-trade/upload/; } }

7.2 从课程设计走向生产环境：后续可以做的事情

这套系统跑到“能演示、能上线”只是第一步。如果真要往生产环境方向走，我认为有几个优先级比较高的事情。

第一是接入真正的第三方支付，替换掉模拟支付，这一步涉及商户资质、回调验签、退款接口，技术复杂度会上升一个台阶。第二是完善钱包体系，目前资金流向依赖订单表，更合理的做法是把“平台待结算给卖家的钱”独立冻结到wallet表的frozen_balance字段，并让卖家可以在后台申请提现。第三是引入WebSocket，买家付款后实时通知卖家发货，比定时轮询订单列表体验好很多。

我个人的体会是，游戏交易系统这类项目，业务逻辑的复杂度远高于技术本身。状态机、资金流水、原子扣减这些设计一旦想清楚，SpringBoot和Vue写起来反而顺畅。最后再分享一个小技巧：开发时把order_logs和trade_record两张表的所有字段都打印到日志里，排查线上纠纷时你会发现，这两张表比任何运维工具都好用。