企业官网建设流程全解析

前段时间我在做原神周边售卖平台这类电商项目时，被标题里那一长串技术名词搞得头大——Spring Boot、PHP、Python、小程序、机器学习、数据可视化……乍一看好像每个方向都得沾一点，真动手才发现，把核心业务做扎实比什么都重要。最终我选择用 Spring Boot 作为后端主框架，把小程序端和后台管理端拆开，完成了从商品浏览、购物车、下单支付到后台发货、数据看板的完整闭环。如果你也正打算做类似的原神周边商城、动漫周边平台或者游戏周边交易站点，这篇文章应该能帮你把思路理顺。

先说结论：这种商城类项目真正值钱的部分，不是“会不会用某个新框架”，而是数据模型设计、交易链路的状态控制，以及各种异常情况下系统能不能保持一致。这也是很多带着“源码”走捷径的同学最容易翻车的地方——代码能跑，但一问到“为什么订单状态要这样流转”“库存超卖怎么防”就答不上来。下面我从一个完整落地者的视角，把这个项目拆开讲清楚。

1. 原神周边售卖平台的业务轮廓：先分清“电商平台”和“摆摊”

很多人在拿到这个题目后，第一反应是打开编辑器建一个 Spring Boot 工程，把依赖引好就往里写 Controller。这样做的结果通常是：页面做完了，代码也跑得通，但后台管理、库存、订单状态基本是摆设。要避免这种情况，第一步不是写代码，而是把“售卖平台”翻译成用户和管理员真正会进行的操作。

1.1 周边商城和标准电商的差异点

表面上看来，原神周边售卖平台和普通电商平台没有本质区别，都有商品列表、商品详情、购物车、订单、支付、物流。但周边类目有个非常明显的特征：SKU 维度相对单一，但款式、版本、特典、渠道限定的组合很多。

举个例子，一个角色亚克力立牌可以分成“单人款”“双人款”“透明亚克力款”“带场景立牌款”，同一类商品的图片和详情可以复用，但价格与库存不同。如果为每一款单独建一张商品表，后台维护会相当痛苦；如果只建一张商品表，不做规格拆分，用户下单时又选不了具体款式。

所以在设计第一阶段，我建议大家先把“周边商城”的业务拆成下面几个角色：

• 游客：浏览商品、搜索、查看详情，看到喜欢的内容会被引导登录后下单。
• 注册用户：维护个人信息、收货地址、收藏夹、购物车，完成下单与支付。
• 管理员：管理商品分类、商品信息、SKU 库存、轮播图、订单状态、退款售后，查看销售数据。
• 运营人员（可选）：通过后台看板查看近七天成交趋势、热销 top10、待发货订单数量。

第一版不需要把每个角色都做到完美，但从项目展示角度，至少要覆盖用户端购买闭环和管理端发货闭环。否则答辩或复盘时很容易被问住：“用户支付之后，管理员怎么知道要发什么货？”

1.2 表单页面后端的重要清单

我自己初始设计时，会用以下功能列表来指导编码，每一项都会指向具体的表或接口。这样可以避免写到后面发现字段对不上：

在这里要特别说明一下地址和订单的关联：在结算页时，用户从一个“地址列表”里选默认地址，但订单一旦生成，地址要作为订单字段的快照保存。因为用户之后可能修改地址，历史订单却必须保持下单时的收货信息。这是很多新手项目会犯的低级错误——订单页面一直 join 地址表，用户改地址后历史订单的地址也跟着变了。

2. 选型复盘：为什么我从一堆备选方案里选定了 Spring Boot 为主技术栈

原标题里同时出现了 Java、PHP、Python、C#、小程序等关键词，很容易让人误以为一个项目需要同时用多种语言。但真实工程里，绝大多数情况下主后端只需要选一个，其他角色通过 API 通信。

2.1 主语言的取舍：Spring Boot 的最优解在哪里

我第一次评估时就发现：一个典型校园或小团队项目，最重要的约束是三件事——能否快速开发、是否有足够多的轮子、部署和维护成本是否可控。

