企业官网建设流程全解析

1. 项目整体设计与思路拆解

1.1 这个项目解决的是什么问题

我当初动手做这个SpringBoot零食商城系统的时候，市面上现成的商城源码不少，但大多数都有三个痛点：一是代码臃肿，动不动就微服务全家桶，一个小商城压了一堆中间件，新手根本跑不起来；二是业务耦合太死，商品、分类、订单逻辑写死成一种模式，换一个经营场景就得大改；三是配套资料短缺，光给源码不给文档，数据库脚本还得自己倒推，部署过程全靠猜。

所以这个项目从一开始立项就定了个方向：用SpringBoot单体架构做一个功能完整的商城系统，同时把业务层抽离成可配置的双模版——一套代码既能跑零食商城，也能跑花店管理。这样做的好处很直接：对于学习SpringBoot的人来说，不用被分布式那套复杂度劝退，专心看核心业务代码；对于要拿去做课程设计或者毕设的人来说，多模板的亮点比普通商城源码要加分不少；对于真想跑一个线上小店的个人开发者，换套配置就能复用，省掉二开成本。

1.2 技术选型背后的考量

SpringBoot做商城系统，算是这个领域最主流的选择了。原因不外乎三点：自动配置极大降低了搭建成本，内嵌Tomcat让部署变成“打包-运行”两步；生态成熟，MyBatis、Spring Data JPA、Spring Security都有大量现成案例可抄；就业市场认可度高，现在大部分企业的Java后端岗位都要求SpringBoot，拿商城系统做练习项目，简历上能写的东西也扎实。

但这里有个取舍要说清楚。我见过很多人做商城系统，一上来就是Spring Cloud Alibaba那套，Nacos、Feign、Gateway全部上阵。如果只是练手或交作业，这属于典型的过度设计。商城系统的核心价值在于业务闭环——商品展示、购物车、下单、支付、库存扣减、订单状态流转——这些用单体架构完全可以承载，而且排查问题方便得多。等真到了需要水平扩展的阶段，再根据实际压力把订单、用户等服务拆出去也不迟。

双模版的设计也是同样的思路。零食和花店看起来是两种业务，但抽象到商城层面，骨子里是一样的：都有商品、分类、库存、订单、用户、结算流程。差异主要在命名风格、类目结构、营销玩法和少数字段上。所以我在设计时没有做两套系统，而是在一套系统里用配置驱动的方式切换“业态模板”，数据存储结构保持一致，只在展示层和部分业务规则上做区分。这个决定为后期维护省了大事。

1.3 双模版的核心设计思路

所谓“双模版”，我在实现上分了三个维度去解耦：

第一是配置维度。系统配置表里存了一个当前模式字段，值可以是snack或flower，启动时加载进内存缓存，前端渲染和后端逻辑都能读到。页面标题、Logo、默认分类、轮播图、店铺公告这些展示信息，全部根据模式动态读取，而不是写死在页面里。

第二是数据维度。虽然商品表是同一张，但分类表的seed数据分成了零食和花店两套。启动脚本里通过insert语句按模式预置数据，商品列表查询时也会根据模式过滤默认分类。库存、价格、销量这些字段两种模式共用，不需要额外拆分。

第三是业务规则维度。零食商城有“会员零食大礼包随机搭配”这种玩法，花店模式则突出“配送时间预约”“鲜花保鲜期提醒”，这些差异化逻辑我抽成了策略接口，在订单创建和商品详情的地方按模式注入不同实现。

这套设计的优点是代码复用率能达到90%以上，新增一个业态模板只需要扩充数据脚本和策略实现，基本不用动表结构。缺点也有，就是初次理解的抽象成本比“写死业务”的版本略高一些。但配合万字技术文档讲清楚分层之后，反而比东抄一块西抄一块更容易掌握。

2. 核心功能模块与数据库设计

2.1 功能模块全景

整个商城系统我按职责拆成了七个模块：用户端包括登录注册、商品浏览、购物车、订单管理；管理端包括商品管理、分类管理、订单处理、会员管理、轮播图设置；公共模块包括文件上传、地址管理、系统配置、日志记录。

