企业官网建设流程全解析

接到这个选题的时候，我反复琢磨了一个问题：一套卖苗族侗族文创产品的微信小程序，和普通电商小程序，本质区别在哪？如果答案是没区别，那这个项目就只是标准电商系统的换皮。真正做完以后才明白，差别全出在商品模型上——手工银饰、蓝染围巾、刺绣挂件，规格不标准、批次不一致、库存数量经常要手工改，商品详情里塞满了文化故事而不是参数表。这些特征直接决定了后端服务怎么划分、数据库表怎么设计、小程序页面怎么展示，完全不能照搬卖标准工业品的电商模板。

我这篇就把这套“SpringBoot + 微信小程序”的文创销售平台完整拆一遍，从需求拆解、技术选型、数据库设计到订单支付的核心实现，全程只讲实际落地时能直接用的思路和方案。如果你正在做类似方向的毕设，或者想了解一个带真实支付闭环的小程序电商项目是怎么组织起来的，这篇文章可以当一份工程参考。

1. 项目到底要做什么：需求拆解比写代码更重要

1.1 一套文创电商系统，本质上在解决什么

很多同学拿到这类题目就开始建表写接口，结果做着做着发现，购物车、订单、支付都是现成套路，真正难搞的反而是“商品”这个最基础的东西。所以我强烈建议先想清楚一个问题：文创电商系统到底解决什么？

它要解决两件事。第一件是交易闭环，用户浏览商品、下单、支付、收货、评价，这套流程任何电商都躲不掉。第二件是内容交付，文创商品的购买决策很大程度上受文化故事、工艺来历、使用场景影响。用户买一条刺绣围巾，不只是买一块布，而是买“手工刺绣”这个标签背后的文化认同。系统必须把商品背后的文化信息变成可浏览、可收藏、可下单的内容载体。

这意味着设计上要比普通电商多几个层次：商品除了标题、价格、库存，还要有材质、工艺、非遗标签、传承人故事、定制说明。列表页展示的不只是图片和价格，还要有“手工”“限量”“可定制”这类决策信息。想清楚这一点，后面所有表结构设计和接口设计就都有了方向。

1.2 苗族侗族文创商品的业务特征决定了系统设计

苗侗文创产品不是标准工业品，它的商品数据有几个很明显的业务特征，每一个都影响技术实现。

• 一件一品。很多手工饰品每个批次、每个师傅做出来的都会有细微差异，库存数量不是经销商给的固定数字，而是“现在手头有多少现货”，改库存是日常操作。
• 规格不标准。同一条围巾可能有多个尺寸和花色，但每个SKU的数量都很小，甚至有的款式只有一件，卖完就真的没了。
• 定价逻辑复杂。手工品往往有“基础款、精工款、定制款”之分，价格跨度很大，定制款还需要用户备注尺寸、纹样偏好。
• 文化属性强。商品要能挂上“非遗工艺”“苗绣”“蜡染”这类标签，用户会按主题逛，而不是按搜索词逛。

这些特征直接落到技术上：库存不能永远按SKU固定数量去硬扣，得支持人工锁定和释放；下单时不能只选一个普通规格，还得支持留言定制；商品表需要扩展文化字段；搜索和导航要把“文化专题”当成一个入口来做。我在实际建模时就把商品分成了product和product_sku两张表，并给商品增加了多个标签字段，后面做文化活动专题页面时才没有返工。

1.3 为什么这个组合是“SpringBoot + 微信小程序”

选型不是拍脑袋，核心原因有三个。

第一，微信小程序是目前触达这类文化消费用户最轻的载体。文创产品客单价不低，但用户决策周期长，通常是在公众号内容、朋友圈分享里看到，再打开小程序慢慢逛。小程序“用完即走”的体验正好匹配这种非刚需、非高频的消费场景。第二，SpringBoot能撑起整个业务后台。小程序只是一个客户端，真正的商品管理、订单处理、支付回调、数据统计都得靠后端完成。SpringBoot生态成熟，MyBatis-Plus、Redis、微信支付SDK都有现成接入，做工程化的成本最低。第三，微信支付链路是闭环的。用户在小程序里直接拉起支付，比做H5商城在支付环节上的体验好一大截，后端只需要处理好支付回调，交易闭环就能成立。

之前有人问为什么不用Vue写个网页端就算完事。网页端当然能做，但缺少微信登录的免密能力，也缺少微信支付在移动端的原生拉起体验，转化率完全不是一回事。所以“SpringBoot + 微信小程序”不是炫技，而是针对这类销售业务的最优解。

