企业官网建设流程全解析

客制化键盘圈子里有个老生常谈的问题：为什么市面上大多数电商系统，直接拿来卖键盘总是各种别扭？因为客制化键盘不是标品，买家不是在“买一把键盘”，而是在“拼一把自己的键盘”。轴体、键帽、外壳、PCB、定位板、卫星轴，每一环都要自己选，甚至颜色、配列、灯光模式都要参与决策。这种“组件自由组合”的需求，和传统商城“SPU直接加购”的模型完全是两回事。我最近刚完成了一个基于 Spring Boot 框架的客制化键盘个性化商城网站项目，代号就叫“springboot101”，从数据库建模到配置器实现踩了不少坑，这篇文章就把设计思路、核心实现、以及排查过程中最有价值的经验完整写出来。

这个项目适合三类人看：第一类是准备做垂直电商、尤其是做“配置型产品”商城的开发者，第二类是客制化键盘圈子里的玩家想自己搭个简易商店，第三类是正在做毕业设计或课程项目、想找真实业务场景的人。它不是一篇纯理论教程，而是把“配置器 + 商城链路”如何落地讲透的实操记录。

1. 项目到底要做什么：客制化键盘商城的需求拆解

1.1 为什么叫“springboot101”，技术选型背后的逻辑

“springboot101”这个名字听起来像个版本号，实际上是我给项目起的内部代号，意思是“用 Spring Boot 把一门技术吃透”的练习项目。选型上没有上微服务那套复杂架构，而是老老实实用单体应用加模块化分包，因为这类商城的核心矛盾不在并发，而在业务规则的复杂度。

我选用的技术栈是 Spring Boot 2.7、MyBatis-Plus、MySQL 8.0、Redis、JWT，前端用 Vue 3 加 Element Plus。有人可能觉得 MyBatis-Plus 不如 JPA 纯粹，但我看重的是它对单表 CRUD 的快速覆盖，开发效率高，而且 SQL 随时可以手工改写。Redis 主要承担三件事：缓存组件价格、缓存兼容性规则、在高峰期协助库存锁定。JWT 做用户登录态，没有引入 Spring Security heavyweight 那套，因为项目里角色就两种：普通用户和管理员，自定义拦截器足够。

选型时我考虑过两个替代方案：一是直接买一套现成的电商开源系统再改造，二是用 Node.js 写全栈。前者的问题在于，现成系统的大多数功能我们都用不上，但它的数据模型会死死约束住配置器的实现方式；后者开发确实快，但服务端事务管理、定时任务、数据一致性方案都没有 Spring Boot 生态来得顺手。综合下来，单体 Spring Boot 是最平衡的选择。

1.2 客制化键盘商城和普通电商网站的本质区别

普通电商的购物车条目是“商品 ID + 数量”，用户下单时直接关联商品表，订单详情展示也是从商品表实时查。这套逻辑放到客制化键盘上完全走不通，因为用户购买的不是一个现成商品，而是一整套配置方案。

举个例子：一个配置方案里包含“65% 配列铝合金外壳套件 + 佳达隆 G 轴 Pro 黄轴 + PBT 键帽 + 焊接 PCB + 钢定位板”。如果某个组件缺货、下架、或者价格涨了，普通电商的做法是订单照常显示，最多标注“商品已失效”，但客制化键盘不行，因为用户买的是一套兼容的组合，任何一个组件变了都可能导致整套方案无法使用。

所以核心差异有两个。第一，商品模型要从“单品”变成“组件 + 配置方案”，配置方案是用户生成的组合体，它必须能被持久化、分享、再次购买。第二，订单必须存“配置快照”，不能依赖实时外键关联，否则后台一改组件信息，历史订单就乱了。理解了这两点，后面的数据库设计和接口设计才有方向。

1.3 功能模块的边界划分

我把整个商城拆成前台、后台、公共基础三个部分，前台功能包括首页组件展示、个性化配置器、我的方案、购物车、订单、模拟支付、个人中心。后台功能包括组件管理、方案审核、库存管理、订单管理、内容管理。公共基础部分包括用户登录注册、权限拦截、文件上传、缓存管理。

模块划分最重要的原则是“配置器相关逻辑独立成域”。我没有把配置器代码散落在商品模块里，而是单独抽了一个 config 包，里面放方案实体、兼容性校验服务、价格计算服务。这样做的好处是，后续如果要把配置器开放给第三方店铺使用，可以直接通过 API 暴露，不用动商城主链路。同时，订单模块只依赖配置器提供的“方案快照”接口，不直接访问组件表，这样两个模块的耦合度降到了最低。

