企业官网建设流程全解析

买菜这件事看起来离技术很远，但真把它拆成一个可运行的系统，你会发现它几乎覆盖了中小型业务系统的全部典型问题：多角色权限、商品与库存、订单状态流转、个性化推荐、评价体系、定时任务和数据看板。基于Java的菜匣子优选系统，说的就是把生鲜蔬菜的选品、展示、下单、配送这条链路用一套Java技术栈完整跑通，再叠加一层"优选"逻辑，让不同用户看到的货架不完全一样。这类题目在毕业设计里出现频率极高，但绝大多数实现只停留在"增删改查跑通就行"，答辩时被追问两句推荐逻辑就哑火。这篇内容面向正在做类似系统、或者准备把手上代码整理成论文的同学，我会把技术选型的取舍、数据库字段怎么定、推荐权重怎么算、库存怎么防超卖、论文怎么写才不被判定为模板，一条一条摊开讲，能直接对着抄的部分我都给出来。

1. 先想清楚菜匣子优选系统到底在解决什么问题

1.1 从买菜场景倒推功能需求，而不是从技术栈倒推

很多人做这类系统是反过来的：先决定用SpringBoot + Vue，再去想"那我要做哪些页面"。这么干出来的系统功能是散的，用户下单流程走一半发现地址管理没做，或者商品下架后订单详情页直接报空指针。更靠谱的顺序是先把自己当成用户和运营方各走一遍。

用户侧：打开首页要看到今天有什么新鲜菜、哪些在打折；挑菜的时候想知道这个西红柿是本地还是外地、大概多久能送到；放进购物车后要能改数量；结算时选地址、选送达时段；付完钱要能看到订单到哪一步了。运营侧：要能上架下架商品、改价格、看库存、处理退款、发优惠券、看今天卖了多少。

把这两侧的行为列成清单，你会发现真正必须做的核心模块其实只有六块：用户与权限、商品与分类、购物车与订单、地址与配送、评价与反馈、推荐与看板。剩下的都是锦上添花。我个人的经验是，先把这六块的主干流程做到能用，再回头加优惠券、积分、秒杀这些功能，否则很容易在一个功能上打磨太久，最后核心链路跑不通。

这里有个容易被忽略的点：菜匣子这类生鲜场景和普通电商有本质区别。普通电商的库存是稳定的，一本书放一年还在；生鲜有保鲜期，今天的菠菜明天就掉价，库存还要按批次管理。所以你的商品表里必须留出"上架时间""保质期天数""产地"这几个字段，否则"优选"两个字就是空话。

1.2 为什么这个题目长期偏爱SpringBoot这套组合

说句实在话，选SpringBoot不是因为它是唯一解，而是因为它在"能在有限时间内独立跑通"这个约束下性价比最高。你可以用纯Servlet + JSP写，也能跑，但配置文件能写到你怀疑人生；你可以上微服务，但一个日订单量三位数的系统拆成六个服务，光是服务注册和链路追踪的配置就够你折腾一周。

我这边的常见组合是：SpringBoot 2.7.x + MyBatis-Plus + MySQL 8.0 + Redis（可选）+ Vue 3 + Element Plus。这套的好处是每一层都有大量现成示例，遇到问题搜一下基本能找到答案；坏处是网上示例版本杂乱，直接抄经常出现依赖冲突。关于版本，我这里给个明确建议——

注意：如果指导方要求必须用SpringBoot 3.x，那你必须把所有javax.servlet、javax.validation改成jakarta.*，这一步不做，启动直接报类找不到，而且报错信息不会直接告诉你是包名问题，很容易卡半天。

1.3 角色划分决定了权限拦截器怎么写

系统里的角色不要设太多，三个就够：普通用户、运营人员、超级管理员。普通用户只能看自己的订单和地址；运营人员能管商品、管订单、看数据看板，但不能改用户权限；超级管理员什么都能干但一般不参与日常操作。

这个划分直接决定了你的拦截器设计。我见过不少项目把权限判断写在每个Controller方法里，if (user.getRole() != 1) return error();，写了几十处之后改需求就崩了。正确做法是用注解 + 拦截器（或者直接用Sa-Token、Spring Security这套），在方法上标@RequireRole("ADMIN")，拦截器统一处理。这样新增接口时只要加个注解，不用重复写判断逻辑。