• PHP 和 C# 在国内校园网络环境里资料相对少，如果你后续想继续深挖 Java 生态，价值也不如 Spring Boot 高。
• Python 写接口很快，但项目到后期要接较复杂的订单状态机、权限管理和事务控制，团队协作的时候容易放飞自我。
• Spring Boot 的好处是生态太完整了。你要用分页查询有 MyBatis-Plus，要登录态有 Sa-Token/JWT，要 Redis 缓存有现成 starter。尤其是做课程设计或毕业设计，Spring Boot 是整套“外卖系统”“商城系统”的默认解法，遇到问题的答案最多，遇到答辩老师也能讲清楚。

所以最终我确定的后端是Spring Boot 2.7.18 + JDK 8/17 + MySQL 8.0 + Redis 5.x + MyBatis-Plus。这里没有刻意上 Spring Cloud，也没有拆微服务。对于一个周边售卖平台来说，单体应用最直接、最容易维护，也最不容易在答辩的时候给自己挖坑。

2.2 为什么不用 Spring Security，而用 JWT + 拦截器

很多人看到做系统就会默认引入 Spring Security。但这类“非复杂权限模型”的商城项目，Spring Security 的过滤器链反而会带来不小的认知负担。要配置不拦截哪些路径、自定义 UserDetailsService、处理 CSRF，折腾大半天还容易把前端跨域问题搅在一起。