2. 技术选型：哪些是标准答案，哪些要自己想清楚

2.1 后端框架：SpringBoot的取舍

后端我用的是Spring Boot 2.7，搭配MyBatis-Plus、MySQL 8、Redis，权限这块没上Spring Security，而是用一个拦截器加自定义注解搞定。这么选的原因很直接：项目体量在十个业务模块左右，Spring Security那套复杂的过滤器链和配置对于这种规模完全是过度设计，写起来反而拖慢进度。

MyBatis-Plus是我比较推荐的持久层方案，内置分页插件、逻辑删除、字段填充，单表CRUD几乎不用手写SQL，能把大量时间省给核心业务。但要注意一点，所有涉及库存扣减、订单状态更新的SQL都必须手写，不能用它自带的updateById去拼，因为那些场景对条件更新和原子性有要求，后面第四节会专门讲。

整个后端我拆成了这样几个包结构：controller、service、mapper、entity、config、common。common里放统一返回结果类Result<T>、业务异常BizException、全局异常处理器。统一返回结构特别重要，小程序端接接口最烦的就是“有时候直接返回对象，有时候返回字符串”，统一成{code, msg, data}以后前端解析逻辑可以一套代码走天下。

2.2 小程序端：原生渲染还是uni-app

小程序端我选了原生开发，没有用uni-app。理由很简单：项目只发布微信一个平台，原生小程序的调试工具、组件能力、云开发能力都是最直接的，遇到问题查资料也最容易命中。uni-app的优势是跨端，但代价是需要维护一套自己的编译链，一旦遇到自定义组件或者平台差异，排查成本比省下来的开发量还高。

原生小程序里我用了几个主题明确的组件和工具：TDesign小程序组件库提供基础UI组件，Vant也有用到，主要解决地址选择、弹窗这些通用交互；请求封装上做了一个简单的request.js，统一处理基础URL、token注入、401跳转登录、错误Toast。页面结构上，比较重要的是把首页、商品、购物车、订单、个人中心拆成了五个Tab页，每个Tab对应独立的包，方便后期做分包优化。

有一点要提醒：小程序的setData性能问题很实际。我在商品列表页第一次加载50条数据时，一次性往页面上塞了完整对象集合，滚动起来明显卡顿。后来改成每次只渲染{id, title, price, cover}这种精简字段，图片用懒加载，列表滚动就顺了。这个细节在开发调试时很难发现，真机上手指一滑就有感知。

2.3 存储与中间件：MySQL、Redis、文件服务各管什么

MySQL负责所有业务数据的持久化，商品、用户、订单、评论全在里面。金额统一用int类型存“分”，避免float/double的精度问题。凡是列表查询都走索引覆盖，订单表按user_id、status做联合索引，商品表按category_id、status建索引，这是最基础但最有效的一步。

Redis在这个项目里干了三件事：缓存热点数据、做分布式锁防超卖、记录幂等Key。首页的轮播和推荐商品、商品详情页都是读多写少的数据，直接缓存成JSON字符串，管理员在后台改商品后删掉对应缓存即可。库存扣减的防超卖锁也放在Redis里，用SETNX实现一个简单的下单锁。另外，微信支付回调的transaction_id我会先检查Redis里是否已处理过，处理过就直接返回成功，防止重复更新订单。

文件服务这块，商品图片用的是云对象存储，小程序端的图片域名要求必须是HTTPS，而且要在小程序后台配置合法域名。开发阶段可以在开发者工具里勾选“不校验合法域名”，但上线前不配好就全挂了。上线后图片建议走CDN，因为小程序包体有限，商品图、详情页长图这种大资源不能塞进包里，必须全部外链。

3. 功能模块划分：用户端与管理端各要什么

3.1 用户小程序端的功能清单

用户端总共做了八个核心页面模块，整理如下：

整个用户端的核心交互是围绕“逛”而不是“找”来设计的。搜索框只是一个辅助入口，真正引导用户的是首页的文化专题和分类导航，因为文创消费是内容驱动型决策，用户需要先看到故事，再看到商品。

3.2 管理后台的功能清单

管理后台没有单独做成App，而是按Web端管理页面来实现，SpringBoot只提供REST接口。功能上主要覆盖三块：商品维护、订单处理和营销配置。

