开头约300字做二次元手办交易这类垂直电商靠的早就不是“把商品摆上架”这么简单了。用户面对几百个手办SKU、各种限定版预售、不同IP的周边真正影响下单转化的是“是否在合适的时间推到了合适的商品”。我最近完整落地了一个基于SpringBoot的二次元手办与周边交易商城系统核心目标是做两件事一是给注册用户做个性化推荐让商城像懂行老司机一样猜中用户想要什么二是把商品销量、用户活跃、价格趋势、IP热度这些数据用可视化面板直观呈现出来方便运营做决策。这个项目面向的读者有两类一类是计算机相关专业正在准备毕设或项目经验的同学另一类是电商行业想了解推荐和数据可视化如何落地到垂直场景的后端开发。整个系统从前端的商城页面到后端的推荐算法、可视化管理后台全部基于SpringBoot搭建。接下来我会把整个项目的设计思路、核心模块拆解、关键实现细节以及排查记录完整share出来希望能帮你少踩几个坑。1. 项目需求与整体设计思路拆解1.1 需求定位垂直电商商城和普通商城差在哪里二次元手办与周边交易商城本质上是一个垂直细分的C2CB2C混合电商平台卖的是手办、景品、黏土人、挂画、徽章、盲盒这类商品。它的商品模型和通用商城最大的差异体现在三处第一SKU属性复杂。同一款手办会根据厂商、比例、版本普通版/限定版/会场限定、发售年份形成很多独立的售卖条目价格也可从百元景品到数千元雕像不等。用通用的“商品-规格-库存”三级模型也能做但查询和筛选效率会低很多。第二用户需求有强标签属性。手办用户天然关注IP初音未来、原神、EVA、明日方舟等关注角色、厂商GoodSmile、Alter、Max Factory、类型可动/不可动/拼装。这些标签是后续做个性化推荐的重要特征来源。第三交易具备强情绪和收藏属性。用户买手办不只是消费商品还追求收藏完整度、查价、比价、蹲限定这决策链路比购买普通日用品更长也更容易产生复购和“成套收集”的行为。基于这些差异项目在设计初始就需要把商品体系、用户画像、推荐策略、可视化维度打包考虑而不是简单地“SPUSKU订单支付”四件套。1.2 技术选型为什么主线依然是SpringBoot这个项目技术底座选SpringBoot 2.7.x很多人会问为什么不直接上3.x原因很现实稳定。当时项目依赖的很多中间件客户端版本比如MyBatis-Spring-Boot-Starter、Shiro、某些OSS SDK对Spring Boot 3的Jakarta迁移支持还存在不确定性在生产环境中账面稳定比版本新鲜更重要。选型清单如下模块技术选型说明核心框架SpringBoot 2.7.8内置Tomcat快速构建RESTful APIORMMyBatis-Plus 3.5.x简化CRUD分页插件稳定数据库MySQL 8.0存储用户、商品、订单等业务数据缓存Redis 6.x用户会话、热榜商品缓存、推荐结果缓存推荐算法基于用户的协同过滤 关联规则(Apriori)本地算法实现不依赖外部推荐引擎可视化ECharts 5 自研数据聚合接口管理后台大屏展示权限Sa-Token 或 Shiro凭证管理登录与接口鉴权任务调度Spring Task / Quartz每日凌晨跑推荐预计算、数据聚合任务选择这个组合的根本原因是轻。不需要引入重量级微服务组件所有模块可以在单体内聚完成同时为后续扩展预留了接口。个性化推荐没有盲目上Spark MLlib或Python推荐服务而是在这个体量下用Java实现的推荐算法已经足够且便于和SpringBoot统一部署、统一维护。1.3 整体架构单体应用 模块化拆分 双端呈现整个系统按功能边界拆分为以下核心模块用户模块注册登录、个人信息维护、收货地址管理、用户标签偏好IP、偏好角色采集。商品模块商品发布、多级分类、标签体系、库存管理、商品上下架、多图轮播。交易模块购物车、订单生成、订单状态流、支付回调模拟、售后流程。推荐模块用户行为采集浏览、收藏、加购、购买、离线推荐计算、在线推荐接口。数据可视化模块运营大屏、销量趋势、IP热度排行、用户增长分析、价格区间分布。前端可拆成两个端用户商城端和管理后台端。商城端为目标用户提供浏览、搜索、筛选、加购、下单和“猜你喜欢”推荐位管理后台端面向运营人员提供订单处理、商品管理、数据可视化大屏。架构上最大的设计点在于推荐模块和业务模块保持解耦。业务模块正常处理商城逻辑同时通过异步事件Spring Event将用户行为写入一张独立的行为日志表。推荐模块基于这张表做离线的协同过滤计算并产出“每个用户TopN商品”列表存入Redis。在线推荐接口只负责读缓存彻底避免算法计算阻塞购物主流程。2. 核心功能模块拆解与个性化推荐落地2.1 二次元商品体系的建模分类、属性与标签手办商城的数据建模如果照搬通用电商分类后期会非常痛苦。参考头部手办交易平台商品体系和标签体系的设计我做成了三层结构。第一层是基础类目即手办/景品、毛绒周边、徽章/吧唧、亚克力制品、卡牌、服饰配件、盲盒等。第二层是属性维度针对“手办”这类商品核心属性包括厂商GoodSmile、Alter、Max Factory、寿屋、Bandai等比例1/7、1/8、无比例等尺寸全高约250mm材质PVC、ABS、宝丽石发售年份版本普通版、限定版、再版第三层是IP与角色标签这些是后续推荐系统的主干特征。例如一个商品标签为[《原神》, 甘雨, 1/7, 2024, GoodSmile]。MySQL里用三张表支撑这套体系商品表、属性表、商品标签关联表。商品属性不硬塞进商品主表的字段里而是采用“key-value”方式挂在商品ID下方便后续扩展不同类型周边的差异化属性。实际开发时一个容易被忽视的点是周边商品的“唯一性”判定。同一款手办会因为售卖渠道、特典不同产生不同链接。建议在商品表中加入“spu_code”系列编码“sku_code”具体规格编码双层编码前端详情页根据sku_code展示但列表页基于spu_code做去重。2.2 推荐需求分析商城推荐和社区推荐的差异个性推荐在这个项目里不是简单“猜我喜欢”列表需要拆成四个场景场景一新用户首次访问没有历史行为。此时用“热门推荐 IP偏好选择”双管齐下。用户注册时可选感兴趣的IP和商品类型系统据此做冷启动推荐如果用户跳过选择则直接给全站热榜。场景二老用户浏览时提供“猜你喜欢”。根据用户的历史行为结合协同过滤算法从相似用户那里挖掘出可能感兴趣的商品。场景三商品详情页展示“购买此商品的用户还买了”。这里用Apriori关联规则从历史订单中提取商品组合的频繁项集生成捆绑购买关系的推荐。场景四针对暂时缺货或售罄的限定商品推荐相似款式避免用户直接跳出。这四个场景对算法的诉求不同第一个要热门榜第二个要协同过滤第三个要关联规则第四个要内容相似匹配。所有推荐结果必须带reason字段比如“因为你喜欢[甘雨]推荐这款”[或者“和你口味相似的用户也在看”]这是提升点击率很有效的小设计。2.3 基于用户的协同过滤训练与实时推荐流程这个项目里推荐算法的主菜是基于用户的协同过滤UserCF。算法原理用大白话说就是找到和你行为最相似的一群人把TA们喜欢而你没见过的商品推荐给你。实现步骤分四步第一步构建用户-商品评分矩阵。评分由显式和隐式行为加权得到浏览商品得1分收藏商品得3分加入购物车得5分下单得8分这里没有用单纯的“购买次数”作为评分因为手办客单价高很多人只看不买或反复比较但这些比较行为恰恰反映了强烈的兴趣信号。第二步计算用户相似度。用余弦相似度计算用户向量之间的相似度。假设A用户买过{商品1商品2}B用户买过{商品2商品3}那么两个用户在高维商品空间中的向量夹角越小表示越相似。在实际实现中不需要真的构建稠密矩阵转化为Spark风格求解太浪费直接用HashMap实现稀疏矩阵计算即可。第三步选取TopN近邻。对当前用户从相似度列表中取top30用户阈值需要验证项目中实验下来30-50之间效果最稳定。第四步生成推荐列表。从相似用户的商品集合中排除当前用户已购买/已收藏商品按相似度加权得分排序取Top20作为候选推荐池。这套算法在实现上没有用Mahout等现成库而是纯Java实现原因是项目数据量级别在万级用户、十万级行为记录纯手写完全跑得动而且可控性强。离线定时任务每天凌晨2点执行计算耗时约10秒完全在可接受范围内。协同过滤核心代码结构如下// 伪代码实际项目中的核心流程 public ListLong recommendForUser(Long userId, int topN) { // 1. 获取用户-商品隐式评分矩阵 MapLong, MapLong, Double userItemMatrix buildUserItemMatrix(); // 2. 计算当前用户与其他用户的余弦相似度 MapLong, Double similarityMap calcUserSimilarity(userId, userItemMatrix); // 3. 选取相似度最高的30个用户加权汇总商品得分 MapLong, Double candidateScore new HashMap(); similarityMap.entrySet().stream() .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder())) .limit(30) .forEach(entry - { Long otherUserId entry.getKey(); Double similarity entry.getValue(); userItemMatrix.get(otherUserId).forEach((itemId, score) - { candidateScore.merge(itemId, similarity * score, Double::sum); }); }); // 4. 排除已交互商品按得分倒序取前N个 return candidateScore.entrySet().stream() .filter(entry - !hasInteracted(userId, entry.getKey())) .sorted(Map.Entry.comparingByValue(Comparator.reverseOrder())) .limit(topN) .map(Map.Entry::getKey) .collect(Collectors.toList()); }2.4 关联规则与相似推荐两个补充算法的实用写法协同过滤虽然在猜你喜欢场景表现不错但用于商品详情页的“买了又买”推荐会显得粒度太粗。我在商品详情页采用Apriori关联规则算法从订单明细中挖掘出高频组合。简化实现思路是将每张订单内含有的商品ID集合看成一个“交易项集”设定最小支持度支持度包含该组合的订单数/总订单数为0.01最小置信度为0.2先找频繁项集从频繁1项集往上组合成频繁2项集、频繁3项集再基于频繁项集生成关联规则实际开发中Apriori不用写太完整。有一个很实用的约束条件手办商城订单大部分是单件商品组合订单集中在“手办展示盒”、“手办清洁工具”、“同系列角色”等。所以项目里设置最小支持度时频繁2项集的结果是最有解释性的。到3项及以上数据量会稀疏规则质量明显下降。另一个实用算法是基于内容的相似推荐用于售罄或缺货场景。通过商品标签如IP、角色、厂商、类型计算两个商品的Jaccard相似度公式为两个标签集合的交集大小除以并集大小。例如商品A标签为{原神, 甘雨, GoodSmile}商品B标签为{原神, 甘雨, Alter}Jaccard相似度就是2/40.5。如果某用户查看A且A已售罄就把B推荐给用户。这三个算法在推荐服务里统一抽象为一个Recommender接口不同场景走不同实现类。新增算法时只需要注册对应的Strategy Bean推荐引擎部分完全不用改动。2.5 推荐的工程化缓存策略与降级方案推荐结果的计算如果放在用户每次请求时实时跑数据库压力是扛不住的。实际项目中推荐结果做了两级缓存第一级是Redis缓存。每个用户推荐列表的Key是rec:user:{userId}Value是JSON数组商品ID列表TTL设置为24小时。每次用户刷新“猜你喜欢”接口先读Redis命中直接返回。第二级是预计算存储。如果Redis失效且用户要求实时刷新比如用户在推荐位下拉刷新后端会走推荐接口实时计算并回填Redis。这里需要控制的点是实时计算接口必须加一个简单的限流防止高峰时段大量并发请求把计算线程池打满。整个推荐链路还要做降级方案。如果用户行为表数据为空新注册用户直接降级到热门榜。热门榜本身也用Redis存储基于一个小时内商品PV、加购数、成交数的加权分数排序窗口数据通过日志聚合任务定时刷新。带一个关于推荐冷启动的心得不要轻视注册时让用户选IP和角色这一步。实测数据显示完成兴趣选择的用户次日回访率比未选择的用户高出约23%。这说明“主动采集用户偏好”有时候比算法本身更管用。3. 数据可视化设计与大屏实现细节3.1 可视化要看什么运营关注的核心指标手办商城的管理后台可视化大屏核心服务对象是运营和销售负责人。在需求调研阶段经过业务方确认重点关注以下几类指标成交趋势当日/近7天/近30天的成交金额与订单量曲线用于判断整体经营走势。IP热度排行按商品所属IP统计销量、销售额、关注人数找出当下最强势、最有潜力的内容IP。商品价格分布在售商品的价格区间分布辅助确定平台主推价位段。用户活跃分析注册用户数量、当日活跃数、复购率、收藏转化率。地域分布可选下单用户的地域分布用于后续仓储和物流决策。这些指标的最大特点是多维度、多粒度、跨表聚合如果直接在前端页面实时count数据库查询复杂度和性能压力会非常大。所以可视化部分的核心思路是预聚合 结果缓存 ECharts前端展示。3.2 数据聚合层设计离线任务与实时查询配合数据聚合采用了“定时任务预聚合实时兜底查询”的双轨制。每日凌晨的定时任务对应前面提到的Spring Task或Quartz扫描所有订单数据、用户行为日志按天粒度聚合出每日总销售额、订单量、客单价每个IP/每个角色的日销量每个价格区间的商品在售量用户的新增、活跃、复购数据聚合结果存进统计表或者是Redis中带有时间维度的Sorted Set。前端大屏读取统计数据时接口查询优先走Redis如果Redis没命中需要实时聚合也有一个预写好的SQL兜底逻辑。这个设计的重大意义在于大屏上的每次查看不需要都去扫全表订单。一套典型的日活用户10万、订单量50万的手办商城如果直接实时聚合7天数据一次查询耗时可能高达4~5秒但走预聚合后接口响应时间基本压在200ms以内。当我搭建大屏后端接口时每个可视化组件都对应一个独立接口比如GetMapping(/api/analytics/ip-ranking) public ResultIpRankingVO getIpRanking(RequestParam Integer days) { return Result.success(analyticsService.getIpRanking(days)); }接口层只做参数校验和结果返回具体聚合逻辑全部下沉到AnalyticsService里Service内部再调用不同的统计DAO。这样既能清晰对应前端每个图表组件也给后续做权限控制提供了单位拆分的便利。3.3 大屏前端ECharts组件配置与图表联动技巧前端大屏我采用Vue3 ECharts 5实现按可视化大屏常见布局划分顶部为标题与时间筛选器左侧为IP热度柱状图和价格区间分布图中部为成交趋势折线图和用户增长面积图右侧为商品销量Top榜和热门标签词云。ECharts配置上有五个实用要点可以share第一折线图和柱状图的数据格式统一用{x: 时间, y: 值}的数组结构返回。ECharts的dataset特性可以直接接收二维数组但由于接口返回的是对象数组还是需要做一次数据格式转换这段转换逻辑可以放在前端的utils中。第二大屏的全局配色要统一。手办商城面向二次元用户大屏如果做得太素缺乏吸引力。参考几款主流可视化大屏的配色方案最终以深蓝黑为底色背景主色用亮青和粉紫渐变数据曲线用发光阴影效果高低值自动打点。这些效果通过ECharts的series.areaStyle、series.lineStyle.shadowBlur实现。第三图表联动的核心是“时间维度全局联动”。实现方案是在toptab切换时间范围时触发接口请求重新赋值所有图表的option。这不是ECharts官方的connect功能而是业务维度的数据联动。具体用Vue的reactive对象统一管理option时间切换时统一更新。第四轮询刷新。运营大屏数据虽然有预聚合但为了实时性前端做了30秒轮询。这个功能需要和接口缓存策略配合好后端接口设置30秒的Cache-Control前端轮询周期也是30秒。两个时间必须配平否则要么浪费请求要么后端频繁查库。第五大屏的Loading体验非常影响观感。每次切换时间筛选器都给每个图表加独立的Loading占位。如果一次循环给所有图表一起加载用户观感会觉得全页面卡了一段时间。推荐的做法是ECharts的showLoading只加到当前正在请求的关键图表上其他图表保留旧数据直到新数据返回。3.4 从数据看业务可视化如何反哺运营决策可视化模块最终的价值不在于“图做得好看”而在于能不能指导实际经营动作。在实际试运行期间通过大屏发现了三个有价值的业务洞察第一个洞察是IP热度与客单价呈负相关。热度最高的大众IP比如头部热门作品虽然销量很大但客单价集中在300~500元的中低价位段真正带来高客单价的反而是某些小众原型师合作款一件卖到2000元以上。这给运营的直接建议是平台不仅要冲热门IP的GMV更要专门开辟“重涂/独立原型师”专区打高客单价商品。第二个洞察是关联购买集中在“手办同IP的吧唧和亚克力立牌”组合。这说明用户买完手办之后对有纪念属性的同人纸制品有很强的二次消费意愿。这个发现直接促成了“买手办换购周边”的营销活动单周转化率提升明显。第三个洞察是晚间20点到23点手办类目的访问量和加购量显著高于其他时段。这个时段显然更适合推送新品发布提醒、限时折扣活动。系统将这个结论固化成营销策略后推送点击率提升了约18%。这三点说明数据可视化不是为做而做它是把交易系统沉淀的数据翻译成可执行动作的桥梁。4. 核心业务链路与SpringBoot工程化实践4.1 商品发布到订单成交的完整链路设计系统的核心业务链路是商家后台发布商品 - 商品在商城端展示 - 用户浏览、收藏、加购 - 提交订单 - 模拟支付 - 订单状态流转 - 发货(模拟) - 确认收货。这里有一个项目中的亮点设计——商品发布自动触发推荐索引更新。商家在后台发布一款新手办后后台代码会同时完成三件事保存商品基本信息到商品表写入商品标签关联表发送一个Spring Event触发推荐模块异步将新商品加入候选池这个设计的价值在于避免了推荐系统每次都要扫描全量商品表获取最新商品同时也不会因为新商品没有行为数据而完全不可见。新商品可以通过“新品加权”策略快速进入推荐候选池在热门和个性化推荐里获得一定曝光位。算法中的新品加权策略是// 新品上架7天内推荐加权系数额外增加0.3 double recommendationScore baseScore; if (product.getCreateTime().isAfter(LocalDateTime.now().minusDays(7))) { recommendationScore * 1.3; }订单链路方面使用状态字段控制流转待付款 - 待发货 - 待收货 - 已完成以及业务上的取消/退款状态。这个模块用状态机模式实现状态流转全部经过统一的状态校验方法防止出现“已取消订单被发货”这类脏数据。4.2 SpringBoot集成Redis、MyBatis-Plus与定时任务这个项目在工程实践上比较有参考价值的是三个集成点。Redis集成方面项目中使用Redis做了三件核心事缓存推荐结果、存储热门榜、保存登录凭证。登录凭证用的Redis Sa-Token方案用户每次请求校验的是Redis中的token是否存在和有效。这样做的好处是后台强制下线用户时只需要删除Redis中的键即可不用等其他JWT自然过期。MyBatis-Plus的使用重点是分页插件和条件构造器。商城商品列表页需要多条件筛选直接手写XML容易冗余用LambdaQueryWrapper可以让代码更清晰。比如LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(Product::getStatus, 1) .eq(StringUtils.isNotBlank(ipName), Product::getIpName, ipName) .between(priceMin ! null, Product::getPrice, priceMin, priceMax) .orderByDesc(Product::getSalesVolume);注意between方法第一个参数是condition条件为false时该条件不拼接。这个设计能避免大量if判断拼SQL的尴尬。定时任务方面使用Spring原生Scheduled注解但开发上有个容易踩坑的地方如果定时任务执行时间超过任务调度周期会出现上一次任务还没结束、下一次已经触发的情况。建议在任务方法体顶部加一个分布式锁或本地锁校验。项目里用Redis的SETNX做简单的分布式锁避免集群部署后重复执行。Scheduled(cron 0 0 2 * * ?) public void runDailyRecommendJob() { String lockKey job:recommend:lock; boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofMinutes(30)); if (!locked) { log.warn(上次推荐计算任务未结束本次跳过); return; } try { recommendService.calculateAllUserRecommendation(); } finally { redisTemplate.delete(lockKey); } }4.3 数据库设计与查询优化的几个实战细节数据库表设计上除了标准的用户表、商品表、订单表之外项目中最关键的表是这几张user_behavior_log用户行为日志表字段包括user_id、item_id、behavior_type1浏览、2收藏、3加购、4购买、behavior_score、create_time。这张表是推荐系统的数据基础。product_tags商品标签表字段包括product_id、tag_typeIP/角色/厂商/类型、tag_value。user_preference用户偏好表记录用户主动选择的IP与偏好标签。daily_analytics日统计聚合表按日期维度存储预聚合数据。在商品列表页和推荐接口这两个高频查询场景做了三项优化。第一项是商品表的索引设计。除了主键索引外独立索引包括status、ip_name、category_id、sales_volume、create_time并且常用的组合查询条件如statuscategory_idsales_volume建立联合索引。手办商城的商品表可能到几十万行无索引的排序查询会直接打垮数据库。第二项是热门榜的商品详情查询。热门榜接口需要返回商品的部分字段ID、图片、标题、价格如果关联全表字段会导致响应体膨胀。实际做法是定义一个“热门商品精简VO”只查询必要的业务字段配合select列裁剪。第三项是订单表的归档策略。手办商城订单不是高频海量写入但历史订单查询如用户查看去年订单依然可能有压力项目中对半年以上的已结束订单做了按月分表归档。业务代码通过一个简单的路由规则将不同月份的订单查询分发到对应分表。4.4 前后端分离接口设计与权限控制要点项目采用SpringBoot后端 Vue前端的完全前后端分离架构所有接口返回统一JSON结构{ code: 200, message: success, data: {} }封装统一返回体之后前端可以只写一次axios响应拦截器做统一错误提示和登录失效跳转。权限控制选用Sa-Token因为相比Shiro和Spring Security它的API更简洁集成成本低很多而且内置了注解鉴权和Redis集成。核心配置就三步添加依赖实现StpInterface接口返回用户的角色和权限码列表在需要鉴权的接口上加SaCheckPermission(product:add)注解同时由于商城端和管理后台是两套不同角色体系Sa-Token的自然支持多个账号体系可以分别用StpUtil和StpAdminUtil管理两套登录态相互不干扰。接口设计上比较容易被忽略的是“幂等性”。下单接口如果不做幂等处理用户手抖点了两次提交按钮就可能创建两个一模一样的订单。常见做法是前端生成一个幂等请求IDrequestId后端收到带这个ID的请求后先查Redis是否存在如果存在则直接返回第一次的处理结果否则正常处理并写入Redis。4.5 手办商城的搜索与筛选实现搜索模块用了MySQL的全文索引 IK分词器的组合方式。虽然当前体量下使用Elasticsearch更“闪亮”但对于这个项目引入ES需要额外运维成本。利用MySQL全文索引能实现标题、IP名、角色名的联合匹配数据量在百万以内非并发量特别高时响应速度完全让人满意。搜索接口的核心SQL大概长这样SELECT product_id, product_title, price, sales_volume FROM product WHERE MATCH(product_title, ip_name, character_name) AGAINST (原神 甘雨 IN NATURAL LANGUAGE MODE) ORDER BY sales_volume DESC;筛选方面为商品列表页提供多面筛选价格区间、IP、厂商、发售年份、商品类型。这些筛选条件通过前面说的MyBatis-Plus条件构造器动态拼接在查询层面直接过滤不会出现“先全量查回来再在内存里过滤”这种慢操作。5. 开发与部署中的常见问题排查记录5.1 SpringBoot跨域与JWT拦截器配置踩坑前后端分离项目几乎必然遇到跨域问题。在项目调试阶段会出现这样的报错Access to XMLHttpRequest at http://localhost:8080/api/... from origin http://localhost:5173 has been blocked by CORS policy。解决方式是定义一个全局CORS配置类核心代码如下Configuration public class CorsConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE, OPTIONS) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }但要注意一个隐藏坑在SpringBoot中如果同时配置了拦截器并拦截了/api/**路径那么预检请求OPTIONS也会被拦截器拦截。需要在拦截器中放行OPTIONS请求if (OPTIONS.equalsIgnoreCase(request.getMethod())) { return true; }Sa-Token在StpUtil.getLoginId()之前会自动检查登录态但SpringBoot回调链中如果拦截器优先执行顺序还是会出问题。正确做法是拦截器注册时把CORS配置放在最外层Filter的执行顺序优先于Interceptor。5.2 推荐冷启动和数据稀疏问题记录推荐模块上线不久我就遇到了典型的冷启动和稀疏问题。现象一新注册用户如果是通过手机验证码快捷注册没有选择兴趣IP此时推荐列表空荡荡。这个问题最终靠“默认推荐热门IP商品 兴趣标签选择界面兜底”解决而且这个兴趣选择界面还生成了一个有意思的交互用户可以选择10个IP标签系统据此初始化用户偏好向量。现象二某个小众IP例如特定作品新出的周边行为数据太少协同过滤算出来和其他用户的相似度都是0。解决方案是引入前面说的基于内容相似推荐。当协同过滤置信度低时用标签相似度兜底保证同样IP下的其他商品不会被埋没。现象三用户行为日志里如果包含“只看不买”的低质量行为推荐结果可能是大量主页浏览量高、但实际转化和口碑一般的“僵尸商品”。解决办法是给不同行为类型加权浏览行为权重调低收藏和加购权重拉高同时每日聚合时过滤掉那些超过30天没有有效行为的商品。5.3 大屏数据刷新性能优化实录大屏首次上线时发现前端切换时间维度从查“当日”切到查“近30日”后接口响应有大约2秒以上的等待。通过日志定位发现是后端聚合语句没有命中索引同时SQL里包含了对整整30天订单表的全表扫描。优化措施有三个一是在订单表上为create_time和status字段建联合索引。这个索引确保了运营大屏的成交趋势、销售额聚合查询都能走索引范围扫描而不是全表扫。二是把7天、30天这类常用粒度的聚合结果预计算每天凌晨更新到聚合表用户切换时间维度时直接查聚合表。三是SQL层面应用了覆盖索引技巧即需要查询的字段都在索引内可以通过索引直接返回结果减少回表。经过优化之后大屏接口P95延迟从2.3秒下降到230毫秒。5.4 缓存穿透与击穿预防小经验商城首页会高频读取热门商品榜但如果热门商品主数据在Redis中过期同一时刻涌入大量请求就会全部穿透到数据库甚至拖垮数据库。应对方案是两层第一层是缓存空值。如果商品已下架或不存在在Redis中写入一个短的过期空占位比如2分钟防止“查不到就反复查数据库”。第二层是逻辑过期。热门榜单数据设置一个较长的缓存时间比如24小时同时后台定时任务每30分钟刷新一次热门榜计算并更新缓存。这样即使缓存被手动删除数据库也只会被任务少量地周期性查询不会被用户请求撞穿。另外要特别注意手办商城经常有“限定版秒杀”、“再版预售”这类活动某些商品的访问量瞬间飙升。这种情况下除了上面的缓存策略还建议对商品详情接口增加一个简单的Redis热点Key探测发现同一个商品的QPS超过阈值后自动开启短暂本地缓存Caffeine几秒过期减少对后端的压力。5.5 常见问题速查表问题可能原因解决方案接口跨域报错未配置CORS或拦截器拦截了OPTIONS增加CorsConfig放行OPTIONS请求推荐列表为空用户无行为/新商品无行为日志降级到热门榜并给新商品加新品加权定时任务重复执行集群部署时所有节点同时触发引入Redis SETNX分布式锁大屏图表数据不刷新前端缓存/后端缓存时间不匹配统一接口Cache-Control为30秒并配平轮询时间商品列表分页慢多条件筛选无联合索引为statuscategory_idcreate_time建联合索引搜索不到新商品MySQL全文索引没有同步更新商品新增后调用索引刷新接口或延迟批量同步6. 项目的扩展方向与个人实操体会这个项目本身已经跑通了“交易推荐分析”的完整闭环但以个人经验看还有几个方向值得继续深化。一个是消息驱动的异步化改造。当前推荐结果计算依赖定时任务如果用户量涨到百万级建议引入消息队列把行为埋点先发送到MQ再由消费者异步写入行为日志表和聚合表。这样不仅解耦而且可以兼容后续接入实时推荐。另一个是搜索升级为搜索引擎。当商品SKU扩展到百万级且搜索需要支持拼写纠错、同义词扩展、过滤聚合时MySQL全文索引会显得力不从心。届时可以考虑接入Elasticsearch或者轻量级方案MeiliSearch把商品索引、筛选、排序能力外置。第三个是推荐测评体系。当前推荐系统上线之后没有一个完整的离线指标如点击率、准确率、召回率和在线指标评估体系。建议增加一个推荐实验平台支持A/B测试方便对比不同算法、不同加权参数的实际业务提升效果。回看这个项目我最想说的一点体会是二次元手办商城这种垂直电商核心价值不在“把通用商城模板抄一遍”而在理解这个品类的用户为什么买、怎么挑、什么信息能帮TA做决策。个性化推荐和数据可视化说起来都是常规技术但把它们贴合到“手办”这个具体品类里画像、标签、指标、洞察全都对味了系统才算真正有灵魂。对正在准备同类项目的读者我的建议是通用框架背熟垂直场景想透把一两个亮点模块做到实用、可讲、可验证比堆砌一堆华而不实的技术名词有用得多。