刚接到这个题目时，我第一反应是：这不就是电商系统加了个“机器人”前缀吗？直到真去梳理需求才发现，基于SpringBoot的机器人商城管理系统和普通电商有着明显的差异。一台六轴机械臂上架时，运营要填自由度、最大负载、工作半径、重复定位精度、供电方式、通信接口、防护等级、安装方式等几十项参数，而每台设备还有“加装视觉模组”“更换夹爪型号”这类选配逻辑。用普通商城那一套“标题+图片+富文本详情”来支撑，商品上架的第一关就过不去。
这篇文章我想从实际设计者的视角，把这个系统的需求边界、技术选型、数据库设计、核心交易链路、以及我踩过的一些坑完整写出来。适合正在做毕业设计、课程设计，或者刚接触全栈电商项目、想理解“单体应用如何做到结构清晰又抵抗并发”的开发者。我会把为什么这么设计的思路也讲清楚，不是只给一堆代码。
1. 为什么“机器人商城”不是普通电商换个皮 —— 项目定位与需求边界
做这个系统之前，我接手过一个机器人设备厂商的商城需求。对方一开始拿的是某通用电商平台的模板，结果运营在实际录入商品时发现根本没法用。机器人的规格参数是“参数表驱动”的，客户下单前要对着几十项技术指标核对选型，而不是像买手机一样只看颜色和存储容量。
所以在做系统设计时，第一件事不是建表，而是把“机器人商城”到底有哪些特殊性梳理清楚。
1.1 机器人商品和普通商品的核心区别
普通电商商品，比如手机、服装，规格维度通常很少，商品模型基本是固定字段加少量规格。但机器人产品完全不同，差异点集中在四个方面：
- 规格维度复杂且不固定。不同分类的机器人，参数模板完全不一样。机械臂要关注自由度、负载、臂展；移动机器人要关注导航方式、避障传感器、电池续航；教育机器人则更关注编程接口、开源程度。这就意味着商品模型必须支持“分类-规格模板-参数值”的灵活绑定，而不是写死字段。
- 库存管理粒度不同。整机类机器人往往按序列号/SN管理，交付时要记录出厂编号、生产日期、保修期；配件和耗材则按普通SKU管理。这个差异直接影响库存表怎么设计。
- 交易模式混合。整机设备经常是“客户线上询价、销售线下沟通、最终合同成交”；而配件、保养耗材则是标准线上订单。系统需要同时容忍“半线下流程”和“纯线上流程”。
- 售后不是简单的退换货。机器人设备涉及安装调试、固件升级、返厂维修，所以售后单要能关联订单、关联商品SN、记录处理节点。
如果照着普通电商抄一套，这些场景全部都会变成“勉强能用但很难受”。
1.2 这类“管理系统”题目容易做歪的三个地方
我见过很多以“XX管理系统设计与实现”为题的演示项目，问题通常出在三个地方：
一是把项目做成了纯粹的CRUD，商品删掉后历史订单里的商品信息跟着消失，或者变成空引用；二是库存扣减逻辑写成“先查再扣”，并发一高就超卖；三是没有统一的返回结构和异常体系，接口联调时前端拿到各种形状的数据，代码里写满if判断。
这些问题如果能在这个项目里提前想明白，答辩也好、真实交付也好，都会顺畅很多。所以我在下文里会把这些点都展开讲。
1.3 用户角色与核心业务流
整个系统可以拆成三条角色线去理解：
- 用户端：注册登录、浏览分类、查看商品参数、加购结算、在线支付、查看订单、申请售后。
- 运营端：维护分类、维护规格模板、商品草稿录入、上架审核、SKU价格与库存调整、订单发货、售后处理。
- 管理员端：角色与权限分配、数据看板、敏感配置管理。
核心业务流则是“运营建商品 -> 审核上架 -> C端/B端浏览询价下单 -> 扣减库存创建订单 -> 支付回调 -> 发货 -> 售后”。
把边界和角色理清楚之后，技术选型和表结构设计就有了明确依据。
2. 技术选型不再纠结：SpringBoot这套组合到底解决了什么问题
选型不是选“最流行的”，而是选“在这个场景下最稳、最容易把业务做对的”。我最终用的核心组合是SpringBoot + MySQL + Redis + Vue3，单体应用架构。
2.1 后端为什么选SpringBoot而不是自研框架或纯Servlet
SpringBoot的核心价值在于“自动装配+生态成熟”。项目里要用的数据库访问、缓存、参数校验、权限认证、支付回调验签，几乎都能在Spring生态里找到成熟方案。对于这种管理类系统，团队协作时最怕的是“每个人写一套工具类”，SpringBoot通过starter统一了这些基础能力。
另外SpringBoot的约定大于配置能显著降低上手成本。一个刚接触项目的新人，看到application.yml里的数据源配置、@RestController的接口写法、@Transactional的事务边界，基本不需要额外培训就能开始改需求。这在交付型项目里是实打实的优势。
版本方面我是这样定的：JDK用的17，SpringBoot用的2.7.x（不是3.x，因为当时团队对一个第三方支付SDK的兼容性有顾虑，实测3.x会把部分XML配置方式改掉，没必要在这个项目里冒险），ORM用的MyBatis-Plus。MyBatis-Plus对CRUD的简化程度很高，也支持自定义SQL应对库存扣减这类复杂操作。
2.2 前端与中间件的搭配思路
前端管理后台用的Vue3 + Element Plus。这个组合在做后台管理类界面时效率极高，表格、表单、弹窗、树形控件都有现成组件，和后台系统的交互模型非常契合。
用户端商城界面我没有强制用前后端分离。考虑到首页、商品详情页对SEO有要求，我实际采用的是“模板渲染为主、局部交互用Vue组件”的半分离方案。商品搜索、购物车、订单状态这类偏交互的模块再用接口异步渲染。这套做法比强上SPA更适合内容型页面，也降低了首屏渲染的复杂度。
数据库选的MySQL 8.0，InnoDB引擎。Redis用来做热点商品缓存、购物车临时数据、验证码存储、以及库存预扣。文件存储用的本地磁盘加MinIO，机器人商品有大量的产品手册、三维模型图、演示视频，统一走对象存储比较合理。支付对接的是支付宝沙箱和微信支付沙箱，沙箱环境足够完成功能演示和流程验证。
2.3 “单体优先”的架构决策
这个系统我没有一开始就上Spring Cloud微服务。原因很简单：业务规模没到那个量级，微服务带来的分布式事务、服务治理、部署编排成本，会直接把项目拖垮。单体架构不代表代码烂，关键是模块边界清晰。
我按maven多模块拆分了四个部分：
robot-common：通用返回结构、异常定义、工具类robot-admin：后台管理端接口robot-portal：用户商城端接口robot-framework：安全配置、Redis配置、文件配置等横切能力
这样做的好处是，将来如果流量真的涨到需要拆分，可以先从robot-portal的订单模块拆出去，不至于推倒重来。对学习项目来说，这种“模块清晰”的状态也更容易给代码评审者讲解。
3. 数据库设计是这类系统的“隐形杀手”：从商品规格到订单快照
数据库设计在整个系统里占比最重，也最影响后续开发体验。我按照“商品域-交易域-库存域-售後域”四条线来设计表结构，下面挑核心的表说明。
3.1 商品表的拆分思路：SPU与SKU
机器人商城必须先区分SPU和SKU两个概念，否则后面全乱。
SPU（Standard Product Unit）是商品信息聚合层，比如“六轴桌面级机械臂套装”；SKU（Stock Keeping Unit）是具体可卖的库存单元，比如“六轴桌面级机械臂 + 视觉模组 + 臂展800mm + 220V供电”。每个SKU对应自己的价格、库存、规格参数。
核心表结构如下：
category：分类表，机器人整机、配件、耗材等，支持层级spec_template：规格模板表，绑定分类，定义该分类下需要维护哪些参数product：商品SPU表product_sku：SKU表，规格参数用JSON列存储
spec_template我留的字段是category_id、spec_name、spec_type、options、is_required、sort。options存的是下拉选项JSON，比如“供电方式”的可选值是["220V","380V","48V DC"]。这样运营新增商品时，前端可以动态根据模板渲染表单。
product_sku表的规格字段我用了specs JSON。有读者可能会问：为什么不拆成规格值明细表？我的理由是：机器人规格维度太多且不稳定，如果用关系表存储，查询和编辑反而要反复join和动态拼SQL，维护成本高。JSON列配合校验逻辑，在这个业务量级下是性价比最高的做法。真正要按规格筛选商品时，可以在搜索中间件里做，而不是靠数据库硬扛。
3.2 订单表与商品快照：不能只存一个商品ID
订单表这里有一个特别重要的设计原则：订单明细必须保存商品快照，而不是仅仅存sku_id，然后在展示时去join商品表。
为什么？因为商品是会变的。运营可以修改价格、修改商品名称、下架商品甚至删除商品。如果订单明细里不保存成交当时的商品名、规格描述、单价、图片等信息，历史订单很快会变成一堆无法展示的ID。用户查看“三个月前买的机械臂”时，看到的应该是当时购买的商品信息，而不是商品现在的样子。
所以我这里order_item表里加了快照字段：
CREATE TABLE `order_item` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `order_id` BIGINT NOT NULL, `sku_id` BIGINT NOT NULL, `product_name` VARCHAR(255) NOT NULL, `spec_desc` VARCHAR(500) NOT NULL, `product_image` VARCHAR(255), `price` INT NOT NULL COMMENT '成交单价，单位分', `quantity` INT NOT NULL, `snapshot` JSON COMMENT '商品快照JSON', `create_time` DATETIME NOT NULL, KEY `idx_order_id` (`order_id`) ) ENGINE=InnoDB;price字段我特意用INT存“分”，而不是用DECIMAL或FLOAT。金额计算用整数可以完全规避浮点误差，订单总金额就是SUM(price * quantity)，非常干净。
订单主表也存了address_snapshot，收货地址同样要在下单那一刻固化。用户后来改了收货信息，不能影响这个订单的物流配送。
3.3 库存、日志与售后：容易被忽略的三张表
第一张是stock_log库存流水表。我记录了每次库存变更前后的数值、变更类型、关联订单号、操作人。这张表的价值在排查“库存为什么对不上”的时候会体现出来。没有流水表的库存系统，出了问题基本只能靠猜。
CREATE TABLE `stock_log` ( `id` BIGINT PRIMARY KEY AUTO_INCREMENT, `sku_id` BIGINT NOT NULL, `change_type` VARCHAR(32) NOT NULL COMMENT 'ORDER_CREATE/ORDER_CANCEL/ADMIN_ADJUST/REFUND', `change_qty` INT NOT NULL, `before_qty` INT NOT NULL, `after_qty` INT NOT NULL, `order_no` VARCHAR(64), `operator_id` BIGINT, `remark` VARCHAR(255), `create_time` DATETIME NOT NULL ) ENGINE=InnoDB;第二张是aftersale售后单表。机器人售后的状态流比普通商品复杂，涉及“待审核、待寄修、维修中、检测完成、已退款、已换货、已关闭”这些节点。所以这张表里面有status字段之外，还要有problem_desc、image_urlsJSON、result、process_logJSON。
第三张是sku_sn序列号表。如果系统要管理整机设备，每个整机SKU会生成唯一的SN码，下单时锁定SN，发货时记录SN去向。这样设备后续进售后流程时，可以直接通过SN查到购买订单和保修信息。这个设计在第一期可以做成“登记制”，不必一开始就完全自动化。
4. 核心业务链路落地：从加购到支付完成的完整代码思路
表建完之后，核心的交易链路落地是关键。这里我挑四个最典型的环节讲，顺序是“商品查询-下单-支付回调-后台导入导出”。
4.1 商品列表接口中的缓存与不一致处理
商品详情页的数据由多个部分组成：SPU基本信息、SKU列表、规格参数、运营图文、相关配件推荐。如果每次都查数据库，详情页的接口压力会非常大。
我实际采用的方式是把“商品详情聚合数据”整体缓存到Redis，key设计为product:detail:{productId}，value是整个ProductDetailVO对象的JSON序列化字符串，过期时间设置30分钟并加上随机偏移量，避免大量商品同时过期导致缓存雪崩。
public ProductDetailVO getProductDetail(Long productId) { String cacheKey = "product:detail:" + productId; String cached = redisTemplate.opsForValue().get(cacheKey); if (StringUtils.isNotBlank(cached)) { return JSONUtil.toBean(cached, ProductDetailVO.class); } ProductDetailVO vo = buildProductDetailFromDb(productId); if (vo == null) { // 缓存空值，防止缓存穿透 redisTemplate.opsForValue().set(cacheKey, "{}", Duration.ofMinutes(5)); return null; } redisTemplate.opsForValue().set(cacheKey, JSONUtil.toJsonStr(vo), Duration.ofMinutes(30 + RandomUtil.randomInt(0, 300))); return vo; }这里我做了两件事防御：第一，缓存空值，防止不存在的商品ID被恶意刷导致数据库被打穿；第二，公众号或运营后台修改商品信息时，删除product:detail:{productId}这个缓存key，而不是去更新缓存，因为更新聚合缓存太容易漏字段了。
4.2 下单流程的“三件事”：校验、扣库存、写订单
下单接口是交易系统的核心区域。我把整个下单流程放在一个@Transactional事务里面，事务内依次完成校验、扣库存、写订单三步。
@Transactional(rollbackFor = Exception.class) public OrderVO createOrder(CreateOrderDTO dto) { // 1. 校验SKU状态与库存 Sku sku = skuMapper.selectById(dto.getSkuId()); if (sku == null || sku.getStatus() != 1) { throw new BizException("商品已下架"); } // 2. 扣减库存：条件更新，防止超卖 int rows = skuMapper.deductStock(sku.getId(), dto.getQuantity()); if (rows == 0) { throw new BizException("库存不足"); } // 3. 写订单主表与明细表 // 4. 记录库存流水 // 5. 返回待支付订单VO }关键点在deductStock这条SQL。它必须是一条带条件的原子更新语句：
UPDATE product_sku SET stock = stock - #{quantity}, sale_count = sale_count + #{quantity} WHERE id = #{skuId} AND status = 1 AND stock >= #{quantity}执行结果返回更新的行数。如果返回0，说明库存不足或者SKU状态已经不合法。这个写法直接把“校验-扣减”合二为一，从根上解决超卖问题。比“先SELECT库存，再判断，再UPDATE”的写法在高并发下更安全，因为两条SQL之间必然存在竞态窗口。
下单之后需要写stock_log流水表，记录这次扣减的数量和关联订单号，方便后续排查。事务内部任何一个环节报错都会回滚，库存也会跟着回滚，不会出现“库存扣了但订单没生成”的现象。
4.3 支付回调与订单状态机的推进
支付回调是另一个容易埋雷的地方。支付宝、微信支付在回调时会有“重试机制”，同一个支付结果可能通知多次，如果幂等没做好，就会出现重复发货、重复加积分之类的问题。
我实现支付回调的流程是这样的：
- 先验签，确认这是支付平台发来的真实请求；
- 根据
order_no查出订单； - 用Redis的
setnx加一个分布式锁，key是order:paylock:{orderNo}； - 在锁内判断订单当前状态，如果已经是“已支付”，直接返回成功给支付平台；
- 否则才更新订单状态、写支付流水、记录库存流水（此时不需要再动库存，因为下单时已经扣过了）。
public void handlePayCallback(PayNotifyDTO notify) { boolean locked = redisTemplate.opsForValue() .setIfAbsent("order:paylock:" + notify.getOrderNo(), "1", Duration.ofSeconds(10)); if (!locked) { throw new BizException("重复回调"); } try { Order order = orderMapper.selectByOrderNo(notify.getOrderNo()); if (!Objects.equals(order.getStatus(), OrderStatus.WAIT_PAY)) { return; } // 更新订单状态、写支付流水、更新用户权益 } finally { redisTemplate.delete("order:paylock:" + notify.getOrderNo()); } }订单状态机我定了固定的一条链：
待支付 -> 已支付 -> 已发货 -> 已收货 -> 已完成
同时有两个分支：
待支付 -> 已取消（用户取消或超时关闭）
已支付/已发货 -> 售后中 -> 已退款 / 已完成
超时关闭订单我用的定时任务，每分钟扫描一次，把超过30分钟未支付的订单关闭，同时回滚库存。回滚前必须校验订单还是“待支付”状态，防止支付回调已经到账却被定时任务误关。
4.4 后台管理的Excel导入导出：一个最容易被低估的功能
这个点可能很多人会忽略，但实际运营效率的瓶颈往往就在这里。一个机器人SKU的规格参数有几十列，如果一条条在表单里录入，上架50台设备可能要运营人员干一整天。我做了基于EasyExcel的导入导出：
- 后台先下载“SKU导入模板.xlsx”，模板列和
spec_template动态生成； - 运营按模板填写后上传，后端逐行校验价格、库存、规格参数格式；
- 校验通过才批量落库，任何一行有问题，返回带行号的错误提示。
金额统一以“分”为单位写入Excel时除以100，读入时乘以100。这里有个经验：导入时千万别让用户填“金额（元）”，小数点一错全错。宁可模板里直接写“价格（分）”，或者统一保留两位小数后转整数，也能减少很多返工。
5. 实测中躲不开的坑：这些问题我在开发时都踩过
这一部分是全文的“干货区”。下面四个坑我都真实踩过，希望能帮读者少走弯路。
5.1 库存超卖的根因与处理方案
我第一次写这个项目时，库存扣减用的是最直观的写法：
Sku sku = skuMapper.selectById(skuId); if (sku.getStock() >= quantity) { // 执行update }表面看没问题，但两个请求同时查到stock=1，都通过校验，都执行update stock = stock - 1，最终数据库里库存变成-1。这在JVM单进程内就可能发生，因为查询和更新是两行代码，中间有执行空隙。
修复按我上面说的，改成单条条件更新SQL。如果系统高并发到了Redis必须参与的程度，可以在数据库扣减之前先用Redis预扣：
local stock = redis.call('get', KEYS[1]) if not stock or tonumber(stock) < tonumber(ARGV[1]) then return -1 end redis.call('decrby', KEYS[1], ARGV[1]) return 1这个Lua脚本在Redis中原子执行。预扣成功后，再去执行数据库扣减。数据库扣减失败则回补Redis库存。
我个人的最终方案是：Redis预扣 + 数据库条件更新 + 事务回滚补偿。下单前预扣库存，创建订单成功则数据库对应扣减并回补Redis；创建失败则回补Redis。这样既挡掉了绝大多数无效请求打到MySQL，又保证了最终一致性。
5.2 JSON规格字段的“写入容易读取难”
规格参数用JSON列存储后，最大的坑出现在“写入与读取的口径不一致”。举例来说，同一个“臂展”参数，运营A录的是800mm，运营B录的是0.8m，前端展示时就会出现非常不专业的效果。更麻烦的是，有些SKU没有视觉模组参数，JSON里就不存在这个key，前端拿到不同结构的JSON后只能靠一堆防御代码兜底。
我的解决方法是：
- 在规格模板里给每个规范参数配置字段类型（数值、单选、多选、文本），并在后台录入时强制校验；
- 入库前做一次“模板化补全”，把模板里的所有参数key都写到JSON里，没有值的用空字符串占位；
- 这样最终前端拿到的SKU规格JSON结构永远是统一的，缺失值也至少是有序的空值，渲染逻辑大幅简化。
这个思路本质上是把“数据的结构稳定性”前置到写入阶段，而不是靠读取时兜底。
5.3 接口返回结构不统一导致的联调地狱
项目开发早期，有同事图省事，有的接口直接返回Map，有的返回一个裸的List，有的又包了一层{code: 200, data: ...}。前端联调时每个接口都要单独适配，代码里全是if (res.data && res.data.list)这种垃圾防御。三天联调后我实在受不了，把所有接口统一成Result<T>结构。
public class Result<T> { private Integer code; private String message; private T data; }并且约定：
code = 0表示成功；code != 0表示业务失败，前端读取message直接弹出提示；- 系统级异常统一由
@RestControllerAdvice捕获，兜底返回code = 500。
从那时起，联调效率提升了一个量级。这个约定最好在项目启动第一天就定好，不要中途再改。
5.4 时区与金额字段：低级但致命
最后一个小坑是时区。MySQL连接串里如果不加serverTimezone=Asia/Shanghai，SpringBoot默认按UTC处理时间，订单创建时间会比北京时间少8小时。排查这类问题时往往会浪费很多时间，因为业务代码看起来完全正常。
金额字段我在前面提过用INT存“分”。这里还要再强调一句：金额计算请统一在Service层用整数运算，不要前端传浮点数、后端存DECIMAL，最后打印出来一堆0.30000000000000004。这些低级错误在演示的时候会非常破坏专业度。
6. 从能跑到跑得稳：安全加固与上线前检查清单
这个系统如果只是课程设计或内部演示，基础认证就够了。但如果要真实上线运营，权限、防刷、部署每一项都要打磨。
6.1 权限模型与接口防刷
我用的是Spring Security + JWT。用户端和管理员端是两套Token体系：
- 用户端登录后拿
UserToken，访问/api/**接口； - 管理员登录后拿
AdminToken，访问/admin/**接口； - 管理员再细分角色：运营（维护商品和订单）、客服（处理售后）、超级管理员（分配权限）。
密码存储用BCrypt加密，Spring Security内置支持，千万不要自己写MD5加盐。MD5在现代GPU算力面前太容易被暴力破解。
接口防刷我在关键接口上做了Redis限流。比如发送验证码接口限制“同一手机号60秒1次”，下单接口限制“同一用户每秒最多2次”。实现逻辑并不复杂：
public boolean tryAcquire(String key, int limit, int seconds) { Long count = redisTemplate.opsForValue().increment(key); if (count != null && count == 1) { redisTemplate.expire(key, Duration.ofSeconds(seconds)); } return count != null && count <= limit; }这个简单的incr + expire实现已经能挡住大部分脚本刷接口的行为。
6.2 参数校验与XSS防御
后端接口入参全部加了Validation注解：
public class CreateOrderDTO { @NotNull(message = "SKU不能为空") private Long skuId; @Min(value = 1, message = "购买数量至少为1") @Max(value = 99, message = "单次购买数量不能超过99") private Integer quantity; }前端如果传入非法参数，会在进入业务逻辑之前被拦截，返回统一的参数错误。另一件重要的事是XSS防御。运营后台的商品富文本详情，内容要按白名单过滤，去掉<script>、<iframe>这类标签和javascript:协议，否则后台成了攻击者投放恶意脚本的窗口。
文件上传也是高危区，我做了三重限制：只允许指定的扩展名（jpg、png、pdf、zip等）；限制单文件大小；文件重命名为UUID后存储。这样即使压缩包里有恶意文件，也不会以可执行形式出现在系统目录。
6.3 上线部署与回归检查清单
部署我用的方式是打jar包 + Docker容器化，前端构建后由Nginx托管，反向代理到后端服务。流程并不复杂，但有几件事必须做：
- MySQL开启定时备份，至少每天全量备份一次；
- 生产环境关闭Swagger接口文档和调试日志级别；
- 用JMeter做一次简单压测，重点测注册、商品搜索、下单这三个接口，观察响应时间是否在预期范围内；
- 下单接口高并发压测时，重点看数据库连接池是否被打满，以及库存最终是否和预期一致；
- 给运营准备一份操作手册，把“上架商品完整步骤”“处理售后单流程”写成文字加截图，否则后面所有问题都会来问开发。
6.4 轻量级数据看板的实现
如果想在答辩或演示时更出彩，可以加一个轻量数据看板。不强制，但很有效。我实现了“今日完成订单数、今日销售额、库存预警列表”三个指标。
实现思路是在下单和支付回调成功时，对Redis的计数器执行incr，然后写一个定时任务每5分钟把Redis中的累计值刷到MySQL，前端通过一个聚合接口展示。数据允许短时间内的延迟，不需要实时。这个功能工作量不大，但对“系统价值”的表达帮助很大。
7. 写在最后的个人体会与扩展思路
做完这个项目，我最大的体会是：题目看起来是普通的电商管理，但真正拉开差距的是对业务特殊性的理解和对数据一致性的把控。一个系统能不能扛住演示现场“多人同时下单”的压力，能不能在运营误操作后还能查清数据，完全取决于数据库设计和事务边界是否到位。
在扩展方向上，我觉得这个系统有几个自然的演进路径：
- 整机设备引入SN序列号全链路追踪，从出厂、入库、下单、发货到售后，用SN串起来；
- 增加询价转订单流程，B端客户对整机询价后，销售在后台把整套配置转成正式订单；
- 结合消息推送，用户下单、发货、售后进度等节点通过站内信或短信触达；
- 如果订单量真的增长到单库压力很大，再考虑按用户维度做分库分表，或者把订单模块拆成独立服务。
最后一件事想提醒所有做类似项目的开发者：不要把精力都放在“炫技”上。把商品参数模型设计好、把订单快照和库存流水做好、把接口返回结构统一好，这些反而更能在演示和答辩时让听的人眼前一亮。功能堆得多但核心链路脆弱，一上并发就原形毕露，那种翻车现场我见过不少次。宁可做十个扎实的核心功能，也不要铺二十个虚的页面。