角色表设计上，建议用role表 +user_role关联表的经典RBAC模型，别图省事在user表里加一个role字段存字符串。原因很实际：后面如果运营需要拆成"商品运营"和"订单客服"两个角色，你那个字符串字段就得全表更新，而关联表只需要插一行。

2. 技术架构与工程结构：别一上来就堆微服务

2.1 前后端分离还是服务端渲染，怎么选不后悔

这个问题每年都有人问。我的判断标准很简单：看你的展示重点在哪里。如果系统里有大量交互（购物车实时改数量、地址切换、订单筛选），那必须前后端分离，用Vue或React；如果只是想快速出效果、页面以展示为主，Thymeleaf模板反而更快。

菜匣子这类系统的交互密度不低，购物车、地址、订单列表都是典型的动态页面，所以我倾向于前后端分离。但分离带来的成本要提前认清楚：跨域配置、登录态传递（JWT放Header还是Cookie）、前端打包后怎么部署到Nginx、开发阶段怎么配代理。这四件事每一件都能卡住新手半天。

跨域这块，开发阶段最省事的做法是在vite.config.js里配代理，让前端请求走同源，避免后端加一堆CORS配置：

// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, rewrite: path => path.replace(/^\/api/, '') } } } })

生产环境则用Nginx把前端静态资源和后端接口放在同一个域名下，/api转发到后端端口，其余走静态文件。这样前后端都不需要处理跨域，是最干净的方案。

2.2 分层结构：Controller里不要写业务逻辑

工程结构乱是这类项目最常见的扣分点。我建议的包结构是这样：

com.example.caihe ├── common 通用返回、异常、常量、工具类 ├── config 配置类（MyBatis、Redis、拦截器注册） ├── controller 只做参数接收和结果返回 ├── service 业务逻辑接口 │ └── impl 业务实现 ├── mapper 数据访问 ├── entity 数据库实体 ├── dto 入参对象 ├── vo 出参对象 └── task 定时任务

为什么要拆DTO和VO？讲个真实场景：用户表里有密码字段，你如果直接把User实体返回给前端，密码就泄露了。用VO只暴露需要的字段，是从结构上解决问题，比在代码里手动user.setPassword(null)可靠得多。DTO同理，注册接口需要的字段和实体字段往往不一致（比如要确认密码字段），用DTO接收入参，校验注解也更好写。

Controller里只保留三件事：接收参数、调用Service、封装返回。任何if-else业务判断、任何数据库操作，都不该出现在Controller里。答辩时被问到"你的业务逻辑在哪一层"，答不上来是很掉分的。

2.3 统一返回与全局异常，早做早省事

这套东西必须在项目第一天就搭好，后期补会非常痛苦。统一返回体长这样：

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 200; r.msg = "操作成功"; r.data = data; return r; } public static <T> Result<T> fail(Integer code, String msg) { Result<T> r = new Result<>(); r.code = code; r.msg = msg; return r; } }

配合@RestControllerAdvice做全局异常捕获，把参数校验异常、业务异常、系统异常分成三类处理。业务异常用自定义的BizException抛出，前端拿到code=500且有明确msg时直接弹提示；系统异常则记录日志并返回统一的"服务器开小差了"，不要把堆栈信息暴露给前端。这一点在论文的"安全性设计"章节里是可以写的实打实的内容。

3. 数据库设计：整个系统的地基，改起来最贵

3.1 核心表结构与关键字段取舍

数据库这块我建议花整个项目30%的时间。表结构定错了，后面每改一次都要动实体、动Mapper、动前端，成本是滚雪球式的。

核心表大概十张左右：user、role、user_role、category、product、cart、orders、order_item、address、comment，再加上recommend_log和banner做扩展。这里重点说几个容易设计错的。

product表，字段远比你想的多：

价格用decimal不用double，这是硬规矩。double在二进制里存不了精确的0.1，做金额运算会出现19.899999999999999这种结果，结算时差一分钱用户就投诉。库存字段建议加个version做乐观锁，后面讲超卖时会说。

orders表最关键的字段是order_no，别用自增id当订单号。自增id会暴露你的订单量，而且看着不专业。生成规则用"年月日时分秒 + 6位随机数"，比如20240518143025+384712。

