简介一套基于前后端分离架构的SpringBoot天猫商城整站源码面向Java Web学习者与初级开发人员用于理解电商系统从用户端到管理端的完整实现。项目整合SpringBoot、BootStrap、Vue.js、JQuery、Thymeleaf3、JPA、Redis、Shiro与Elasticsearch覆盖页面渲染、数据持久化、缓存、安全认证及商品搜索等核心环节。资源共2000个文件以jpg图片、html页面、java源码为主另有js、css、sql及配置文件可满足前端展示、后端逻辑与数据库初始化需求压缩包约287MB。目前已有530人学习下载。通过该资源可快速搭建可运行的天猫风格商城参考前后端分离落地方式、Shiro权限控制逻辑、Elasticsearch与SpringBoot整合方案并借助大量静态资源与部署文件减少环境配置成本适合作为课程设计或毕业设计的起步蓝本。1. 这个项目到底是什么样SpringBoot 电商商城的一次完整拆解tmall_springboot 这套电商商城项目拿到手第一件事不是启动 SpringBoot而是先把 Redis 和 Elasticsearch 跑起来否则登录验证码报错、商品搜索直接白屏这一下就能劝退不少人。项目本身是 SpringBoot 作为主骨架的单体应用但内部把 JPA 持久层、Redis 缓存、Shiro 权限认证、Elasticsearch 商品检索、BootStrap Vue.js JQuery 前端三层全串起来了覆盖了电商系统最核心的「用户、商品、购物车、订单、搜索」闭环。适合两类人一类是准备用完整项目做毕设或简历项目的人另一类是已经在 SSM 里写过 CRUD、想看看 SpringBoot 技术栈怎么组织多模块协作的开发者。下面按我的拆包习惯从数据层到权限层再到检索层逐个说清实现逻辑和踩坑点。2. SpringBoot JPA 数据模块实体关系与仓储层的关键细节2.1 为什么这个项目选 JPA 而不是 MyBatis拆过 SSM 项目的开发者在面对 JPA 时通常有抵触心理觉得 MyBatis 写 SQL 更直观。但这个项目选 JPA 有它的合理性电商商城的核心操作是单表 CRUD、主子表级联保存和分页查询这类场景用 JPA 的实体映射和方法名派生查询代码量比 MyBatis 的 XML 少一半。比如保存订单要给订单主表、订单明细表、商品库存三处落数据JPA 里只需要维护好实体关系调用orderRepository.save()就能级联写入不需要手写三条 INSERT。JPA 和 MyBatis 的取舍可以简单看成下表这样关注点JPA本项目选型MyBatis单表 CRUD仓储接口零实现需要写 SQL 或通用 Mapper主子表级联写支持级联保存需手动控制事务和多条 SQL复杂多表联查需要 JPQL/JPA Specification原生 SQL 更顺手缓存与二级缓存配合 Redis 较方便基本靠外部缓存学习曲线实体关系概念多SQL 门槛低实际翻代码时会发现项目里凡是要做动态条件查询的地方还是用了 JPA 的 Specification类似 JPA 版的多条件拼装器并没有硬用方法名派生去拼一个很长的查询接口。这说明作者在选型时是有边界的CRUD 交给 JPA复杂查询用 Specification 兜底。你如果之后接了个需要大量联表报表的需求再用 MyBatis 也不矛盾两个 ORM 共存是常见做法。2.2 核心表结构与实体关联写法不管前端页面有多少个电商后台的数据模型万变不离其宗。这个项目里以会员、商品、分类、购物车、订单五类表为骨架。商品和分类是多对一订单和订单明细是一对多购物车和会员是多对一。表结构大致如下CREATE TABLE t_member ( id BIGINT PRIMARY KEY AUTO_INCREMENT, username VARCHAR(50) NOT NULL UNIQUE, password VARCHAR(100) NOT NULL, nickname VARCHAR(50), status TINYINT DEFAULT 1, create_time DATETIME ); CREATE TABLE t_category ( id BIGINT PRIMARY KEY AUTO_INCREMENT, name VARCHAR(50), parent_id BIGINT DEFAULT 0, sort_order INT DEFAULT 0 ); CREATE TABLE t_product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, title VARCHAR(200), subtitle VARCHAR(200), main_image VARCHAR(500), detail TEXT, original_price DECIMAL(10,2), discount_price DECIMAL(10,2), stock INT DEFAULT 0, sales INT DEFAULT 0, category_id BIGINT, status TINYINT DEFAULT 1, create_time DATETIME );建表时的几个关键选择username加了 UNIQUE 约束从数据库层面防止注册时同步写入的并发冲突金额字段用DECIMAL(10,2)而不是 FLOAT避免浮点精度导致订单价格对不上status字段统一做逻辑下架而不是物理删除这样商品详情页的历史订单还能追溯到商品快照。父分类用parent_id加0表示顶级分类二级分类就指向一级分类的 id这是大部分商城通用的无限级分类简化版。实体映射里最容易出错的是create_time的自动填充。项目里通常会用PrePersist在插入前统一补齐时间字段而不是让每条插入语句手动写当前时间。Entity Table(name t_product) public class Product implements Serializable { Id GeneratedValue(strategy GenerationType.IDENTITY) private Long id; Column(name title, length 200) private String title; Column(name discount_price, precision 10, scale 2) private BigDecimal discountPrice; Column(name stock) private Integer stock; ManyToOne(fetch FetchType.LAZY) JoinColumn(name category_id) private Category category; PrePersist public void prePersist() { if (createTime null) { createTime new Date(); } } }这段代码的关键在两处。第一处是GeneratedValue(strategy GenerationType.IDENTITY)它依赖数据库自增主键插入后 JPA 会自动把生成的 id 回写到实体。如果改成TABLE策略在高并发插入时会产生额外的锁竞争电商场景没必要这么干。第二处是ManyToOne(fetch FetchType.LAZY)商品挂分类用了懒加载这样查询商品列表时 JPA 只查商品表本身不会自动把分类带出来。但懒加载在接口返回 JSON 时容易触发序列化异常这是一个高频坑我放到第 5 章专门讲。2.3 Repository 层方法名与分页参数的配合项目的数据访问层全部继承JpaRepository它自带save、findById、findAll、deleteById等基础方法。电商项目使用频率最高的查询是「按关键词模糊查商品」「按分类查商品并排序」「分页查订单」这些能力不需要手写 SQL。public interface ProductRepository extends JpaRepositoryProduct, Long { // 按标题模糊查询 ListProduct findByTitleContaining(String keyword); // 按分类和上下架状态查询按销量倒序 ListProduct findByCategoryIdAndStatusOrderBySalesDesc(Long categoryId, Integer status); // 分页查询 PageProduct findByStatus(Integer status, Pageable pageable); }findByTitleContaining由 JPA 根据方法名自动生成 SQL等价于WHERE title LIKE % ? %。findByCategoryIdAndStatusOrderBySalesDesc一眼能看出查询条件先按分类 id 过滤、再按上下架状态过滤最后按销量降序排适合用在「分类页销量排行」这种场景。分页参数Pageable是从 Controller 传入的常见的写法是PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, createTime))。有两个细节需要留意page从 0 开始前端传 1 时后端要page - 1Sort.by里传的是实体属性名而不是数据库列名写成create_time会直接报PropertyReferenceException这是 JPA 新手翻车率最高的地方。3. Shiro Redis 认证授权登录态、权限与缓存怎么串起来3.1 登录认证链路拆解电商系统的安全管理有两个层次游客能不能看商品和搜索不需要登录能不能下单和进后台管理必须登录 角色校验。这是典型的认证 授权双能力Shiro 在这里靠过滤器链完成全部工作。项目里的核心配置在 ShiroConfig先看过滤器链Bean public ShiroFilterFactoryBean shiroFilterFactoryBean(SecurityManager securityManager) { ShiroFilterFactoryBean shiroFilterFactoryBean new ShiroFilterFactoryBean(); shiroFilterFactoryBean.setSecurityManager(securityManager); MapString, String filterChainDefinitionMap new LinkedHashMap(); // 静态资源和登录注册放行 filterChainDefinitionMap.put(/static/**, anon); filterChainDefinitionMap.put(/css/**, anon); filterChainDefinitionMap.put(/js/**, anon); filterChainDefinitionMap.put(/images/**, anon); filterChainDefinitionMap.put(/user/login, anon); filterChainDefinitionMap.put(/user/register, anon); filterChainDefinitionMap.put(/product/**, anon); // 购物车、订单必须登录 filterChainDefinitionMap.put(/cart/**, authc); filterChainDefinitionMap.put(/order/**, authc); // 后台接口要求管理员角色 filterChainDefinitionMap.put(/admin/**, roles[admin]); // 未登录跳转到登录页 shiroFilterFactoryBean.setLoginUrl(/user/toLogin); // 登录成功默认跳转到首页 shiroFilterFactoryBean.setSuccessUrl(/); // 无权限跳转页面 shiroFilterFactoryBean.setUnauthorizedUrl(/unauthorized); shiroFilterFactoryBean.setFilterChainDefinitionMap(filterChainDefinitionMap); return shiroFilterFactoryBean; }过滤器链的配置顺序就是匹配顺序Shiro 使用LinkedHashMap保证这一点不要换成普通HashMap否则规则的先后顺序无法保证。anon表示无需认证即可访问authc表示需要登录roles[admin]表示除了登录还需要 admin 角色。注意/admin/**用了通配符但 Shiro 的通配符和 Spring 的AntPathMatcher规则一致/admin/**会匹配/admin/下所有子路径包含多层。3.2 自定义 Realm 与密码校验逻辑过滤器只负责拦截真正的认证逻辑在自定义 Realm 里。项目会创建一个类继承AuthorizingRealm重写doGetAuthenticationInfo登录验证和doGetAuthorizationInfo权限角色加载。Override protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken token) throws AuthenticationException { UsernamePasswordToken usernamePasswordToken (UsernamePasswordToken) token; String username usernamePasswordToken.getUsername(); Member member memberService.findByUsername(username); if (member null) { throw new UnknownAccountException(用户不存在); } if (member.getStatus() ! 1) { throw new LockedAccountException(账号已被锁定); } return new SimpleAuthenticationInfo(member, member.getPassword(), ByteSource.Util.bytes(member.getSalt()), getName()); }这里有个容易被忽略的设计密码不是明文比对而是把数据库中所属盐值salt一起交给 ShiroShiro 内部会用它做加盐哈希后与输入密码比对。如果盐值不参与认证那同一明文密码在不同用户之间会生成相同的密文攻击者使用彩虹表就可以批量破解。所以注册时应该使用随机盐例如 UUID 前 8 位并且每个用户盐值不同。权限加载方法中通常用RequiresPermissions注解做细粒度控制。比如后台管理员点击删除商品时在 Controller 方法上加RequiresPermissions(product:delete)Shiro 的 AOP 拦截判断当前用户的权限集合是否包含该权限码没有就抛出AuthorizationException。3.3 Redis 在会话管理和验证码中的具体作用SpringBoot 默认的 Session 存在内存中服务一重启所有用户都得重新登录。这个项目引入 Redis 做 Session 持久化本质上是把 Shiro 的 SessionDAO 指向 Redis 缓存。Bean public RedisSessionDAO redisSessionDAO(RedisTemplateString, Object redisTemplate) { RedisSessionDAO sessionDAO new RedisSessionDAO(); sessionDAO.setRedisManager(redisManager(redisTemplate)); sessionDAO.setKeyPrefix(shiro_session:); return sessionDAO; }关键参数是keyPrefix。它决定了 session 在 Redis 中的存储键前缀。默认前缀不带业务含义排查问题时很难分清哪个 key 属于哪个用户。电商商城这种多端场景建议前缀拆细一点例如shiro:session:web:。另一个参数sessionIdGenerator可以换成自定义的 UUID 生成器防止默认生成器在某些容器环境下产生重复 session id。验证码缓存也是 Redis 的高频用途。常见做法是用户请求验证码接口时服务端生成图片并把答案写入 Redis设置 5 分钟过期登录时取出比对后立即删除。如果直接把验证码存在 Session 里多实例部署时请求落到不同节点就校验不通过。Redis 方案天然跨实例共享这也是项目里验证码不走 Session 的原因。3.4 角色权限控制的默认实现与扩展方向项目默认只有admin后台管理员和user前台会员两类角色。用户注册时默认分配user角色管理员手动在数据库里把某个会员的role_id改成管理员角色。这种设计在毕设和内部系统里足够用生产环境则需要引入role_permission、permission两张表做动态权限分配。Shiro 的doGetAuthorizationInfo里只需要把角色和权限集合改成从数据库查询即可框架本身的过滤器链不用动。4. Elasticsearch 商品检索从 MySQL LIKE 到全文搜索的跃迁4.1 搜索场景下 MySQL 的局限性商城首页的搜索框是最常见的入口如果只是WHERE title LIKE %手机%当商品量到几万条时这几个问题会逐个暴露LIKE 前置通配符会让索引失效数据库被迫全表扫描相关性排序做不到结果集只会按默认主键或指定字段排序无法把「标题精确包含」的商品排到「详情页包含关键词」的商品前面热点词高频搜索还会拖垮数据库连接池。所以项目把搜索链路独立出来MySQL 继续负责商品、订单等事务性数据Elasticsearch 只承接商品文档的检索。MySQL 负责写入和修改ES 负责读和查。这正好用上了项目标题里 Elasticsearch 的价值点。4.2 商品数据同步的三种实现方式ES 里的数据不是凭空有的需要一个同步机制把 MySQL 里的商品表导过去。这个项目里我看到的常见做法是启动时用ApplicationRunner做全量导入同时提供一个后台「重建索引」按钮做手动触发。全量导入的核心代码是这样的Component public class ProductIndexInitializer implements ApplicationRunner { Resource private ProductRepository productRepository; Resource private ProductSearchRepository productSearchRepository; Override public void run(ApplicationArguments args) { ListProduct products productRepository.findByStatus(1); ListProductDocument documents products.stream() .map(product - { ProductDocument doc new ProductDocument(); doc.setId(product.getId()); doc.setTitle(product.getTitle()); doc.setSubtitle(product.getSubtitle()); doc.setDiscountPrice(product.getDiscountPrice()); doc.setCategoryName(product.getCategory().getName()); doc.setSales(product.getSales()); return doc; }) .collect(Collectors.toList()); productSearchRepository.saveAll(documents); } }ApplicationRunner会在 SpringBoot 容器启动完成后执行run方法比PostConstruct更适合做这种依赖完整 Bean 的初始化任务。代码里先查数据库状态正常的商品再逐条转成 ES 文档结构最后批量saveAll。这里有个细节取商品分类名时访问了product.getCategory().getName()在事务外对懒加载属性取值会抛LazyInitializationException所以建议把商品列表查询改成findByStatus后在一个事务内完成转换或者在实体上把分类关系改成 EAGER。同步方式的选择上全量导入适合商品总量不超过十万的小型商城启动时导入慢一点没关系。后续如果每次商品变化都要准实时同步常见方案是监听 MySQL 的 binlog 或者用定时任务做增量比对。定时任务胜在简单但实时性差binlog 方案实时性好但引入额外组件需要按项目规模权衡。4.3 搜索接口分词、过滤与高亮商品搜索接口聚合了关键词、分类、价格区间三个条件这就是个典型的组合检索场景。ES 的NativeSearchQuery比单字段 match 查询复杂不少但拆解开看并不难public PageProductDocument search(String keyword, Long categoryId, Double minPrice, Double maxPrice, Pageable pageable) { BoolQueryBuilder boolQueryBuilder QueryBuilders.boolQuery(); // 关键词默认分词匹配标题和副标题 boolQueryBuilder.must(QueryBuilders.matchQuery(title, keyword).analyzer(ik_max_word)); // 分类过滤 if (categoryId ! null) { boolQueryBuilder.filter(QueryBuilders.termQuery(categoryId, categoryId)); } // 价格区间过滤使用 range if (minPrice ! null || maxPrice ! null) { RangeQueryBuilder rangeQuery QueryBuilders.rangeQuery(discountPrice); if (minPrice ! null) { rangeQuery.gte(minPrice); } if (maxPrice ! null) { rangeQuery.lte(maxPrice); } boolQueryBuilder.filter(rangeQuery); } NativeSearchQuery searchQuery new NativeSearchQueryBuilder() .withQuery(boolQueryBuilder) .withPageable(pageable) .withSort(SortBuilders.fieldSort(sales).order(SortOrder.DESC)) .build(); return productSearchRepository.search(searchQuery); }这段查询把两类子句分得很清楚must是参与相关度计算的匹配条件关键词命中的商品会按匹配度排序filter是纯过滤条件分类和价格区间只参与筛选不影响相关度打分而且 filter 结果会被 ES 缓存查询效率更高。排序上按销量降序符合商城「卖得好的排前面」的习惯。分词器用的ik_max_word是业界常见的中文分词插件它能把「智能手机」切分成「智能」「手机」等多个词搜索「手机」也能召回标题含「智能手机」的商品。项目里如果细节字段也要参与搜索可以再加一个multi_match查询同时匹配title和subtitle。高亮功能是搜索结果展示里比较提气的一个点。ES 会在返回的highlight字段里把命中的词包上标签前端拿到后自己渲染成红色或加粗即可后端只用加一行配置.withHighlightFields(new HighlightBuilder.Field(title).preTags(span classhighlight).postTags(/span))实际调接口时keyword传空字符串会导致matchQuery匹配所有文档一定要在 Service 层过滤这种参数。另外Pageable传给 ES 的语义和 JPA 一致page同样从 0 开始前端页码换算逻辑要前后端统一不然翻页总是差一页。5. 避坑与常见问题懒加载、序列化、静态资源拦截的血泪现场5.1 JPA 懒加载导致 JSON 序列化失败现象接口返回商品列表时直接抛LazyInitializationException或者报错failed to lazily initialize a collection前端看到 500。原因控制器拿到商品实体后转 JSONJackson 序列化器访问了category这个懒加载属性但此时事务已经提交Session 已关闭代理对象无法再从数据库加载数据。解决最简单的做法是把商品列表查询方法加上Transactional(readOnly true)让事务覆盖到序列化结束更优雅的方案是给实体关系改为FetchType.EAGER但会导致查询商品时多查一条分类 SQL数据量大时有性能隐患。我一般倾向第三种在 Controller 层直接转成 VO/DTO 对象只复制需要的字段彻底避开懒加载陷阱。5.2 Redis 里 key 出现乱码前缀现象通过 Redis 可视化工具查看缓存key 显示为\xac\xed\x00\x05t\x00这种二进制字符串肉眼无法辨认为哪个模块的数据。原因默认JdkSerializationRedisSerializer会把 key 和 value 都做 Java 序列化存进去的 key 是序列化后的字节数组自然是一堆乱码。这与用户无关是序列化器配置问题。解决在RedisConfig中把 key 的序列化器改为StringRedisSerializervalue 根据数据形态选择Jackson2JsonRedisSerializer。注意设置了 key 序列化器后之前写入的二进制 key 已经成为历史数据项目启动前用FLUSHDB清一次缓存避免新旧数据格式混存。5.3 前端样式和脚本被 Shiro 拦截现象登录页能跳转但页面 CSS 完全丢失控制台报 404登录按钮的验证码图片也加载不出来。原因Shiro 过滤器链把所有/static/**、/css/**、/js/**以外的路径默认拦截而页面里资源路径写的是../static/css/main.css相对路径没匹配上放行规则。解决先检查过滤器链是否配置了anon放行规则然后核对前端资源引入路径应该统一用 Thymeleaf 的th:href{/css/main.css}它会自动拼接上下文根路径。避免把静态资源和接口目录混在同一层结构上让静态资源集中在根路径下的静态目录接口统一带/api前缀放行规则清晰很多。5.4 Elasticsearch 索引不存在启动报错现象项目能正常启动但一到商品搜索接口控制台报index_not_found_exceptionES 返回 404。原因ES 的索引是显式创建的商品索引若没在启动时初始化搜索操作找不到可用的索引。只靠实体上的Document(indexName product)注解并不会自动建索引除非开启自动创建开关。解决在启动初始化类里先判断索引是否存在不存在则调用IndexOperations.create()创建索引同时写入 mapping 和分词器设置。索引创建后再做数据同步这样搜索接口首次调用就不会踩空。排查这类问题时可以直接在 Elasticsearch 的 Kibana 界面里执行GET _cat/indices看索引是否在场。5.5 下单时库存扣减事务边界混乱现象高并发下测试同一商品下单库存出现负数订单明细和订单主表数据不完整。原因扣库存、写订单、写明细三个操作没有放到同一个事务中或者某个操作被单独捕获了异常导致事务提前回滚标志被吃掉。解决在 Service 层下单方法上标注Transactional(rollbackFor Exception.class)并确保入口方法内部不吞异常。库存扣减要带stock 0条件配合数据库乐观锁或UPDATE product SET stock stock - 1 WHERE id ? AND stock 0原子更新避免并发超卖。分布式部署的商城还得考虑把扣库存放到 Redis 或者独立库存服务但单体项目这个事务写法够用。6. 本地复现与进阶启动顺序、验收路径和二次开发建议拿到源码后不要直接点 Run按下面顺序准备环境先启动 Redis再启动 Elasticsearch然后是 MySQL 并导入项目自带的初始化 SQL最后启动 SpringBoot 主类。顺序错了多半会看到Unable to connect to Redis或 ES 连接拒绝这不是项目代码问题是依赖服务没就绪。启动完成后按这套路径验证功能闭环注册新用户注意验证码走 Redis需要 Redis 在线— 首页搜索框搜「手机」看结果是否有高亮 — 添加商品到购物车 — 结算下单 — 用 admin 账号进后台查看订单列表 — 修改商品上下架状态后前台确认商品消失。这条链路走通说明 JPA 写库、Shiro 认证授权、Redis 会话、ES 搜索、前后端静态资源路由全都没问题。更有仪式感的验证是在 Elasticsearch 的 Kibana 控制台执行搜索语句直接比对 ES 查询结果和前端页面数据确认前端拿到的数据确实来自 ES 而非 MySQL 透传。二次开发可以从三处切入给搜索接口加上「综合排序」和「价格升序/降序」切换改动集中在搜索 Service 里追加排序字段把 Shiro 的认证逻辑从 Session 改为无状态 JWT让商城具备前后端完全分离部署的条件将后台管理端改成 Vue 独立工程用 Axios 调用接口。这几项改动刚好能覆盖简历里「电商全链路」「中间件集成」「认证授权」三个核心关键词。我从那以后每次拿新工程都会强制先跑一遍依赖环境再动代码把「起服务前先起 Redis 和 ES」养成肌肉记忆能省掉一半的排查时间。希望帮到你。本文还有配套的精品资源点击获取