用户端走的是标准商城流程。游客可以浏览商品和分类，加入购物车前需要登录。注册支持用户名密码方式，密码通过BCrypt加密存储。登录后进入商品详情页可以选规格、填数量、加购、立即购买，结算时选择收货地址提交订单。订单状态机包含待支付、已支付、待发货、已发货、已完成、已取消六种状态，后台发货后用户可以确认收货。

管理端按角色分开权限。管理员拥有全部菜单，运营人员只能操作商品和分类，订单人员只能处理订单。权限控制通过拦截器加注解的方式实现，没有引入太重的安全框架，但基本的防越权是够用的。商品管理支持上下架、修改库存、批量导入（通过Excel模板）、图片上传，图片存储走本地磁盘路径映射。

双模版在这套功能框架下的差异点集中体现在三处：首页装修结构（零食展示爆款零食瀑布流，花店展示主题花束专题）、商品属性刷新（零食有保质期和口味，花店有花材和保鲜期）、订单备注（花店额外支持配送时间预约）。这些差异走的是策略加模板渲染，核心表并没有分裂。

2.2 数据库表结构设计与关联关系

数据库我用的是MySQL 8.0，字符集选了utf8mb4，排序规则utf8mb4_general_ci。脚本总共包含12张业务表加1张系统配置表，配合索引和外键约束，在交付时一并提供了完整的建表脚本和预置数据脚本。

用户表（user_info）是商城的基础，字段包括用户ID、昵称、手机号、密码密文、头像URL、状态、注册时间。手机号做了唯一索引，密码存的是BCrypt结果，长度设为60，直接存明文是最容易被数据库审计发现的问题，这个点我在技术文档里特意标红提醒过。

商品表（product_info）核心字段有商品名、主图、轮播图（JSON数组）、详情富文本、原价、现价、库存、销量、浏览量、上下架状态、软删标记。为了支持零食和花店双模版，还加了一个template_type字段标记当前商品归属的业态模板，以及一个attributes字段用JSON存储扩展属性——零食存保质期、口味、净含量，花店存花材、寓意、保鲜期。这种设计避免了为两种业态分别建表导致的后期维护噩梦。

分类表（category_info）通过parent_id支持两级分类，零食模式下预置了坚果炒货、饼干糕点、肉干肉脯、糖果果冻等；花店模式下预置了玫瑰系列、百合系列、节日花束、绿植盆栽等。分类和商品是一对多关系，商品详情查询时联表带出分类名称。

订单相关拆成订单主表（order_info）和订单明细表（order_item_detail）。主表存订单号、用户ID、总金额、实付金额、优惠金额、订单状态、收货人、手机号、地址详细、订单备注、创建时间、支付时间、发货时间。明细表存商品快照、单价、数量、小计。特别要提的是明细表里做了商品快照字段，商品改名或删除了，历史订单依然能显示当时的商品信息。这在两个模板切换时尤其重要，避免花店模板下看到零食残留数据的尴尬。

营销相关设计了优惠券表（coupon_info）和购物车表（cart_info）。优惠券支持满减和折扣两种类型，用户在结算时可选择可用券。购物车表以用户为维度记录了加购的商品ID、数量、加入时间，一个用户一个商品只存一条记录，数量可以累加，这样前端渲染比较清爽。

系统配置表（sys_config）是双模版的心脏，字段就三个：config_key、config_value、config_desc。当前模式、店铺名称、店铺公告、运费模板、订单自动关闭时长，全放这张表里。启动时一次性load进内存，比每次查询都走数据库快得多。

2.3 核心表结构的建表脚本说明

这里贴一段我当时写商品表的核心SQL，有注释说明关键点：