order_item表必须做快照。什么意思？下单时把商品的名称、单价、图片都存一份到订单明细里，不能只存product_id。原因很实在：三个月后商品改价了或者下架了，用户翻历史订单看到的金额必须是他当时付的钱，如果只关联商品id，显示出来的就是现在的价格，数据就错了。这是数据库设计里最典型的"快照"思想，写进论文里是加分项。

3.2 冗余字段要不要加，看查询频率

教科书上讲究第三范式，实际项目里适度冗余是必须的。举两个例子：

product表里的sales和good_rate就是冗余字段。严格范式下，销量应该count(order_item)算出来，好评率应该查comment表算平均。但首页要展示20个商品，每个都去count一次，就是20次子查询。所以我选择在下单成功和评价提交时，用一条update把这两个字段更新掉，查询时直接读。

同样，orders表里存了receiver_name、receiver_phone、receiver_address三个字段，而不是只存address_id。因为用户可能删掉地址簿里的旧地址，但订单的收货信息必须永久保留。

冗余的代价是数据一致性要靠代码保证，所以这类更新一定要放在事务里，且要保证所有修改入口都覆盖到。我的做法是：把所有涉及冗余字段的更新，统一收敛到Service层的一个私有方法里，别在多个地方零散地写update。

3.3 索引与初始化数据的实操细节

索引不要乱加。我见过的典型配置是：product表的category_id、status、name建索引，orders表的user_id、order_no、status建索引，order_item表的order_id建索引。联合索引的字段顺序按"区分度高的在前"排，比如(status, category_id)就比反过来好。

初始化数据这块有个小坑：很多同学的sql脚本里中文注释或中文数据导入后是乱码。检查三处：数据库字符集必须是utf8mb4，连接串要带characterEncoding=utf8mb4，MySQL 8的连接URL还要带serverTimezone=Asia/Shanghai，否则时间会差8小时。这个时区问题特别隐蔽，表现出来是订单创建时间比实际早8个小时，排查起来要看好久。

spring: datasource: url: jdbc:mysql://localhost:3306/caihe?useUnicode=true&characterEncoding=utf8mb4&serverTimezone=Asia/Shanghai&useSSL=false username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver

注意驱动类名是com.mysql.cj.jdbc.Driver，不是老版本的com.mysql.jdbc.Driver，写错会警告甚至连接失败。

4. 优选推荐模块：这是题目的灵魂，也是最容易被追问的部分

4.1 三种能落地的推荐策略，从简单到复杂

"优选"两个字是这个题目的核心卖点，但很多人做到最后只是把商品按销量倒序排一下就叫推荐了，答辩一问就露馅。我推荐按难度分三层来做，做不完至少做前两层。

第一层是规则加权排序，也叫基于内容的推荐。每个商品算一个综合分，按分数倒序展示。这个实现最简单，效果也最可控，因为它不依赖用户行为数据，冷启动阶段就能用。

第二层是基于标签的偏好匹配。用户注册时选几个偏好标签（叶菜、根茎、菌菇、水果），或者从历史订单里自动提取品类偏好，推荐时给匹配的商品加权。

第三层是协同过滤。基于"买了A的人还买了B"或者"和你口味相似的人喜欢C"。这一层可以作为亮点写进论文，但实际数据量太小的时候效果很差，需要做降级处理。

4.2 综合评分公式怎么定，参数怎么算

规则加权的核心是一个公式。我这里给一套实际用过的：

score = 0.30 * 销量归一化分 + 0.25 * 好评率 + 0.20 * 时间新鲜度 + 0.15 * 价格亲和度 + 0.10 * 标签匹配度

每一项都要先归一化到0到1之间，否则量纲不同没法加。具体怎么算：

销量归一化用最大最小值归一化：(sales - minSales) / (maxSales - minSales)。如果所有商品销量一样（分母为0），直接给0.5，别让它抛异常。用对数归一化log(1+sales)/log(1+maxSales)效果更平滑，因为头部商品的销量往往是长尾的几十倍，线性归一化会把其他商品全压成接近0。

时间新鲜度用指数衰减：exp(-λ * 上架天数)。λ取0.05的话，上架7天新鲜度是0.70，30天是0.22，90天是0.011。这个参数λ要根据品类调，叶菜类衰减快（λ=0.1），粮油类几乎不变（λ=0.01）。

价格亲和度需要一个用户的价格偏好。简单做法是取用户历史订单的客单价，然后算1 - |商品价格 - 客单价| / 客单价，超出范围归0。没有历史数据时给固定的0.5。