我在项目里采用的是JWT 生成登录态 + HandlerInterceptor 拦截请求。用户登录成功后，后端生成一个带有效期的 token 返回给小程序；小程序每次请求在 Header 里带Authorization: Bearer token；拦截器对需要登录的路径（比如/api/user/**、/api/order/**）校验 token，并把 userId 放入 ThreadLocal。管理后台接口则在/api/admin/**下单独做一层管理员校验。

这套方案的好处就是逻辑肉眼可见，出问题能立刻定位。你不需要理解 Spring Security 那一整套委托过滤器原理，也能把登录态做得很稳。

2.3 前台、后台管理和数据看板的角色分工

原项目标题里提到“小程序”，但从工程角度，不管是微信小程序、H5 还是 Vue 后台管理，都只是后端 API 的客户端。我在实际布局中采用了：

• 用户端：原生微信小程序或 uni-app（这取决于你本机是否安装微信开发者工具），通过wx.request请求后端接口。
• 管理后台：Vue 3 + Element Plus，运行在浏览器中，管理商品与订单。
• 数据可视化看板：单独一个 Vue 页面或直接嵌在管理后台首页，用 ECharts 展示统计数据。

关键点在于，后端不关心页面长什么样。前后端之间的契约就是一份接口文档，只要后端输出稳定的 JSON 结构，前端怎么换都行。这个思路也让“一套后端同时支持小程序、H5、后台”成为可能，而不是把代码复制三份。

3. 数据层是这块项目的真正骨架：我用到的核心表结构与设计理由

如果说 Spring Boot 骨架代码是汽车外壳，那么数据库就是发动机和底盘。周边售卖平台后续出现的绝大部分 Bug，追根溯源都在表结构设计或状态流转上。

3.1 商品信息：SPU 和 SKU 的取舍

我见过很多简化版商城只建一张product表，里面直接放价格和库存。这样页面开发确实省事，但无法解决下面几种情况：

• 同一个角色的徽章有“单个装”和“整盒装”，款式名和价格不同。
• “预售款”和“现货款”放在同一个商品详情页，但发货时间不同。
• 用户下单后后台需要知道买的是哪个具体 SKU，才能正确拣货。

因此我的项目引入了两层商品模型：

• product（SPU）：存商品标题、所属分类、主图、详情富文本、状态（草稿/上架/下架）。
• product_sku（SKU）：存规格名称（如“单人款/双人款”）、唯一编码、价格、库存、图片、是否启用。

在商品详情页，用户看到的“角色、款式、特典版本”其实就是同一 SPU 下的不同 SKU。后端在创建订单时读取的也不是 SPU 的价格，而是当前选中 SKU 的价格。即使同一个 SPU 下面多个 SKU 的封面图完全一样，也必须保留独立记录，因为库存和售价是不同的。

建表粗略如下（我对字段做了精简）：

CREATE TABLE `product` ( `id` bigint NOT NULL AUTO_INCREMENT, `category_id` bigint DEFAULT NULL, `title` varchar(200) NOT NULL, `subtitle` varchar(500) DEFAULT NULL, `main_image` varchar(500) DEFAULT NULL, `detail_html` longtext, `status` tinyint NOT NULL DEFAULT '0' COMMENT '0草稿 1上架 2下架', `create_time` datetime DEFAULT NULL, `update_time` datetime DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; CREATE TABLE `product_sku` ( `id` bigint NOT NULL AUTO_INCREMENT, `product_id` bigint NOT NULL, `spec` varchar(200) NOT NULL COMMENT '规格描述', `price` decimal(10,2) NOT NULL, `stock` int NOT NULL DEFAULT '0', `image` varchar(500) DEFAULT NULL, `status` tinyint NOT NULL DEFAULT '1', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这里要特意提醒你：建库时字符集务必使用 utf8mb4，不要省事用 utf8。角色名、emoji、特殊符号在 utf8mb3 下容易报错或变成问号，特别是周边商品名可能会有特殊字符，这个问题上线前特别难发现。

3.2 购物车与订单的拆分逻辑

购物车表相对简单，核心字段包括用户 ID、SKU ID、购买数量、选中状态、加购时间。需要注意的一个设计是sku_id要额外冗余一份product_id，因为查询购物车列表时，页面需要按商品分组展示，如果没有 product_id，就需要 join 两次才能拿到商品分组信息。

订单数据是项目的核心。我设计了两张表：

• order_main：存订单号、用户 ID、总金额、运费、优惠金额、状态、收货人快照、下单时间、支付时间、发货时间。
• order_item：存订单主表 ID、SKU ID、商品标题快照、规格快照、商品主图快照、单价、数量、小计。

拆成两张表的好处一目了然：如果订单所有信息全放在一行，一个订单买了 5 件不同商品时，字段会非常难查询。order_item里保存的是 SKU 与商品信息在成交那一刻的“快照”，这就避免了下单后商家修改商品标题或价格，导致历史订单展示错乱的问题。

对于订单号，我一般不用自增 ID 直接暴露给用户，而是生成一个业务单号，例如“关键字 + 日期 + 随机数”。原因是不希望用户通过 ID 枚举订单，也不希望在对接支付回调时出现混淆。

String orderNo = "GFG" + System.currentTimeMillis() + String.format("%04d", new Random().nextInt(10000));

虽然这只是一个简化方案，但它足够满足商城基本需求。更严格的场景还需要引入雪花 ID 或 Redis 自增序列，不过对于单体项目来说，当前方式已经够用了。

3.3 订单状态不能只靠“硬编码整数”

很多项目里的订单状态直接用0 1 2 3散落在代码里，后期很容易出现“订单支付成功后，状态没有流转到待发货”这类问题。我在做这个项目时，第一件事就是定义订单状态枚举类。

public enum OrderStatus { PENDING_PAYMENT(0, "待支付", "PAY_TIMEOUT_CANCEL"), PAID(1, "已支付/待发货", "ADMIN_SHIP"), SHIPPED(2, "已发货", "USER_CONFIRM"), COMPLETED(3, "已完成", ""), CANCELLED(4, "已取消", ""), REFUNDING(5, "退款中", ""), REFUNDED(6, "已退款", ""); private final int code; private final String desc; private final String nextEvent; }

在此基础上，后台“发货”按钮只允许把状态从已支付/待发货流转到已发货；“确认收货”只允许把已发货流转到已完成。没有合法流转的事件要直接给前端返回错误提示，不能用“if (status == 0 || status == 1) 都可以执行”这种模糊判断。

4. 交易链路核心：从购物车到支付回调，我踩过最深的坑都在这段

交易链路是整个平台的重中之重。你可以把页面做得朴素一点，但下单、扣库存、支付、发货这些操作在并发情况下绝不能出错。

4.1 减库存不要“先查再改”，用数据库的原子更新

新手最容易写出的代码如下：

ProductSku sku = skuMapper.selectById(skuId); if (sku.getStock() >= count) { sku.setStock(sku.getStock() - count); skuMapper.updateById(sku); }

这在单用户测试时一切正常，但假如两个用户同时下最后一单，两边都查到库存剩 1，都会判断库存充足，于是都进入扣减逻辑，最终库存变成 -1，也就是超卖。解决这个问题，并不需要一开始就引入 Redis 分布式锁。对单体项目而言，一条带条件的 SQL 就能保证扣减的原子性：

@Update("UPDATE product_sku SET stock = stock - #{count} " + "WHERE id = #{skuId} AND stock >= #{count} AND status = 1") int reduceStock(@Param("skuId") Long skuId, @Param("count") Integer count);

只有当int result = skuMapper.reduceStock(...)返回 1 时，才说明库存扣减成功；返回 0 就说明库存不够，直接抛业务异常，并回滚整个下单事务。这里的关键，是把“判断库存是否充足”和“扣减库存”在数据库层面合并成一步。这种方案在单体阶段足够可靠，等日订单量真的上来了，再考虑 Redis + Lua 或 MQ 削峰也不迟。

4.2 下单接口的事务边界与状态一致性

我在下单接口中，会做这么几件事：

1. 从购物车勾选项或“立即购买”参数中得到 SKU 列表。
2. 校验商品是否上架、SKU 是否禁用、库存是否足够。
3. 计算总金额，生成订单主表和订单明细。
4. 调用reduceStock扣减库存。
5. 清空已购买的购物车项。

整个方法都加上@Transactional(rollbackFor = Exception.class)。一旦扣减库存失败，订单主表、订单明细和库存操作必须全部回滚。否则容易出现“库存没扣，但订单已经生成”这类数据不一致。

这里还有一个偏工程化的细节：不要在事务里做远程调用或耗时操作。比如对接模拟支付后，回调逻辑如果可能耗时较长，不要和下单流程塞在同一个长事务里。支付成功回调单独处理订单状态即可。

以下是我在下单 Controller 中推荐的大致逻辑，代码只保留了核心判断：

@PostMapping("/create") public R createOrder(@RequestBody CreateOrderVO vo) { Long userId = UserContext.getUserId(); // 1. 查询地址，校验是否存在 // 2. 查询购物车项或立即购买商品 // 3. 校验商品、SKU、库存 // 4. 创建订单主表和订单明细 // 5. 扣减库存 // 6. 删除已加购的商品 return R.ok(orderNo); }

如果你希望在答辩时表现得更专业，可以额外说明：为什么用数据库事务而不是用“写完订单再调第三方库存”？因为在单库单表结构下，MySQL 本身就具备本地事务能力，把订单和库存维护在同一事务里最简单、安全。不要一开始就把订单和库存拆成两个微服务，那是把问题复杂化。

4.3 支付回调的幂等处理

在这个项目中，可能没有真实商家账号对接微信支付或支付宝，所以我会采用“模拟支付”模式：用户点击“去支付”后，前端请求一个模拟支付接口，后端假设支付成功，再调用同一个支付回调逻辑。

但真实场景下，支付回调可能会因为网络原因被微信或支付宝重复推送。如果你的回调逻辑没有做幂等保护，用户支付一次但订单状态可能被重复处理，甚至给用户发两次发货通知。

我给出的处理方式很简单：

// 先把订单状态从“待支付”更新为“已支付” // 如果更新行数为0，说明订单状态不是待支付，直接返回成功，表示已经处理过 int rows = orderMainMapper.markPaid(orderNo); if (rows == 0) { return R.ok(); }

这样即使支付平台重复回调，第二次进来时订单已经不是“待支付”状态，就直接返回成功，不重复执行业务逻辑。对于取消超时未支付订单也类似：只有“待支付”状态才能被取消，如果已经支付，系统要拒绝取消请求。

4.4 超时未支付、申请退款、确认收货

• 超时未支付：可以使用定时任务定时扫描“创建时间超过 30 分钟且状态为待支付”的订单，然后把订单置为已取消，并恢复库存。
• 用户申请退款：在“已支付/待发货”状态下允许用户申请，管理员后台审核通过后，置为已退款，并恢复库存。
• 确认收货：用户在商品签收后点击确认，订单状态从已发货变为已完成。

这里要特别小心“恢复库存”。如果订单已经发货，用户想要退款，不是简单把状态置为已退款并恢复库存，而是要先把商品退回，再做退款；否则会出现“货已经发出去了，库存也被加回来”的状态。我在第二版代码中给订单增加了一个is_stock_returned字段，专门记录是否已经执行过库存回补操作，避免错误地二次回补。

5. 登录态、文件上传和可视化看板：这些“细活”决定了项目能不能申请上线

很多同学的商城代码写完，商品管理也正常，但对登录态和安全控制缺少概念。如果你想把这个项目包装成一份能写进简历的作品，下面这些点非常加分。

5.1 小程序登录与后端 JWT 鉴权的搭配

小程序端推荐直接使用微信登录能力。用户从小程序端调用wx.login获得临时code，传给后端；后端再调用微信接口换取openid。如果openid对应用户不存在，则自动注册新账号；如果已存在，则直接签发 JWT 返回。

后端负责维护一张user表，核心字段是openid、昵称、头像、手机号、状态。不要把openid当成可以随意暴露的字段，它属于敏感信息，每次请求只需要带上 token，后端解析出userId即可。这里有一点要提醒：wx.login的code有效期只有五分钟，拿到后要立刻换openid，不要把code存入数据库后隔一段时间再处理。

为了保证接口安全，我会创建一层AuthInterceptor，并将需要登录的请求路径集中管理。不需要登录的路径包括：登录接口、商品列表、商品详情、首页 banner。需要登录的路径包括：购物车、订单、个人中心、收货地址。

registry.addInterceptor(authInterceptor) .addPathPatterns("/api/**") .excludePathPatterns("/api/auth/login", "/api/product/**", "/api/category/**");

如果你想管理后台也走同一套拦截器，可以配置一个独立的路径规则。对于管理端接口，判断逻辑里除了要求已登录，还要校验角色字段是否是管理员。为了快速完成项目，我没有引入细粒度的 RBAC 权限表系统，只是在用户表里保留role字段，并在拦截器中判断。

5.2 图片上传与富文本内容的存储

商品图片上传是商城项目的刚需。小规模部署时最简单的方案是：后端接收MultipartFile，保存到服务器本地目录（例如/data/goods/），然后把可访问的 URL 返回给前端。为了让图片在 Web 端可以展示，需要在 Spring Boot 中配置静态资源映射：

registry.addResourceHandler("/upload/**") .addResourceLocations("file:/data/goods/");

但如果你部署在云服务器上，更合适的方案是上传到对象存储（例如存储桶或云 OSS）。这会涉及 Bucket 权限、CDN 域名等配置，在本地测试时没有必要强行引入，否则一个图片服务问题会消耗你一整天的精力。

商品详情的富文本内容，我直接用 longtext 字段保存富文本生成的 HTML。这样做简单，但前端展示时要避免 XSS 风险，后台提交富文本内容时必须对<script>标签等危险内容做过滤。对于本项目来说，后台管理员是可信用户，所以主要风险来自账户被盗后恶意注入。

5.3 数据可视化看板：原标题里的“大屏可视化”其实可以很轻量

项目标题中提到的“大屏可视化”，其实不需要额外搭建一套重量级大数据平台。对一款周边售卖平台来说，最实用的可视化数据是：

• 今日订单数、今日销售额、总用户数、总商品数。
• 近 7 天销售额折线图。
• 销量 Top10 商品排行榜。
• 最近待发货订单列表。

在 Spring Boot 端，我写一个dashboard聚合接口，返回给前端：

public class DashboardVO { private BigDecimal todayAmount; private Long todayOrderCount; private Long totalUserCount; private List<SalesTrendItem> salesTrend; // 近7天 private List<Map<String, Object>> topSkus; // top10 }

前端用 ECharts 一个折线图加两个柱状图就能完成看板展示。整个过程真正的工作量在 SQL 聚合查询上，不在“可视化框架”本身。很多项目把可视化当成一个神秘卖点，其实无非是“后端给数据，前端画图”。如果时间有限，优先把“订单销售额趋势”和“商品销量排行”做出来就够了。

6. 部署到服务器：文字编码、时区和反向代理三个坑我印象最深

项目本地能跑只是第一步。当你把它部署到服务器上并尝试用手机访问时，会遇到很多“本地根本没有但线上必有”的问题。我实际踩过的三个坑如下。

6.1 数据库的 utf8mb4 和时区问题

连接数据库的 JDBC URL 中建议直接写死时区：

spring: datasource: url: jdbc:mysql://localhost:3306/genshin_shop?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

如果不指定serverTimezone=Asia/Shanghai，低版本数据库连接器会用服务器默认时区，可能导致前端取到的时间比本地晚 8 小时。而且建库时要确认表字符集是 utf8mb4，我前面也提过。最容易出现的现象是：用户下单时写的收货人昵称带了一个特殊符号或颜文字，入库直接变成问号，前端展示时乱码。这类问题排查起来非常隐蔽，因为你在本地用普通汉字测试完全不会触发。

6.2 Nginx 反向代理与前端刷新 404

部署小程序时后端一般不需要考虑自己的域名，但如果同时做了 Web 管理后台，就需要 Nginx 同时托管前端静态文件和反向代理后端接口。这里有一个经典配置：

location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; }

这样访问http://服务器地址/api/order/list时，Nginx 会把请求转发给 Spring Boot。需要注意proxy_pass后面是否带/，带不带会导致转发路径的不同。如果配置错误，常见的表现是前端页面能打开，但所有接口请求都 404 或 405。

对于历史路由的 Vue 项目，刷新页面会出现 404。解决方法是添加如下配置：

location / { try_files $uri $uri/ /index.html; }

6.3 防火墙端口与小程序域名校验

云服务器一般需要在控制台的安全组中放行 80、443、8080 端口，只开放安全组还不够，服务器内部可能还有防火墙。如果你通过 Linux 的systemctl stop firewalld关掉防火墙后接口通了，就说明端口被内部防火墙拦截了。

小程序端正式上线时，还需要在微信公众平台配置服务器域名，并且要求域名必须支持 HTTPS，不能直接使用 IP，不能使用端口号。如果只是本地开发，微信开发者工具可以勾选“不校验合法域名”，但一旦你想体验真机访问，没有备案域名和 HTTPS 证书是没法正常调试的。

7. 我这版实现之外想给你留的几句话

很多人在网上找这套源码，是希望省去从零搭建的时间。但我始终觉得，源码最大的价值是给你提供“见过正确答案”的机会，而不是让你跳过思考。如果你只是把代码跑起来然后截图放进报告，那你对这个项目的理解可能只停留在“能运行”，可一旦面试官问起库存如何扣减、订单状态如何流转，就会立刻露馅。

从实际体验来说，把一个 Spring Boot 原神周边售卖平台完整做下来，核心收获并不是“会写接口”或“会用 MyBatis-Plus”，而是建立了一套对交易系统的直觉：知道查库存时要考虑并发，知道订单要有状态机，知道每个历史数据最好保留快照，知道支付回调要处理幂等。这些经验迁移到任何电商后端项目里都依然成立。

如果你准备在这个项目上继续做扩展，我的建议是按这个顺序走：先给商品加上搜索关键词分词与热门搜索提示；再给用户增加“收藏夹”和“浏览历史”；然后把购物车合并逻辑补全。至于标题里提到的机器学习和数据挖掘类功能，我个人看法是这种体量的平台用“热门商品榜 + 新品推荐”已经足够，不必强行套模型。真的想展示算法能力，可以基于历史订单做一个简单的“协同过滤推荐接口”，但一定要保证离线任务对主业务没有影响。

最后分享一个我在开发中常用的技巧：别急着把商品编辑、用户地址、订单查询等普通 CRUD 一次性全部写完，先跑通一条最短主链路——用户登录、浏览商品、加购、下单、模拟支付、管理后台发货、用户确认收货。这条链路通了以后，再慢慢补周边功能。你会发现后续每个功能都只是在主链路上加分支，代码思路清晰，Bug 也少得多。