CREATE TABLE `product_info` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '商品ID', `product_name` varchar(128) NOT NULL COMMENT '商品名称', `sub_title` varchar(255) DEFAULT NULL COMMENT '副标题/卖点描述', `main_image` varchar(255) DEFAULT NULL COMMENT '主图URL', `images` json DEFAULT NULL COMMENT '轮播图URL列表', `detail_html` text COMMENT '商品详情富文本', `category_id` bigint NOT NULL COMMENT '分类ID', `template_type` varchar(16) NOT NULL DEFAULT 'snack' COMMENT '业态模板: snack/flower', `original_price` decimal(10,2) NOT NULL COMMENT '原价', `sale_price` decimal(10,2) NOT NULL COMMENT '现价/售价', `stock` int NOT NULL DEFAULT 0 COMMENT '库存', `sales_count` int NOT NULL DEFAULT 0 COMMENT '销量', `view_count` int NOT NULL DEFAULT 0 COMMENT '浏览量', `attributes` json DEFAULT NULL COMMENT '扩展属性JSON', `status` tinyint NOT NULL DEFAULT 1 COMMENT '状态: 1上架 0下架', `is_deleted` tinyint NOT NULL DEFAULT 0 COMMENT '软删标记', `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), KEY `idx_category_id` (`category_id`), KEY `idx_template_type` (`template_type`), KEY `idx_status` (`status`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='商品信息表';

有几个设计细节想展开说说。images和attributes用JSON类型，MySQL 8.0天然支持，查询时可以用JSON_EXTRACT提取字段，但我在代码里选择了查出整行后在Service层用Jackson解析成List或Map，这样代码可读性更好，不用写一堆SQL函数。template_type单列索引是因为双模版场景下所有列表查询都会用这个字段过滤，索引收益很明显。is_deleted软删标记是商城系统的行规——商品删除不能物理删除，否则历史订单关联会断，所以列表查询条件一律要加is_deleted = 0。

3. 实操过程与核心环节实现

3.1 源码目录结构与启动流程

项目采用Maven标准结构，包路径按controller、service、mapper、entity、config、common、interceptor划分。拿到源码后导入IDE，第一步先别急着跑，要按顺序做三件事：创建数据库、执行初始化脚本、修改配置文件。

源码包里的sql目录放了三个文件：schema.sql是建表语句，data_snack.sql是零食模版预置数据，data_flower.sql是花店模版预置数据。先执行schema.sql，再根据你想要的模式执行对应数据脚本。如果你想两个模板数据都留着，可以两个脚本都执行，然后通过后台配置切换当前生效的模式。

配置文件application.yml有几个关键项要改。首当其冲是数据源：

spring: datasource: url: jdbc:mysql://localhost:3306/snack_mall?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 你的密码 driver-class-name: com.mysql.cj.jdbc.Driver servlet: multipart: max-file-size: 10MB max-request-size: 20MB server: port: 8080 servlet: context-path: / # 自定义配置项 mall: template: snack # 当前模板模式，snack或flower upload-path: /data/mall/upload/ # 图片上传目录

这里有个常踩的坑：MySQL 8.0以上版本必须指定serverTimezone，否则连接会报时区错误。还有password不要用中文注释里的占位符，直接换实际的数据库密码。upload-path建议改成绝对路径，在Linux服务器上可以创建专有的上传目录并赋予读写权限。

启动类就是标准的SpringBootApplication，直接运行main方法。启动成功后浏览器访问http://localhost:8080，系统会自动跳转到首页。默认管理员账号在data脚本里预置了，用户名admin，密码admin123，登录后台可以切换模板和做商品管理。

3.2 双模版切换机制的代码实现

双模版切换是项目的亮点，这里详细讲一下实现逻辑。系统配置服务在启动时通过ApplicationRunner接口把所有配置项加载到内存Map里，之后每次请求都通过getConfigValue方法读取。切换模板时，后台管理接口更新数据库配置并同步刷新内存缓存，前端页面通过一个Interceptor往Model里注入了当前模板的全局变量，所以Freemarker模板里可以直接用模板名拼接不同的首页布局。

核心代码如下，摘自TemplateConfigService：

@Service public class TemplateContextService { private final Map<String, String> configCache = new ConcurrentHashMap<>(); @Autowired private SysConfigMapper sysConfigMapper; @PostConstruct public void init() { List<SysConfig> configs = sysConfigMapper.selectAll(); configs.forEach(item -> configCache.put(item.getConfigKey(), item.getConfigValue())); } public String getCurrentTemplate() { return configCache.getOrDefault("mall.template", "snack"); } public void switchTemplate(String template) { if (!Arrays.asList("snack", "flower").contains(template)) { throw new IllegalArgumentException("非法模板标识"); } sysConfigMapper.updateValueByKey("mall.template", template); configCache.put("mall.template", template); } }

商品筛选和列表页通过TemplateContextService判断当前模板，查询商品时带上template_type条件。例如首页推荐位：

public List<ProductVO> getRecommendProducts() { String template = templateContextService.getCurrentTemplate(); return productMapper.selectRecommend(template, 4); }

对应Mapper里的SQL是在where条件上增加template_type的等值过滤，这个逻辑对所有商品相关查询通用。后台添加商品时会根据当前模式自动填充默认模板字段，比如零食模式弹出保质期输入框，花店模式花材多选。前端这块是通过Freemarker的if指令判断模板变量来显示不同表单区块。

这里要特别提醒一个容易出问题的点：商品数据是两个模板共存的，如果零食模式下的商品没有设置template_type=snack，它会默认归到零食类。所以预置脚本执行时一定注意顺序，花店脚本里的商品必须显式写入flower标识。好在脚本里已经处理好了，但如果你自己往数据库里插测试数据，很容易漏掉这个字段。

3.3 订单流程与库存扣减的实现细节

订单流程是商城系统的核心链路，我从下单到支付完成整个闭环串一遍代码逻辑。下单接口接收一个SubmitOrderRequest对象，包含地址ID、优惠券ID、商品条目列表和用户备注。Service层按事务处理，主要的执行顺序是：

@Transactional(rollbackFor = Exception.class) public OrderVO submitOrder(SubmitOrderRequest request) { // 1. 从购物车或直接购买参数中获取商品列表 List<OrderItemParam> items = request.getItems(); // 2. 循环校验商品状态与库存，并锁定 for (OrderItemParam item : items) { Product product = productMapper.selectByIdForUpdate(item.getProductId()); if (product == null || product.getStatus() != 1) { throw new BusinessException("商品不存在或已下架"); } if (product.getStock() < item.getQuantity()) { throw new BusinessException("商品库存不足: " + product.getProductName()); } } // 3. 计算商品总价，应用优惠券 // 4. 生成订单号，插入order_info // 5. 批量插入order_item_detail // 6. 批量扣减库存，增加销量 // 7. 清空购物车中已下单的条目 return OrderVO.fromEntity(order); }

锁库存用的是selectByIdForUpdate，也就是悲观锁。对于单体商城系统的并发量级，这完全够用，而且逻辑简单不容易出错。很多教程推乐观锁版本号方案，但真实商城场景下秒杀级别的并发如果不是单独做库存服务，乐观锁的失败重试反而把业务搞复杂。

库存扣减的SQL做了条件判断，避免超卖：

UPDATE product_info SET stock = stock - #{quantity}, sales_count = sales_count + #{quantity} WHERE id = #{productId} AND stock >= #{quantity}

这个UPDATE语句的返回值是受影响行数，如果为0说明库存扣减失败，直接抛出异常让整个事务回滚。这里用到了数据库行锁的原子性，比先查再改的方式稳妥得多。

订单支付模拟的是 “余额扣款”方式。系统给测试账号预置了虚拟余额，支付接口先校验余额是否充足，充足则扣减余额并把订单状态改为已支付。如果后面接真实支付，只需要替换PaymentService的实现，改成调用微信或支付宝的统一下单接口，异步回调时更新状态即可。这个扩展点在文档里也讲清楚了。

3.4 万字技术文档使用指南

配套的万字技术文档我按模块写了十一个章节，开头是快速上手，包括环境要求（JDK8+、Maven3.6+、MySQL8.0+）和部署步骤，接着按商品、购物车、订单、会员、双模版、权限、部署运维逐章展开，每章开头有功能截图配合文字说清楚页面操作和接口逻辑，后面附上核心代码片段和关键讲解。

文档里还有一个章节专门是FAQ，记录了我开发过程中遇到的问题。比如商品图片上传后无法访问，检查upload-path映射配置；后台修改模板后前端没变化，确认浏览器缓存并清理；数据库脚本执行失败，检查MySQL版本是否低于8.0以及utf8mb4字符集支持情况。

我的建议是拿到项目先别急着改代码，花一两个小时按照文档里的步骤把系统跑起来，然后跟着第二章把商品、分类、订单各操作一遍。熟悉流程之后再去读双模版那个章节，结合代码打断点看模板切换时内存里配置怎么变化，比单纯看文档理解深得多。文档最后还有个部署章节，教你怎么用Maven打包成jar后用systemd做开机自启，这部分对之后的服务器部署很关键。

4. 演示视频与学习路径安排

4.1 演示视频包含哪些内容

我录制演示视频的时候刻意控制在了25分钟以内，核心目的是让拿到项目的人能快速建立整体认知，而不是把代码逐行讲一遍。视频分为四段：第一段演示用户端购物流程，从注册登录到浏览商品、加入购物车、提交订单、支付；第二段演示后台管理，包括商品上下架、分类维护、订单发货、优惠券设置；第三段重点演示双模版切换，切换到花店模式后看首页、商品分类、商品属性、订单备注全部发生变化；第四段快速过一遍源码包结构，指明每个目录的作用。

视频按1080P录制，关键操作位置加了鼠标高亮显示，便于跟着操作时看清点击的位置。演示使用的数据就是数据脚本预置的样例数据，对零食和花店模板都做了完整走查，保证没有逻辑遗漏。

4.2 合理的学习路线参考

如果是以学习为目的，我给拿到源码的同学划一条比较高效的阅读路径。第一阶段先看entity里面的实体类，对照数据库表理解字段含义，大约占用半天；第二阶段看mapper层和对应的XML，理解SQL是怎么组织查询条件的，特别是双模版相关的那几个动态SQL，也差不多半天；第三阶段看service层，重点在订单Service的submitOrder、库存扣减和TemplateContextService的切换逻辑，建议打断点跟一遍流程；第四阶段看controller层，感知请求参数是怎么校验、怎么封装返回值的。

跳过controller先看service的好处是避免被HTTP层的细节干扰，先聚焦业务规则。等业务逻辑清楚了，再看controller反而非常快，基本一两个小时就能过完。前端的Freemarker模板建议最后看，因为双模版的页面切换逻辑散落在不同的ftl文件里，没有后端代码基础直接看容易绕晕。

4.3 视频演示里没有体现的细节

视频里我不会讲、但是实际操作中特别容易踩的细节有这几个。

第一是切换模板后需要刷新首页缓存。我在页面上做了一个简单的片段缓存，为了避免每次访问都查数据库导致首页太重。切换模板接口会主动清除缓存，但如果直接改数据库字段，缓存不会失效，页面就一直显示旧的模板内容。遇到这种情况重启应用或者调用缓存的刷新接口就能解决。

第二是图片上传的目录权限。本地开发如果在Windows上跑，上传目录随意设一个绝对路径即可。但部署到Linux服务器后，Java进程运行在哪个用户下，这个用户必须对上传目录有读写权限，否则图片上传直接报FileNotFoundException，而且这个报错不会提示权限不足，排查起来比较费劲。建议部署后先传一张图片测试。

第三是跨域问题。如果前端静态页面和后端接口分开部署，启动类需要加上CorsConfig。源码里已经内置了CORS配置，默认允许所有来源。生产环境建议收紧allowedOrigins，只配自己的域名，避免被其他站点抓接口。

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

5.1 部署运行阶段的典型问题

我整理了一份高频问题清单，每一个都是实操中真实出现过的，反复被遇到就先列在这里。

数据库连接失败，报Communications link failure。这种情况九成是MySQL服务没启动，或者端口不是默认的3306。先用命令行客户端测试本地连接是否成功，排除法确认是网络问题还是账号权限问题。如果是从另一台机器连数据库，MySQL默认bind-address可能只绑定了127.0.0.1，需要在my.ini里改成0.0.0.0并重启服务。

启动时报端口被占用。SpringBoot默认用的是8080，如果本机已经被其他项目占用，直接改application.yml里的server.port。也可以在启动命令里指定--server.port=8081，适合临时跑多个实例测试。

数据库脚本执行报错。检查脚本文件编码是否为UTF-8，Windows下用记事本打开再另存，很容易变成带BOM的UTF-8，MySQL执行会报语法错误。推荐用Navicat或DataGrip直接执行SQL文件，避免命令行编码问题。

商品图片列表加载不出来。确认application.yml里的upload-path路径末尾是否有斜杠，拼接URL时如果缺少会导致路径错乱。还要检查项目里WebMvcConfigurer的addResourceHandlers配置，把磁盘路径映射到/upload/**虚拟路径上的代码是否保留。

登录后台提示密码错误。默认账号admin/admin123只在首次执行数据脚本时初始化，如果之前改过密码或者执行过多次初始化脚本，后来再跑一遍脚本会把密码重置，但数据库中可能残留其他记录导致唯一索引冲突。建议确认业务数据可丢的前提下，先truncate相关表再重新执行完整脚本。

5.2 业务逻辑测试阶段的坑

商品上架了但前台看不到。检查两个地方：一是商品状态字段，status为1才是上架；二是template_type是否等于当前模板模式。后台商品管理列表和前台是按两个维度的过滤条件查的，后台默认不过滤模板，前台会加模板条件，所以后台看到有数据，前台没有就是模板类型不匹配。

下单时提示库存不足，但看了后台库存还有余量。回查商品查询逻辑里是否用了缓存。如果做本地缓存，库存变动接口没有同步更新缓存，那么显示的数据就是旧值。这个项目为简单起见商品详情没有做缓存，但你自己扩展时要注意保持一致。

切换花店模板后，首页轮播图和商品分类没变。首页分类导航在模板切换时只更新了分类下拉数据和推荐位数据，轮播图存储并未按模板隔离，所以还是零食模板上传的图片。要适配花店模板，需要在上传轮播图时也加上模板标识，或者简化处理：切换模板时用一套独立的轮播图数据，我在技术文档的双模版章节里专门讲了怎样扩展轮播图表字段来实现这个隔离。

优惠券在下单时没有被自动匹配。目前的实现是用户在结算页手动选择优惠券，没有做自动最优匹配。你如果觉得体验不好，可以写一个策略方法，遍历用户可用的优惠券，找到优惠金额最大的那个并选中。要注意满减券必须满足门槛，折扣券是否互斥，这个扩展在service层的applyCoupon方法里加循环即可。

5.3 疑难杂症的个人排查心得

说实话，做这类项目卡住时间最长的问题，往往不是技术本身，而是环境细节。我在写这个系统的过程中，遇到过本地跑得好好的、换一台机器就启动报错的案例，最后发现是JDK版本不一致，本地用了11，另一台机器是8，代码里不小心用了只有JDK11才有的String类方法。所以环境上要统一，项目pom.xml里设置了Java版本为1.8，你的IDE编译级别和运行环境的JDK版本一定要匹配，否则项目自带的环境变量会被IDE覆盖。

另外要养成阅读完整异常栈的习惯。SpringBoot的报错信息比很多传统框架友好，根因一般都在Caused by那一段，不要只盯着最上面的Exception名称看。我遇到过一次启动失败，最上面是NoSuchBeanDefinitionException，当时以为是某个Service没加@Service注解，排查半天，最后发现是mybatis的Mapper接口没有被@MapperScan扫描到，异常栈底部明确写着Invalid bound statement。所以说，栈里的最后十行往往才是真正答案。

还有数据库连接池的时区问题。这个已经提过，但值得再说一遍，因为真的很常见且隐蔽。不指定serverTimezone时，高版本MySQL驱动会默认使用JVM所在时区，如果你本机时区设置错误，所有时间字段的读写都会偏差好几个小时。统一指定为Asia/Shanghai是最省心的方案。

6. 项目扩展与二次开发建议

6.1 怎样升级成真正的线上商城

如果要把这套系统用于实际运营，有几个模块需要认真强化。支付一定要接真实的第三方支付通道，虚拟余额只能作为测试用，线上没有合规的支付渠道商家根本没法收款。支付回调通知需要设计幂等处理，防止重复通知导致订单状态错乱——用一个支付流水表记录回调记录，判断是否已处理，这是最直接的做法。

物流跟踪模块也是线上商城刚需。订单发货后要给每个包裹绑定物流单号，对接快递查询接口，用户可以在订单详情看到物流轨迹。这个功能写一个物流查询Service，把模板方法预留好，接快递鸟还是其他服务商看你的实际选择。

商品搜索当前只做了名称LIKE查询，数据量小时没问题，商品过万后性能会比较明显，建议引入全文检索方案。轻量方案是在MySQL里建全文索引，重量方案可以上独立的搜索引擎服务，但在单体架构下尽量别引入额外服务，全文索引足够撑住几万商品的搜索场景。

6.2 把双模版扩展为多模版

双模版证明这套思路可行后，很容易扩展到更多业态。比如“生鲜超市”模式、 “二手回收”模式，核心表结构完全不用动，每个模板新增一套预置数据和对应的策略实现类。前端模板目录下新增一套以模板名命名的文件夹，视图解析器按模板名动态选择即可。

扩展时重点留意模板之间差异过大的情况。比如零食模式用户关心生产日期和保质期，花店模式用户关心配送时间和保鲜期，而生鲜模式可能关心产地和冷链配送。差异变大后，attributes字段内的JSON结构就不再适合写死解析了，建议改成前端表单动态渲染加后端动态JSON提取，或者干脆为高差异模板单独建扩展表，用复合主键关联商品ID。我在文档的扩展建议章节里画过一张表，列出了不同业态可能需要的扩展属性，拿到手可以直接对照设计。

6.3 性能优化与部署建议

部署方案我推荐直接用一台轻量云服务器跑单机。配置1核2G起步，2核4G更稳，系统装Linux，环境装JDK8和MySQL8.0。打了包之后上传jar到服务器，按文档部署章节写的systemd服务配置做成开机自启，再配合nginx反代前端静态资源，后端只处理接口请求，简单可靠。

并发方面，单体系统瓶颈一般在数据库。对商城场景，读多写少，优先做首页和热门商品页面的缓存。本地缓存加进程内Caffeine就够用，做好淘汰策略和过期时间。如果有多台实例部署，需要把缓存改成Redis共享，否则一台服务器切换模板，另一台的缓存还是旧的。这些后续扩展的方向，我在技术文档中都标了TODO标记，方便接手的人快速定位改动点。

关于数据库层面，订单表增长速度快，建议按月份做分区或者分表。商城上线前几个月可以先不折腾，订单量上来之后再按月迁移，平时写SQL时注意带上订单时间的查询条件，这样分表后的改动成本会小一些。

7. 项目交付清单与关键文件说明

7.1 源码包完整内容

交付的源码包在压缩包里分成了四个目录，最外层是README.txt，建议先读这个。sources目录放的是完整Maven工程，不依赖外部私服，联网后自动拉取依赖；sql目录放初始化脚本；docs目录放万字技术文档和部署手册；video目录放演示视频。这个组织方式保证拿到包的人不需要到处找资料。

README.txt里我写了四行最重要的操作摘要：环境要求、数据库初始化步骤、启动方式、默认账号。很多同学拿到源码包喜欢直接解压丢进IDE，不看任何文档就开始敲命令，这时候README是最快引导，能少走很多弯路。

7.2 万字技术文档定位与阅读指引

万字技术文档是站在学习者角度写的，定位是“带读源码的导航图”。它不是API手册，不会逐个类给你列方法签名，而是按照一条完整业务链路——从用户发起请求到数据库查询再到响应返回——把关键节点串起来讲。

文档里面我用了相当多的表格做对照，比如双模版功能差异对照表、订单状态流转表、数据库字段说明表。表格比大段文字更能快速建立知识框架，读文档的时候建议先扫章节标题，再重点看表，最后回过来看正文。遇到源码和文档不一致的地方，以源码为准，文档写于代码完成之后，但偶尔会有笔误。

7.3 数据库脚本的执行顺序与维护建议

三个SQL文件的执行顺序非常重要：schema → data_snack → data_flower。schema建表是幂等的，重复执行会报“表已存在”错误，所以完整初始化时最好先手动把旧库drop掉或者使用CREATE TABLE IF NOT EXISTS的版本。data脚本中的INSERT语句如果重复执行会导致主键冲突，同样需要处理。我在交付的脚本里写了可重复执行的保护逻辑，如INSERT IGNORE，但为了干净，还是建议初始化时清空业务表再执行。

后续想重置演示数据，直接执行一个reset.sql即可，它会truncate所有业务表并重新执行预置脚本。这个脚本放在sql目录的example子目录下，属于运维辅助脚本，文档的FAQ章节有说明。

维护时有个建议：数据库脚本应该纳入版本管理，每次结构变更都要生成新的迁移脚本，不要在原脚本上改，不然其他人拿到了新旧版本对不齐。我这次交付就按这个习惯，保留了v1.0初始化版本和迁移示例，方便你看到版本演进的写法。

8. 一些建议与注意事项汇总

8.1 学习阶段的三个建议

第一，不要急着改功能，先把系统完整跑通至少三遍。第一遍按正常用户操作，第二遍带着问题看日志，第三遍自己用调试模式打断点逐步看Service层的执行流程。三遍下来，你看代码的感觉会完全不一样。

第二，刻意练习读异常信息。每次报错不要只截图然后直接搜解决办法，先自己读一遍异常，猜猜可能是哪一层出的问题。读多了之后，你会形成条件反射：看到ClassNotFoundException想到依赖缺失，看到DuplicateKeyException想到唯一索引冲突，这种能力在真实开发中比会写代码更值钱。

第三，写一份属于自己的技术笔记。不用长篇大论，就把你在这个项目里学到的SpringBoot注解、MyBatis写法、订单状态流转逻辑，用自己的话写下来。能用自己的话讲清楚，说明是真懂了。我这个项目的万字文档其实也就是从笔记整理出来的。

8.2 二次开发的编码规范提示

代码规范我遵循了阿里巴巴Java开发手册中的基础约定：类名首字母大写驼峰，方法名小写驼峰，常量全大写下划线，Service接口与Impl实现分离，Controller只做参数接收和响应包装，不写业务逻辑。

在MySQL命名上，表名单数小写下划线，字段名也是小写下划线风格。这里有个容易忽略的细节：Java实体属性用的是驼峰，但数据库字段是下划线，MyBatis需要在配置里开启map-underscore-to-camel-case=true，项目默认已经打开，但如果你自己新建表，也要注意字段和实体属性的映射。

对于状态字段，我用的是tinyint整数枚举而非字符串，省空间且查询效率高。代码里定义了对应的枚举类，前后端传值用数字，展示层转换为文字。你把枚举类里的value和desc对应关系记住，以后改状态显示文案不用动表数据。

8.3 遇到问题时的排查顺序参考

如果你运行中遇到问题，我建议按这个顺序排查：先看控制台有没有异常堆栈，有就定位带Caused by的那一段；没有异常但功能不对，检查日志里有没有打印参数，用日志确认Controller是否收到请求；再往后是Service和Mapper的参数传递是否正常，最后看SQL在数据库客户端单独执行是否返回预期结果。

最高效的方式是在Mapper接口方法上加日志输出，打印执行的SQL和参数内容。MyBatis的日志是系统输出，源码里通过logback配置了输出。真正查问题查多了你会发现，大多数“奇怪的问题”，最后都归结为参数和预期不一致或环境差异，没有那么多玄学。

9. 写在最后的个人心得体会

9.1 我在完成这个项目后的几点深刻体会

做这个项目前后花了大概一个多月，回想起来最有价值的不是代码本身，而是做架构决策时想的那些为什么。为什么要用单体？为什么要做双模版？为什么库存扣减用悲观锁？这些取舍背后是对场景的深入思考。任何方案都有适用边界，找到最适合当下需求的方案，比一股脑搬最流行技术要重要得多。

关于双模版的实现，我现在回头看其实也可以做得更彻底一点。比如把模板配置体系升级成一套可动态注册的机制，新增模板不用改代码，像搭积木一样选择模块、挂载字段、设置规则。但目前通过配置加策略的实现，对于学习项目来说恰好够用，太抽象反而丧失可读性。

写技术文档的那段时间反而是我收获最大的阶段。把脑袋里零散的知识点整理成别人能看懂的文字，这个过程逼着我把每个“大概是这样”的地方都查证清楚，把很多模糊认识补扎实了。所以我真的很建议大家，学完一个项目之后试着写一篇自己的技术总结，不论长短。写出来的东西，才真正长在你身上。

9.2 最后再分享两个实用小技巧

第一个是数据库连接字符串里加几个参数能省掉很多麻烦。我在application.yml中额外配置了initialSize=5、maxActive=20这些连接池参数，以及validationQuery=SELECT 1。这样即使数据库重启过，连接池也能自动检测并重建连接，不会出现网页突然打不开、重启应用才恢复的情况。别小看这一行，它救过我很多次。

第二个是前端调试时用浏览器开发者工具的Network面板。我自己看页面问题从来不直接翻代码，先在Network里看是哪个请求返回异常，再点进请求看请求参数和响应内容。前端报错多半是接口返回不符合预期，用这个方式定位是前端渲染错误还是后端逻辑错误，效率高出太多。

希望这篇总结能帮助你把项目跑起来，也帮你在阅读源码时少走一些弯路。如果你在学习过程中有自己的想法和改进，非常欢迎在评论区聊聊，动手改一版属于你自己的玩法，那才是这个源码真正送给你的礼物。