标签匹配度就是用户偏好标签和商品品类标签的交集比例，完全不匹配给0，全匹配给1。

这套公式的参数不是拍脑袋定的，权重0.30给销量是因为生鲜场景下"很多人买"确实是最强的信号；0.20给新鲜度是因为生鲜损耗快；价格只给0.15是因为价格敏感度因人而异。写论文的时候，这几个权重的理由要讲清楚，这比公式本身更重要。

4.3 协同过滤的简化实现与冷启动兜底

完整版协同过滤要算用户相似度矩阵，工程量大且在小数据量下效果差。我建议用简化版：基于物品的共现推荐。

思路很简单：统计每个用户的历史订单，得到"商品A和商品B被同一个人买过"的次数，存到一张item_similarity表里。推荐时，取用户最近买过的3个商品，查它们的高相似商品，按共现次数排序，去掉已买过的，取前N个。

-- 计算共现（简化示意，实际在Service层做） INSERT INTO item_similarity (item_a, item_b, score) SELECT a.product_id, b.product_id, COUNT(*) AS score FROM order_item a JOIN order_item b ON a.order_id = b.order_id AND a.product_id < b.product_id GROUP BY a.product_id, b.product_id HAVING COUNT(*) >= 2 ON DUPLICATE KEY UPDATE score = VALUES(score);

这个任务放在定时任务里每天凌晨跑一次，或者手动触发生成。注意a.product_id < b.product_id这个条件，它保证(A,B)和(B,A)只存一条，避免重复计算。

冷启动兜底必须做。新用户没有任何订单，协同过滤给出的结果为空，这时候要降级到"规则加权排序"的结果。同理，新商品没有销量和评价，就按上架时间和分类热度给一个基础分。降级链路要在代码里写清楚，if (推荐结果为空) return 规则推荐();，这一行代码在论文里可以解释成"多级推荐降级策略"，是实实在在的工程考量。

心得：推荐结果一定要做打散。同一个分类的商品最多连续出现2个，否则用户看到一屏全是青菜，体验很差。打散的实现就是在结果列表上做一次贪心扫描，同分类计数超限就往后找下一个不同分类的商品。

5. 核心业务链路：从加购到签收的完整状态流转

5.1 购物车与库存扣减，超卖问题必须解决

购物车本身不复杂，cart表存user_id、product_id、quantity，加购时查一下有没有，有就累加，没有就插入。但这里有个商品下架的边界：用户三个月前加购的商品可能已经下架了，结算时要过滤掉并提示。这个逻辑要在结算页的接口里做，不能等到提交订单才校验。

真正的问题是库存扣减。经典的错误写法是这样：

// 错误示范：并发下必超卖 Product p = productMapper.selectById(id); if (p.getStock() >= quantity) { p.setStock(p.getStock() - quantity); productMapper.updateById(p); }

两个请求同时读到库存10，都判断通过，各自减1，最终库存变成9，但实际卖出了2件。这就是超卖。

正确做法有两条路。一条是乐观锁，在product表加version字段：

// 乐观锁方式，MyBatis-Plus自带支持 UpdateWrapper<Product> uw = new UpdateWrapper<>(); uw.eq("id", productId) .ge("stock", quantity) .setSql("stock = stock - " + quantity) .setSql("version = version + 1"); int rows = productMapper.update(null, uw); if (rows == 0) { throw new BizException("库存不足，请调整数量"); }

关键是ge("stock", quantity)这个条件，它把"判断"和"更新"合并成了一条SQL，数据库层面保证原子性。rows == 0说明库存不够，直接抛业务异常。这种方式不需要额外组件，是最推荐的方案。

另一条是Redis预扣减，把库存放到Redis里用decrement原子操作扣，扣成功再异步落库。这个方案性能好，但引入了一致性问题（Redis扣了但数据库没落成功怎么办），需要补偿机制。毕业设计的量级完全用不上，不建议为了炫技引入。

下单流程我建议全部包在一个@Transactional方法里，顺序是：校验库存 → 扣库存 → 生成订单主表 → 批量插入订单明细 → 清空购物车对应商品 → 更新商品销量。任何一步抛异常都回滚。但要注意，事务里不要有远程调用或耗时操作，否则会长时间持有数据库连接，并发一高就连接池耗尽。

5.2 订单状态机，用常量类管住状态值