2. 数据库设计与核心实体建模

2.1 客制化键盘配置器的数据库建模：组件、规格与兼容性

先看核心的组件表。传统电商会建一张巨大的商品表，把所有属性都列成字段，但客制化键盘的组件属性差异太大：轴体有压力克数、触底手感、是否有导光柱；键帽有高度、材质、工艺；PCB有焊接/热插拔、有无 RGB；套件有配列、结构、连接方式。如果全部拆列，字段会爆炸，而且新增属性必须改表。

我的方案是 component 表只存公共字段，差异化属性放到 spec_json 字段里。

CREATE TABLE component ( id BIGINT PRIMARY KEY AUTO_INCREMENT, category VARCHAR(32) NOT NULL COMMENT '组件分类：case/pcb/plate/switch/keycap/stabilizer', name VARCHAR(128) NOT NULL, spec_json JSON NOT NULL COMMENT '规格属性，按分类约定结构', price DECIMAL(10,2) NOT NULL, status TINYINT NOT NULL DEFAULT 1, image_url VARCHAR(512), create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

spec_json 看起来简单，但要约定好每种分类的字段结构，否则不同人录入的数据格式会不一致。比如 switch 分类的 spec_json 统一为：

{ "type": "linear", "actuationForce": 45, "bottomForce": 55, "travel": 4.0, "hotswap": true, "stem": "cross" }

这样前端拿到 spec_json 后按分类渲染表单，不需要写死几十个字段。查询式筛选会用 limited，但后台管理列表也只需要查组件ID、分类、名称、价格这些公共字段，复杂筛选完全交给前端按分类处理 JSON。

兼容性问题我用 compatibility_rule 表解决。每条规则包含 expected_category 和 required_tag，含义是“选了某个 category 的组件后，方案里必须同时存在带某个 tag 的另一个组件”。例如 PCB 如果是 hotswap，就要求定位板的 tag 包含 "hotswap-compatible"。校验的时候，把所有规则加载进内存，遍历用户方案的组件列表，逐个检查条件是否满足。规则表变更频率低，非常适合缓存。

2.2 订单一定要存配置快照，别怕冗余

这是整个项目里我最后悔没有一开始就做对的地方。第一次实现时，order_item 表里只存了组件 id，想着下单后实时查组件表拿到名称和价格。结果上线没多久，我在后台把某款轴体从 3 元一颗调到了 3.5 元一颗，用户历史订单里的价格显示就全变了，而且有一批已下架的键帽直接显示了“商品不存在”。用户截图来投诉，我才意识到订单数据不能这么设计。

客制化键盘订单的可靠做法是：order_item 表中每个组件的名称、单价、图片、规格 JSON 全部冗余存储，当用户提交订单时一次性写入快照。我用的是 order + order_item 两表结构，order 存用户信息、总价、状态，order_item 存每个组件的快照快照。

CREATE TABLE order_item ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_id BIGINT NOT NULL, config_snapshot_id BIGINT COMMENT '关联的方案ID，可为空', component_id BIGINT COMMENT '组件ID，仅用于追溯', component_name VARCHAR(128) NOT NULL, component_image VARCHAR(512), category VARCHAR(32) NOT NULL, unit_price DECIMAL(10,2) NOT NULL, spec_json JSON NOT NULL, quantity INT NOT NULL DEFAULT 1, subtotal DECIMAL(10,2) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

订单展示时，优先读 order_item 快照，组件表和方案表只用于“重新购买”功能。这样即使组件表被删得干干净净，订单依然完整可看。很多人嫌弃冗余，但订单表就是电商系统里最应该接受冗余的地方，它牺牲的是一点点存储成本，换来的是一劳永逸的数据可靠性。

2.3 库存与价格不允许直接在组件表上改

库存设计我一开始也很天真，直接在 component 表加了一个 stock 字段。后来发现这样没法处理“锁定”的概念。用户下单后、支付前的这段时间里，库存应该被暂时冻结，不能卖给其他人，但支付超时后又需要释放。直接减 stock 的话，释放逻辑会变得极其痛苦。

所以我单独建了 inventory 表，字段包括 component_id、total_stock、locked_stock、available_stock。下单时把在途库存加进 locked_stock，支付完成后把它从 locked_stock 挪到 sold_stock（或者说直接减少 total_stock），超时未支付则把 locked_stock 释放回 available_stock。这样库存的每一步变化都有据可查。

价格也是一样的道理。组件表里的 price 只能被视为“当前挂牌价”，真实的成交价以订单快照为准。后台改价不影响历史订单，但是会影响购物车和配置器里的实时计算。配置器的价格不能查 MySQL，要查 Redis 缓存，价格变更时主动删除缓存，避免用户配置时看到的价格和支付时不一致。

3. 个性化配置器的前后端实现

3.1 配置器前端交互设计：SVG 配列预览与组件面板

客制化键盘配置器的前端，最大的难点不是布局，而是让用户“看得懂自己在配什么”。我采用左侧组件分类列表、中间键盘预览、右侧已选配置面板的三栏布局。中间预览区我用 SVG 画了一个基础键盘配列，60%、65%、75%、98、104 这几种常见配列分别定义了一套按键坐标。用户切换配列后，SVG 根据坐标重新渲染每个按键的位置。

选组件的流程是这样的：先在左侧选分类，比如“轴体”，然后在列表里看到轴体图片、手感类型、价格、剩余库存。点击某个轴体后，右侧面板的“轴体”槽位被填充，此时中间预览图上的按键会变色，提示已经有轴体可安装。如果该轴体和当前 PCB 冲突，前端会直接弹出一个黄条提示“当前轴体为五脚轴，所选 PCB 不支持”，并阻止添加。

这个实时校验不是纯前端的营销噱头，而是真正调用后端的 /api/config/validate 接口完成的。前端防不住所有情况，比如库存锁定、价格变动这种事就必须后端兜底。但实时校验能提前拦下大部分不兼容组合，用户体感会好很多，不会等到下单才告诉你配错了。

3.2 后端接口设计：校验、保存、方案加载

配置器的接口我设计成四个，刚好覆盖用户操作链路。

• POST /api/config/validate：传入完整组件 id 列表或 key，后端做兼容性校验、库存校验、价格计算，返回校验结果和总价。
• POST /api/config/save：保存当前方案，生成 config_snapshot，返回 configId。
• GET /api/config/{id}：加载方案详情，用于“我的方案”列表和再次编辑。
• POST /api/cart/add：把方案加入购物车，参数是 configId 和数量。

这里有个容易被忽略的问题：validate 接口和 cart/add 接口之间，方案的价格和库存可能会变化。如果有人绕过前端，直接调用 add 接口，后端必须重新校验并重新计算价格，不能信任客户端传过来的总价。所以 add 接口内部会先加载方案，得到最新的组件列表，然后复用和 validate 相同的校验逻辑。

校验逻辑的核心是组合校验。伪代码大致是这样：

public ConfigValidateResult validate(List<Long> componentIds) { List<Component> components = componentService.listByIds(componentIds); ConfigValidateResult result = new ConfigValidateResult(); // 1. 检查分类完整性：每个分类必须至少选一个 // 2. 检查兼容性规则：加载全部规则并逐一匹配 // 3. 检查库存：每个组件的 available 必须大于等于需求数量 // 4. 计算总价：累加每个组件的实时价格 result.setTotalPrice(components.stream() .mapToBigDecimal(Component::getPrice) .reduce(BigDecimal.ZERO, BigDecimal::add)); return result; }

兼容性校验我用了规则引擎，但没引入规则引擎框架，直接简单遍历匹配。规则表结构不复杂，就几百条，性能瓶颈在多次查询。所以我在 Service 层做了启动时加载，把规则集合缓存到内存，Redis 里存一份规则版本号，后台修改规则后刷新版本号，各节点检测到版本号变化后重新加载。

3.3 价格的实时计算与缓存策略

价格计算看着简单，实现起来有个细节：用户每次修改配置都要调用一次价格接口，如果每次都查 MySQL 的组件表，一台数据库的负载会很难看。我把组件价格缓存到 Redis，key 设计为 price:component:{id}，value 为 JSON 字符串，过期时间设为二十分钟。后台组件改价时，除了更新 MySQL，立即删除该 key，强制下次请求回源。

要注意的是，价格缓存不能顾头不顾尾。用户把方案加入购物车后，购物车展示的总价也要从缓存读取。但如果用户在下单前修改了方案，购物车里的旧方案如何更新？我的做法是购物车条目里始终保存方案 id，每次打开购物车时重新按方案 id 去计算一次价格，然后更新展示，避免购物车里的价格过期。

缓存和数据库的一致性问题在这个场景下没有选择强一致方案，因为丢失几秒钟的价格一致性用户感知不到。但如果发生在支付前，最后一道关卡必须回源数据库验价，防止缓存里是旧价格导致少收款。这个“展示用缓存、支付用数据库”的原则，在商城类项目里可以推广到所有涉及钱的地方。

4. 商城核心链路：加购、下单、支付、库存

4.1 购物车与配置方案的联动设计

购物车表设计成 cart_item(id, user_id, config_id, quantity, selected, create_time)。它不存组件列表，只存 config_id，因为方案本身就是商品单元。这个设计的好处是购物车天然支持“再次编辑方案”的功能：用户点购物车里的某条记录，直接跳转到配置器，把 config_id 对应的方案重新加载出来，改完保存后购物车条目自动指向新的方案版本。

缺点也很明显：方案一旦被修改，购物车里的旧显示字段就需要同步。于是我在 cart_item 里加了冗余的 display_name 和 display_image，在保存方案时同步更新购物车条目，避免每次渲染购物车都要加载方案详情。

数量方面我限制了最大为 5。客制化键盘不是量产键盘，很少有人一次买很多把，但这个项目里我遇到过有人批量下单囤轴体的情况，如果数量限制不对，下单时组件库存瞬间被打穿。每个组件在方案中的数量也不能乱来，一套方案里轴体和键帽的数量必须和配列匹配。比如 65% 配列通常需要 68 颗轴、68 颗键帽，如果用户想多买 10 颗备用轴，应该走单独的“配件加购”逻辑，而不是混在方案配置里。

4.2 下单幂等与库存扣减的两种实现

下单接口必须处理重复点击的问题。前端会给每个订单创建请求生成一个 client_token，后端在进入事务前先查询唯一订单号表，如果同一个 token 已经有订单，直接返回该订单，不做第二次扣减。

库存扣减我踩过 SELECT FOR UPDATE 的坑。最初用 select for update 锁行，再判断 available 是否足够，再 update。高并发下，同一个热门轴体的库存行会成为热点锁，一旦某个请求锁住后做其他表操作，其他请求全部阻塞，接口响应时间直线上升。后来改成条件更新，一条 SQL 完成扣减：

UPDATE inventory SET locked_stock = locked_stock + 1, available_stock = available_stock - 1 WHERE component_id = ? AND available_stock >= 1;

如果 update 影响行数为 0，说明库存不足或状态异常，直接抛出“库存不足”异常并回滚整个下单事务。用条件更新替代行锁，在高并发下性能明显改善，而且不会出现锁等待导致连接池耗尽的问题。

锁定库存后，订单进入“待支付”状态。同时启动一个定时任务，每隔五分钟扫描一次待支付超过 30 分钟的订单，释放 locked_stock，并把订单状态改为“已关闭”。注意定时任务要和下单逻辑共用同一个库存扣减 Service，释放库存同样有条件判断，避免重复释放。

4.3 模拟支付回调与订单状态机

真实支付对接在生产环境才有意义，开发阶段我实现了一个模拟支付模块。前端点击“去支付”后，后端生成一个支付订单号，并返回给前端一个模拟收银台页面。页面里输入任意金额确认按钮，就会调用回调接口，模拟第三方支付渠道通知。

回调接口必须做安全处理。我用简单的 appId + secret 生成签名，回调参数拼接后按约定排序，加上 secret 做 MD5。签名校验通过才允许修改订单状态，防止别人直接调用回调接口改自己订单为已支付。这个签名逻辑虽然是模拟，但能保证后续换成真实支付渠道时，改动成本几乎为零。

订单状态机就是五态：已创建、已支付、已发货、已完成、已关闭。状态只允许单向流转，不允许从已支付跳回已创建。状态变更记录在 order_status_log 表里，用来排查“订单怎么突然变状态了”这种问题。支付成功后，如果用户购买了刻字服务，还要生成一个定制任务发送到后台，由管理员手动处理后进入发货流程。

5. 常见问题与排查实录

5.1 超卖问题：配置器看得到有货，下单却提示库存不足

这个问题上线第二天就出现了。用户在前端看到轴体还有 30 颗，下单时报“库存不足”，马上来质问。原因不复杂：前端展示的库存来自 Redis 缓存，缓存里是五分钟前的库存数据，而下单扣库存查的是 MySQL。两者本来就不是实时一致，高并发下前端数据滞后很正常。

排查思路分三步：先看 MySQL 里 available_stock 是否为 0，再看 Redis 缓存的值是否比 MySQL 大，最后确认定时刷新缓存是否失败。这个问题的本质不是 bug，而是设计预期。我在前端加了“库存数量仅供参考，以实际下单为准”的提示，同时在用户加购时启动一个三秒的重新校验，降低售卖过程中的心理落差。

如果你想从根上解决展示不一致，可以改为前端轮询 Redis 库存，但 Redis 库存和 MySQL 库存仍然存在同步窗口。客制化键盘这种小众商品，与其纠结毫秒级一致，不如把订单预期管理做好，靠实际下单时的条件更新兜底。

5.2 配置快照丢失：订单详情里看不到用户当初选了什么

这个问题我在 2.2 节提到过，测试阶段没暴露，上了生产后被一个真实订单触发。用户在下单后三天找客服说“我当时选的是黑透外壳，为什么订单里显示白色外壳？”我一查数据库，order_item 用的外键关联组件表，而管理员在后台把该外壳的图片换成了白色款，订单详情渲染就跟着变了。

排查过程很顺利，因为问题定位很明确：订单详情不能实时查组件表。修复方案是写了一个数据修复脚本，把历史订单项按当时的订单时间点、组件 ID，从数据库里补一份组件名称和 spec_json 快照进去，同时修复订单展示查询逻辑，优先读快照。这一步之后，我要求所有涉及订单详情的查询全部不查 live 组件表，只查快照。

这个坑再次印证了一个原则：订单是交易凭证，不是商品快照的临时外键。凡是涉及“用户当初买的是什么”的字段，全部要在交易发生时落库，后续任何人修改商品资料，都不应该影响已产生交易的历史记录。

5.3 配置校验接口慢：规则查询拖垮性能

项目联调阶段，配置器校验接口平均耗时 200ms，用户改一次轴体就要等近一秒，体验非常差。我用慢日志查到性能瓶颈在兼容性规则查询上，校验一次要发数十条 SQL 去查规则表。由于规则表很简单，直接改成一次性加载到本地内存，每次校验只遍历内存集合。

具体做法是定义了一个 CompatibilityRuleCache，启动时从数据库全量加载规则列表到 ConcurrentHashMap。后台管理端提供刷新接口，修改规则后调用 cache.reload()，同时更新 Redis 里的规则版本号。每次校验请求先比较版本号，一致则直接用本地内存数据。这个优化把接口耗时降到了 10ms 以内，而且代码改动量不到五十行。

类似的优化我也用到了组件分类的规格定义上。前端每次打开配置器都会请求 component categories 接口，这个接口数据量小、变更少，我直接在前端本地做了持久化缓存，并加了版本号，规则或分类变了才重新拉取。前后端配合之后，配置器整体响应明显顺滑。

5.4 定时任务释放库存的边界问题

最后一个比较隐蔽的坑是定时任务。每天凌晨两点释放超时未支付订单的库存，释放之后某天早上用户下单发现库存还是 0，后台一查 available_stock 没有恢复。排查发现，定时任务扫描订单时，把订单状态改成了“已关闭”，但释放库存的 SQL 因为 affected rows 为 0 被忽略了，原因是库存行已经被前面某个任务重复释放过一次，产生了逻辑上的重复释放。

这个问题的本质是释放操作没有设计成“幂等”。我加了 order_id 到库存流水表，释放前先查流水是否存在，如果存在就直接跳过，保证每次释放只执行一次。释放库存也改成和扣减一样的条件更新，同时更新状态和释放数量，避免状态更新和库存释放之间出现中间态。

这类定时任务的坑在测试环境很难触发，因为测试环境没人真的下单并等半小时。建议写定时任务时，要假设自己可能在半夜被电话叫醒，所以流水记录、幂等判断、异常日志这三样东西一个都不能少。

项目做到这里，主流程已经完全跑通：用户注册登录、在配置器里自由组合键盘、实时校验兼容性、保存方案、加入购物车、下单、模拟支付、后台发货，管理员可以维护组件库和库存。整体代码量大概一万五千行左右，没有用任何高深技术，但业务复杂度和数据一致性问题的覆盖，已经比很多线上商城都实在。我个人在实际开发中体会最深的一点是：客制化键盘商城的难点从来不在于 Spring Boot 本身，而在于商品模型能不能从“标准品”思维切换到“组合品”思维。如果你也打算做类似项目，先把方案快照、兼容性校验、库存锁定这三个模型想清楚，后面的路会顺很多。