商品维护包括商品录入、SKU批量编辑、库存调整、上下架、专题标签设置。这里面我在文创场景下加了一个“库存盘点”功能，管理员可以手工把某个SKU的库存修正成实际数目，所有操作都写进操作日志，方便追溯。订单处理包括订单列表、按状态筛选、发货、取消订单、查看用户定制备注。发货是纯手工操作，因为文创产品很多是手工打包，没有快递单号自动对接，管理员在后台填单号就完事。营销配置包括轮播图、专题推荐位、公告的增删改，所有配置都做成“所见即所得”，不用改代码。

3.3 接口权限模型：单端小程序如何同时服务两类角色

这套系统虽然只有一个小程序客户端，但后台管理员是走Web端的，所以接口天然分成两套：用户端接口和管理端接口。为了让同一个后端工程干干净净地处理两类请求，我在项目里做了简单的双路径隔离。

用户端接口统一走/api/wx/**，需要小程序登录态，通过请求头的Token鉴权；管理端接口统一走/api/admin/**，需要管理员账号密码登录后拿到的Token鉴权。两个路径分别配置拦截器，拦截器里检查Token包含的角色信息，用户端Token只允许访问用户端接口，管理员Token只允许访问管理端接口。拦截器里还要做一层@RequireRole注解支持，有些接口比如下单、支付是普通用户专用，有些接口比如发货、商品编辑是管理员专用，一个注解就能声明清楚。

这种设计在代码上不算什么高级货，但它把权限边界收得很干净。我之前看过一个案例，把管理员和用户塞在同一套接口里，只靠前端按钮隐藏来控制权限，结果任何用户只要能猜到管理接口的URL就能调发货接口，这在毕设答辩里属于致命伤。

4. 数据库设计：文创商品的表结构不能照搬电商模板

4.1 核心表清单与设计依据

数据库是整个项目的骨架，我建了下面这些核心表：

两张表的设计需要重点解释。第一张是product_sku，文创商品SKU数量不大，但规格文本千奇百怪，所以我把spec直接设计成JSON字符串，比如{"size":"均码","color":"蓝染","style":"手工刺绣"}，页面要展示时直接解析，做筛选时再用冗余字段辅助。第二张是orders.address_snapshot，下单时把收货地址转成JSON快照存进去，这样用户后续修改收货地址不会影响历史订单的发货，这是电商系统的基本功，但很多毕设项目都忽略了。

4.2 订单状态机：从下单到收货的完整流转

订单状态是这套系统里最容易出Bug的地方，必须先定义清楚再写代码。我的订单状态定义如下：

状态机写清楚以后，后端的核心逻辑就是一句话：每次状态更新必须满足“当前状态属于允许流转的源状态”，否则直接拒绝操作并抛异常。这个判断写在OrderStateMachine类里，所有订单操作，包括用户取消、支付回调、管理员发货、自动关闭，都必须走这个类的方法，禁止在业务代码里直接update status。

实际开发中有一个教训：有次支付回调已经更新了订单为PAID，但并发场景下用户又点了取消，请求进来判断源状态时发现订单已经是PAID了，于是取消失败，这是对的。但因为我在取消方法里没有加锁，导致第一次取消请求校验通过后还没提交事务，第二次取消请求又进来校验一次，也通过了，结果造成状态更新覆盖。最后修复方式是所有状态更新都加“状态条件更新”SQL：UPDATE orders SET status = #{target} WHERE order_no = #{orderNo} AND status = #{from}，返回受影响行数为0就说明状态已经被别的请求改了。

4.3 金额、库存、规格这三个容易踩坑的点

创业项目的坑，大多集中在三个点上。

金额必须用分存储。小程序端展示时要自己除以100转成元，所有计算都在后端做，前端永远只接收金额数字。订单金额、商品价格、退款金额，全用int类型，数据库字段也是int，避免任何浮点运算。

库存的扣减时机必须想清楚。我采用的是下单时预占库存策略：创建订单时，把订单涉及的所有SKU库存先扣掉；如果30分钟内未支付，定时任务自动释放。为什么不用“支付成功再扣库存”？因为文创商品很多是孤品，用户占着库存不付款会让其他想买的人干瞪眼。预占库存至少能保证真正下单的人有货可发。

规格和商品必须分开建模。之前有同学把所有规格直接做成商品表里的一个字段，像“款式一、款式二”这种写在一个字段里，结果前端要按库存过滤就特别痛苦。正确的做法是product存商品属性，product_sku存一个具体的可卖商品单元，每个SKU有自己的价格、库存、图片，这样购物车和订单明细都能精确到SKU粒度。

5. 关键业务实现速写

5.1 微信登录链路与用户态管理

微信小程序登录是典型的code2session流程。前端调用wx.login()拿到一个临时code，传给后端；后端拿着code、小程序appid、secret去微信接口换openid和session_key；openid是用户在微信体系里的唯一标识，用它去库里找用户，找不到就注册一个。

我封装了一个UserContext工具类，每次请求进入拦截器后，解析出当前用户ID和角色信息放到ThreadLocal里，业务代码直接用UserContext.getUserId()拿当前用户，不用在每个Controller方法里都传一遍用户参数。Token用的是JWT，payload里放userId和role，过期时间设的是7天，小程序端每次请求前检查本地缓存，发现Token快过期了就先调wx.login走一次静默刷新逻辑，用户在页面上的操作完全无感。

这里有个安全细节容易被忽略：微信的session_key我建议只在后端内存里短暂使用，不落库。如果一定要落库，也要加密存储，并且不能随着用户的任何输入一起返回给前端。

5.2 商品组合数据的查询与缓存

商品列表接口和详情接口看着简单，但实现时很容易写出N+1查询。详情页要展示的基础数据包括：商品主信息、SKU列表、轮播图列表、文化标签、评论摘要。如果按照常规思路先查商品，再循环查SKU，再循环查图片，一个详情接口就会产生几十条SQL。

我的做法是分两步查：先查商品主信息，再一次性查出该商品的全部SKU和图片，然后用内存组装。列表页则构建了一个精简的商品列表对象，只包含封面、标题、价格区间、标签、最低库存状态。价格区间怎么算？一个商品可能有多个SKU，展示上的价格应当是最低价到最高价，比如“128元～368元”。这个区间在列表页接口里直接聚合查出来，避免前端拿多SKU自己算。

缓存方面，首页推荐和商品详情我都在Redis里放了一份JSON，key的设计是product:detail:{id}，管理员修改商品或调整库存时主动删除对应缓存。缓存的时候要注意：商品详情里的库存数据不能缓存太久，我设置的过期时间是15分钟，因为库存是实时变化的，缓存太旧会让用户下单时才发现没货，体验很差。

5.3 下单与支付：库存扣减的时机选择

下单接口是核心中的核心。它要做的事包括：校验购物车商品、计算金额、扣减库存、生成订单号和订单明细、清空对应购物车项。为了让整个操作要么全部成功要么全部失败，必须开一个事务。

库存扣减我用的是乐观锁方式，SQL长这样：

UPDATE product_sku SET stock = stock - #{count} WHERE id = #{skuId} AND stock >= #{count}

返回受影响行数为0就说明库存不足，直接抛库存不足异常，整个事务回滚。为什么不用先查再改？因为先查再改在并发场景下必然超卖。这条SQL把“检查库存”和“扣减库存”合并成一个原子操作，是防超卖最简单可靠的方案。如果并发量再大一些，可以在Redis里先做预扣减，但这个项目的业务量用SQL条件更新完全够了。

订单号生成我用的是“时间戳+用户ID后四位+四位随机数”的方式，虽然不如雪花ID严谨，但在这个体量下足够唯一，而且可读性强，客服查单时一眼就能看出大概下单时间。订单创建完成后，前端拿到订单号，调后端/pay/wx/create接口创建微信支付预支付单，拿到微信返回的支付参数，再调wx.requestPayment拉起支付面板。

5.4 支付回调：验签、幂等、订单闭环

支付回调是整个系统最不能出错的环节。微信支付成功后，微信服务器会往我们配置的回调URL发一个POST请求，请求里包含订单号、交易号、支付金额等数据。后端拿到回调后要做三件事：验签、解密、更新订单。

验签是必须的，防止伪造回调请求。微信支付V3的验签过程是：从请求头拿到Wechatpay-Signature、Wechatpay-Timestamp、Wechatpay-Nonce等参数，用微信平台证书验证签名，验证通过后再用APIV3密钥解密请求体里的加密数据。这块我直接用了微信官方Java SDK的NotificationParser，省去了手写加密逻辑的麻烦。

幂等处理是防止重复更新的关键。同一个支付成功回调，微信可能会重试多次，如果后端每次都执行“更新订单为已支付”的逻辑，就可能出现重复加积分、重复发日志、状态被覆盖的问题。我的处理方式是：回调进入后，先用transactionId查Redis，如果存在说明已处理过，直接返回成功应答；不存在则继续处理业务，业务完成后写入Redis并设置过期时间。同时数据库里也用order_no + transaction_id做了唯一约束，双保险避免重复入账。

更新订单状态时，还是用那套条件更新SQL：UPDATE orders SET status = 'PAID', pay_time = NOW(), transaction_id = #{transactionId} WHERE order_no = #{orderNo} AND status = 'WAIT_PAY'。如果影响行数为0，说明这个订单当前状态不是待支付，就不能再改成已支付。所有支付成功的业务操作，包括扣减库存、增加销量、记录状态日志，都在事务里完成，事务提交后再返回{"code":"SUCCESS"}给微信。

5.5 订单超时自动关闭的实现方案

订单超时自动关闭，我一开始想用Redis的过期监听来做：给每个订单Key设30分钟过期时间，过期后触发回调关闭订单。但实际测试发现Redis过期事件并不可靠，消息可能延迟甚至丢失，而且开启了Key过期事件通知后，所有Redis的Key都会触发事件，干扰很大。后来还是回归到最朴素可靠的方案：定时任务扫表。

SpringBoot里用@Scheduled注解写一个定时任务，每分钟执行一次，扫描状态为WAIT_PAY且create_time超过30分钟的订单，批量把它们关闭，同时把预占的库存加回去，并写状态日志。加库存也必须走条件更新：UPDATE product_sku SET stock = stock + #{count} WHERE id = #{skuId}，这样即使订单关闭和用户下单同时发生，也不会因为加存货和扣库存在同一行上打架。

这个方案会多扫一些数据，但表量在万级以内完全没压力，而且逻辑透明，出问题好排查。唯一要注意的是定时任务要加分布式锁：如果后期部署多台服务，防止多台同时扫同一批订单重复释放库存。我用Redis的SETNX锁了一个“关闭订单任务”的Key，任务执行完再删掉，保证同一时间只有一个实例在跑。

6. 常见问题与排查技巧实录

6.1 支付类问题速查

支付问题排查，第一件事永远是把日志打开。我在回调入口一开始就打印收到支付回调，body=xxx，哪怕处理逻辑后面报错，也要把原始请求体打印出来。没有这个日志，出了问题只能对着微信后台瞎猜。回调地址部署时必须使用HTTPS公网地址，这个在上线前就要配好，否则微信根本推不进来。

6.2 数据与并发类问题速查

这里我想说一个非常隐蔽的坑：事务和锁的顺序。如果你在事务里先SELECT ... FOR UPDATE锁行，然后又去远程调Redis或者外部接口，锁的持有时间会变得很长，并发一高就把整个订单表锁死。我的原则是：锁操作的范围要尽可能小，能把外部调用放在事务外，就放在事务外。下单事务里只做数据库操作，Redis锁在事务前获取，事务提交后再释放。

6.3 小程序端体验类问题

小程序端的体验优化，我的整体思路是“能不请求就不多请求，能精简就绝不铺开”。首页只请求一次推荐数据，用户切换到后台再回来时，如果数据还没超时就直接用缓存，避免每次onShow都重新拉全量。分页加载统一做成“下拉刷新 + 上拉加载更多”，并且每次加载前判断hasMore，没更多数据就停止请求，这些小细节叠起来，用户体感会明显好很多。

7. 一点实际经验总结

这整套系统做下来，我最想分享的体会是：不要在项目一开始就埋头写代码，先把订单状态机和库存扣减方案想清楚。这两个问题想通了，整个系统80%的难点其实就已经消解了。状态机解决的是业务流转的合法性问题，库存扣减解决的是数据一致性问题，剩下的大部分内容，比如购物车、商品列表、后台管理，都是在这两个骨架之上铺肉。

第二个体会是：日志要写得比代码还勤。支付回调、定时关单、库存扣减这几个关键路径，每一步都要打日志。我调试支付回调时，就是靠一条条日志配合排查，才定位到是回调验签里的平台证书配置问题，而不是订单逻辑的问题。上线后运维也全靠这些日志，没有日志的系统就是一口黑锅，出了问题只能靠猜。

最后再分享一个文创场景特有的小技巧：系统里尽量多留文化专题位。首页的专题推荐、商品详情里的工艺故事、订单完成后的“猜你喜欢”，都比单纯的销量排序更能提升转化率。技术实现上不过就是多存几个字段、多配几个推荐位，但对于这类有文化内核的商品，内容就是最好的“算法”。这套系统的价值不在代码量多少，而在于它让用户买到的不仅是一件商品，还是一段可以带走的文化记忆。