订单状态不要用魔法数字满代码乱飞。定义一个常量类或者枚举：

流转必须校验合法性。用户不能把"已完成"的订单改成"待支付"，运营也不能跳过"已支付"直接改成"配送中"。写一个changeStatus(orderId, fromStatus, toStatus)的方法，SQL里带上and status = #{fromStatus}的条件，更新影响行数为0就说明状态已经被别人改过，抛异常提示"订单状态已变更，请刷新"。

这种写法叫状态机乐观校验，它能天然防止并发下的重复操作。比如运营点了两次"发货"按钮，第二次会因为状态已经不是"待拣货"而失败，不会重复发货。

5.3 定时任务：超时未支付订单的自动取消

订单创建后30分钟未支付要自动取消并回滚库存。这个功能用Spring的@Scheduled就能实现，不需要引入Quartz：

@Component public class OrderTimeoutTask { @Scheduled(fixedDelay = 60000) // 每分钟扫一次 public void cancelTimeoutOrders() { LocalDateTime deadline = LocalDateTime.now().minusMinutes(30); List<Order> list = orderMapper.selectList( new LambdaQueryWrapper<Order>() .eq(Order::getStatus, 0) .lt(Order::getCreateTime, deadline) .last("limit 100")); for (Order o : list) { try { orderService.cancelAndRestoreStock(o.getId()); } catch (Exception e) { log.error("取消超时订单失败, orderId={}", o.getId(), e); } } } }

几个细节要注意。第一，必须加limit，否则某天积压了几万条订单，一次全查出来直接OOM。第二，单条失败不能影响整批，所以循环里要try-catch。第三，扣库存和还库存的方法要对称，退款和取消都用同一个恢复库存的方法，避免逻辑不一致。第四，@Scheduled默认是单线程的，如果任务执行时间长会和下一个周期重叠，建议在配置类里设置线程池大小，或者把任务的fixedDelay设得比预期执行时间长。

还有一个坑：如果部署了多个实例，定时任务会重复执行。虽然状态机校验能兜住（第二次取消时状态已经不是0了），但日志会很乱。小项目单实例部署就没这问题，写论文时提一句"当前采用单实例部署，多实例场景需引入分布式锁"就够了，别真去上Redis分布式锁。

6. 接口设计与安全，答辩最爱追问的地方

6.1 参数校验别手写if，交给注解

每个接口都手写if (name == null || name.trim().isEmpty())是灾难。用@Validated+ JSR-303注解：

@Data public class RegisterDTO { @NotBlank(message = "用户名不能为空") @Pattern(regexp = "^[a-zA-Z0-9_]{4,16}$", message = "用户名4-16位字母数字下划线") private String username; @NotBlank(message = "密码不能为空") @Size(min = 6, max = 20, message = "密码长度6-20位") private String password; @Pattern(regexp = "^1[3-9]\\d{9}$", message = "手机号格式不正确") private String phone; }

Controller方法参数上加@Validated或@Valid，校验失败会抛MethodArgumentNotValidException，在全局异常处理器里统一捕获，把第一个错误信息返回给前端。这样代码干净，规则集中，改规则只改一处。

要注意一个坑：手机号的正则别写死成^1[3-9]\d{9}$以外的奇怪形式，也别用网上那种超长的精确号段正则，容易误判。还有，正则里的反斜杠在Java字符串里要写成\\d，写成\d编译不报错但匹配会失效，特别隐蔽。

6.2 登录鉴权：JWT用起来注意三个点

JWT的方案是：登录成功后生成token返回前端，前端存localStorage，之后每个请求带在Header里，后端用拦截器解析。三个注意事项：

第一，secret别写死在代码里。至少放到application.yml，更好的做法是环境变量。

第二，过期时间要给合理值。太短用户体验差，太长不安全。2小时比较合适，配合刷新机制。毕业设计不做刷新也行，写论文时说"token有效期2小时，过期需重新登录"。

第三，密码必须加盐哈希。千万别明文存数据库，也别用MD5（彩虹表能查）。用BCrypt，Spring Security里有现成的BCryptPasswordEncoder，单独引入也没问题：

BCryptPasswordEncoder encoder = new BCryptPasswordEncoder(); String hash = encoder.encode("123456"); // 存这个 boolean ok = encoder.matches("123456", hash); // 校验用这个

BCrypt每次加密结果都不一样（因为随机盐），所以不能直接比较字符串，必须用matches。

拦截器设计上，除了登录和注册接口放行，其余全部拦截。角色权限再叠一层，用自定义注解 + AOP实现。有个细节：拦截器里解析完token，要把用户信息存到ThreadLocal里，Controller层直接取，不用每个方法都从Header解析一次。用完记得在afterCompletion里remove()，否则线程池复用会导致用户信息串号，这是个非常隐蔽但危害很大的bug。

6.3 SQL注入与文件上传，两个高频失分点

用MyBatis-Plus基本不会有SQL注入问题，因为它的条件构造器是预编译的。但要小心${}和#{}的区别：#{}是参数占位（PreparedStatement），${}是字符串拼接。排序字段动态拼接的时候很多人用${}，如果这个值来自前端就危险了。正确做法是前端传排序字段名，后端用白名单校验后再拼：

private static final Set<String> ALLOW_SORT = Set.of("price", "sales", "create_time"); if (!ALLOW_SORT.contains(sortField)) { sortField = "create_time"; }

文件上传这块，商品图片上传要校验三点：文件大小（不超过5MB）、文件类型（只允许jpg/png/webp）、文件名（用UUID重命名，不要用原始文件名，防止路径穿越和覆盖）。存储位置建议放在项目外的目录，通过Nginx映射访问，别直接放在src/main/resources/static下，因为打成jar包后那个目录是只读的，上传会失败。这个坑我第一次做的时候踩得结结实实，本地跑得好好的，一打包部署就传不上去。

7. 论文写作：代码之外的另一半，别到最后才动笔

7.1 章节结构怎么搭才不空洞

系统做完了但论文写不出来，是这类题目最普遍的困境。原因通常是代码和文档脱节——写代码的时候没记设计决策，回头补只能编。我的建议是边做边记，每个模块做完就写下"为什么这么做"。

常规的章节骨架是：绪论、相关技术介绍、需求分析、系统设计、系统实现、系统测试、总结与展望。这个结构没问题，问题出在"相关技术介绍"和"绪论"两章大量注水。前者抄一堆SpringBoot官方文档介绍，后者写一堆"随着互联网的发展"，查重率直接爆表。

我的处理方式是：绪论压缩到1500字以内，重点写"现有生鲜类系统在选品推荐上的不足"和"本系统要解决的具体问题"，用你自己的话描述场景，别用套话。相关技术章节控制在2000字，只写你真正用到的技术，且每项技术都要落到"我在哪个模块用了它、解决什么问题"，比如写Redis就说"用于缓存首页热销榜，将首页商品查询耗时从320ms降到40ms"，这比抄一百字技术介绍有用得多。

真正的重头戏应该在需求分析、系统设计、系统实现三章，这三章要占到全文的60%以上。

7.2 图表和测试章节怎么写才有说服力

图表是这类论文的评分重点，但很多人画的图是错误的。用例图只有角色和用例，不要把页面元素画进去；E-R图要标清主外键和基数；时序图要体现调用顺序，别把不相干的类画在一起；类图只画核心类，全画出来反而看不清。

测试章节最容易被写成"我点了按钮，功能正常"。这种描述没有任何价值。正确做法是写测试用例表：

并发测试这条特别加分，因为它证明你考虑过超卖问题。测试方法可以用JMeter或者简单的多线程脚本，跑完把结果截图放进去。

另外，性能测试哪怕只做一个接口也值得写。用Postman或JMeter压一下商品列表接口，记录QPS和平均响应时间，再对比加缓存前后的数据，这就是一节很扎实的内容。

7.3 答辩时最可能被追问的五个问题

根据我了解到的情况，这类系统的答辩追问高度集中在这几个点：

"你的推荐算法为什么这么设计？"答：从数据可得性出发，新系统没有足够的用户行为数据支撑协同过滤，所以主链路用规则加权保证可用性，辅链路用物品共现做个性化补充，并设计了降级策略。这个回答体现你懂边界。

"如果一万个人同时下单，你的系统会崩吗？"答：会，当前是单机部署。瓶颈在三处：数据库连接池、Tomcat线程数、库存行锁竞争。可行的优化方向是连接池调优、热点商品库存分离到缓存。承认局限比硬吹更可信。

"数据库为什么这么设计，符合第几范式？"答：主体满足第三范式，但product表的销量、好评率和orders表的收货信息是有意冗余，理由是查询性能和数