简介microapp-linjiashop-master 是一套基于 Java 的轻量级单商户商城系统源码面向中小企业和想深入电商开发的 Java 开发者。项目以 Spring Boot 为核心整合 MyBatis、Thymeleaf、Redis 与 Maven体现微服务拆分思想并预留微信小程序接口可帮助读者理解从商品、订单、用户到支付模块的真实业务闭环。同时涵盖数据库表设计、OAuth2 等安全认证、Vue.js 前端交互、Docker 部署、CI/CD 流水线、日志监控等工程化实践适合作为综合型电商项目学习范例。资源包为 zip 格式大小约 13.2MB平台目前尚未展示文件总数与类型明细。当前已有 166 人学习下载对希望掌握商城系统全栈开发、小程序对接与项目部署的开发者来说是一份可对照源码逐步拆解的参考素材。1. 拿到这套 Java 商城小程序源码先别急着跑起来做 Java 开发的人应该都有过这种经历从网上下载一个商城系统源码包解压后第一眼看到几百个文件不知道先看哪个硬着头皮配数据库、改配置折腾两小时还是起不来。这套microapp-linjiashop-master就是典型的单商户商城 Java 项目后端基于 Spring Boot MyBatis Thymeleaf Redis管理后台是服务端渲染小程序端走独立 API 接口。它适合两类人一是想快速搭一个可商用的小型电商站点的个人开发者或小商家二是正在学 Spring Boot 全家桶、想找一个完整业务闭环商品、订单、支付、用户、小程序对接来读源码的 Java 学习者。我把它拆过一遍这里把结构、启动步骤和踩过的坑都写清楚照着做能省掉不少自己摸黑的时间。2. 先读懂技术选型为什么是 Spring Boot MyBatis 而不是别的2.1 这套项目的技术栈图谱和后端分层逻辑拿到源码先别急着mvn spring-boot:run第一步是把这个项目的技术栈和目录结构看清楚。它不是一个前后端分离的纯 API 项目而是「管理后台服务端渲染 小程序端接口」的混合形态。管理后台用的是 Thymeleaf 模板引擎由后端直接渲染 HTML 返回浏览器小程序端不能直接跑 HTML所以单独走 JSON 接口。同一个 Spring Boot 应用同时承担两种角色这是很多老牌 Java 商城项目常见的做法。数据访问层用的是 MyBatis 而不是 JPA这意味着所有 SQL 都是手写在 XML 或注解里的。好处是 SQL 可控性强复杂查询多表关联、分页统计排查起来直接看语句坏处是字段改了要同步改映射不像 Hibernate 那样自动。项目里 Maven 负责依赖管理Redis 用来缓存热点数据比如首页轮播图、商品详情降低数据库压力。后端代码分层通常是这样controller接收请求service写业务逻辑mapper或dao访问数据库entity或model对应数据表。看这套源码的时候我建议按照「controller → service → mapper → SQL」的顺序读一个完整链路而不是按文件目录从上到下扫后者很容易被工具类淹没。2.2 项目目录结构和配置文件的几个关键位置解压后先看根目录下的 pom.xml确认依赖版本。我拆的这份里 Spring Boot 版本和 MyBatis Starter 的搭配需要留意Spring Boot 2.x 配mybatis-spring-boot-starter2.x 是没问题的如果是 Spring Boot 3.x 就要用mybatis-spring-boot-starter3.x否则启动时直接报ClassNotFoundException。这是第一个容易翻车的地方。源码包里通常会有一个sql或doc目录里面放着数据库初始化脚本。先执行这个脚本再改配置不要自己新建空库然后指望项目自动建表——虽然 Spring Boot 支持ddl-autoupdate但商城系统的表结构有外键关联和初始化数据比如管理员账号、默认分类靠自动建表会丢数据。配置文件里最需要改的是这三个application.yml或application.properties里的数据源、Redis 连接小程序相关的配置项AppID、Secret文件上传存储路径一个典型的application.yml数据源配置长这样spring: datasource: url: jdbc:mysql://127.0.0.1:3306/linjiashop?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: 127.0.0.1 port: 6379 database: 0 thymeleaf: cache: false这里serverTimezoneAsia/Shanghai是必须的。MySQL 8.x 的驱动默认要求时区参数不加会报The server time zone value的错误这是个高频问题。Redis 的database: 0表示用第 0 个库如果机器上 Redis 有密码还要加password字段。Thymeleaf 的cache: false在开发阶段一定要开否则改了 HTML 模板要重启应用才能生效很影响调试效率。2.3 启动前必须搞清楚的数据库初始化和 Redis 依赖数据库初始化脚本是这个项目能不能跑起来的关键。找到sql目录下的.sql文件用命令行导入比用 Navicat 导入更可控mysql -uroot -p123456 /path/to/linjiashop.sql导入后确认一下表数量。一个完整的单商户商城系统表一般在 20 张以上user用户、product商品、product_sku商品规格、order订单、order_item订单明细、cart购物车、category分类、address收货地址、payment支付记录、banner轮播图等。如果导入后只有十几张表说明可能只是部分模块的脚本要找完整的。这套项目里 Redis 不是可选组件是必选。启动应用前先确认 Redis 服务在运行redis-cli ping返回PONG才说明正常。如果 Redis 没起来Spring Boot 启动时连接超时项目会直接启动失败。这个坑很常见很多人以为是代码问题其实只是忘了把 Redis 打开。项目跑起来后可以通过redis-cli keys *看一下缓存了哪些数据能帮助理解哪些接口走了缓存。3. 本地跑通这套商城从构建到启动的完整操作3.1 Maven 构建和依赖下载的注意事项先把环境列一下JDK 1.8这个项目我要强调Spring Boot 2.x 用 JDK 8 是最稳的用 JDK 11 或 17 可能出现兼容问题、Maven 3.6、MySQL 5.7 或 8.0、Redis 任意稳定版本。如果你电脑上同时装了多个 JDK记得确认JAVA_HOME指向的是 JDK 8。构建命令很简单但有几个参数需要说明mvn clean install -DskipTests -Dmaven.test.skiptrue-DskipTests是跳过测试代码的编译-Dmaven.test.skiptrue是连测试代码都不编译。首次构建会下载大量依赖如果网络不好或者 Maven 中央仓库访问慢建议在settings.xml里配阿里云镜像否则可能卡在下载依赖这一步。构建成功的标志是BUILD SUCCESS然后target目录下会生成可执行的 jar 包。如果你拿到的是 IDE 工程有.idea或.classpath文件直接导入 IDE 也行但导入后要检查一下 Maven 是否自动刷新了依赖。推荐的做法是命令行先mvn clean install一次确认依赖完整后再用 IDE 打开这样可以避免 IDE 里一片飘红不知道是哪里缺包。3.2 启动 Spring Boot 应用和 Admin 后台登录依赖构建完成后启动应用有两种方式。一种是直接跑 jar 包java -jar target/linjiashop.jar --spring.profiles.activeprod另一种是在 IDE 里直接运行启动类的main方法。开发阶段我推荐 IDE 方式因为可以断点调试。启动日志里看到Started Application in x.x seconds就说明成功了端口默认一般是 8080具体看server.port配置。后台管理地址通常是http://localhost:8080或http://localhost:8080/admin。初始账号密码在数据库初始化脚本里一般在user表或admin表里初始密码常见是admin123或123456。如果你登录不进去直接去数据库里查一下这张表SELECT * FROM sys_user WHERE username admin;注意看密码字段是明文还是密文。如果是密文项目里应该有对应的加密工具类比如 MD5、BCrypt来生成新密码不要直接在数据库改明文否则永远登录不进去。3.3 用 Postman 验证小程序端接口的联通性后台能登录后再验证一下小程序端的接口是否正常。小程序端接口和管理后台接口通常在同一个应用里但路径前缀不同。常见的路径设计是/api开头。用 Postman 或者直接 curl 试一下curl -X GET http://localhost:8080/api/index如果返回 JSON 数据说明接口层是通的。如果返回 404看一下 controller 层的 RequestMapping 路径。这里要特别提醒小程序端接口通常对时效性有要求比如首页轮播图接口可能加了 Redis 缓存第一次请求会查数据库再写缓存第二次开始走缓存。你测试的时候看到第一次响应慢、第二次快这是正常现象。验证接口时注意看返回的数据格式。商城项目通常统一返回{ code: 0, message: success, data: {...} }这样的结构code为 0 表示成功非 0 表示业务错误。小程序端就是根据这个 code 来判断请求是否成功的这在后面对接小程序时很关键。4. 核心链路源码剖析登录、商品、购物车和订单4.1 微信小程序登录和 Token 鉴权是怎么串起来的这套项目名称里有「小程序」所以小程序端的登录接口是值得先读的一块。微信小程序登录不是用账号密码而是用wx.login()拿到的code换openid流程是这样的小程序前端调用wx.login()获取临时 code把 code 传给后端后端拿着 code 去微信接口换 openid 和 session_key然后后端自己生成一个 token 返回给小程序前端。之后小程序前端每次请求携带这个 token后端通过拦截器校验。后端代码大致是这样PostMapping(/api/login) public Result login(RequestBody LoginRequest request) { String code request.getCode(); // 调用微信接口 code2Session WxSession session wxService.code2Session(code); // 根据 openid 查找或创建用户 User user userService.findOrCreateByOpenId(session.getOpenId()); // 生成 token 存入 Redis设置过期时间 String token UUID.randomUUID().toString().replace(-, ); redisService.set(token: token, user.getId(), 7 * 24 * 3600); return Result.success(token); }这个 token 就是你后来在小程序端做登录态维持的核心。注意代码里redisService.set的过期时间是 7 天意味着用户一周内不用重新登录超过一周 token 失效要重新走登录流程。有的商城系统还会做「静默登录」用户打开小程序时自动检查本地是否存有 token尝试用 token 直接拉用户信息拉不到才走wx.login()。这个小程序登录换取手机号的逻辑也值得关注微信现在推荐用getPhoneNumber按钮获取用户手机号后端拿到加密数据后要解密解密需要 session_key。细节上要注意 session_key 的有效期是动态的用户多次调用wx.login()后旧的 session_key 会失效解密失败时要让前端重新走登录流程。4.2 商品列表和商品详情的缓存设计商城系统的读多写少商品列表和详情是高并发访问最密集的接口。这套项目在缓存上用了比较常规的方案Redis 存商品详情 JSONkey 设计通常是product:detail:{id}。第一次请求查 MySQL然后把数据序列化为 JSON 存入 Redis设置过期时间比如 30 分钟后续请求直接读缓存Redis 没有才回源数据库。public ProductVO getProductDetail(Long productId) { String key product:detail: productId; String cached redisService.get(key); if (cached ! null) { return JSON.parseObject(cached, ProductVO.class); } Product product productMapper.selectById(productId); ListProductSku skuList skuMapper.selectByProductId(productId); ProductVO vo new ProductVO(product, skuList); redisService.set(key, JSON.toJSONString(vo), 1800); return vo; }这里有个细节商品详情包含 SKU 列表规格、库存、价格查询时要先查商品主表再查 SKU 子表。如果一个商品有多个规格比如颜色、尺码SKU 可能有十几条。缓存时把整个 VO 对象存进去比分开缓存再组装要简单得多但缺点是修改 SKU 后要手动清缓存。key的设计是有讲究的。用product:detail:{id}这种前缀 业务域 主键的方式在排查问题时用redis-cli keys product:*就能看所有商品缓存也方便批量清理。有的项目会在 key 上带版本号product:detail:v1:{id}升级缓存结构时整体换前缀这样就不用一条条删旧 key也是做二次开发时可以参考的技巧。4.3 购物车和订单状态机的流转逻辑购物车是典型的会话级数据但商城系统一般会把它持久化到数据库因为用户换设备后购物车还在。购物车表的核心字段是user_id、product_id、sku_id、quantity、checked是否选中。加购物车的操作逻辑简单但要注意「重复添加同一款 SKU 要累加数量而不是插入新记录」这个边界情况。订单是商城系统里状态最多的模块。一般订单状态有待支付0、已支付/待发货1、已发货/待收货2、已完成3、已取消4、退款中5等。订单状态机是这个项目的核心业务逻辑改状态的时候要判断当前状态是否允许迁移比如已取消的订单不能改成已发货。public void cancelOrder(Long orderId, Long userId) { Order order orderMapper.selectById(orderId); // 校验订单归属 if (!order.getUserId().equals(userId)) { throw new BusinessException(无权操作该订单); } // 只有待支付状态才能取消 if (order.getStatus() ! 0) { throw new BusinessException(当前状态不可取消); } // 取消后要回滚库存 orderMapper.updateStatus(orderId, 4); restoreStock(order); }留意这里的两层校验第一层是归属校验防止 A 用户操作 B 用户的订单第二层是状态校验只允许待支付订单取消。取消后restoreStock把 SKU 的库存加回去。如果漏了这一步用户取消订单后库存就凭空少了这是电商系统最常见的库存不一致问题排查起来很费劲所以读源码时要重点关注这类补偿操作。订单模块还有一个关键点是金额计算。下单时要从数据库查出最新的 SKU 价格不能用前端传过来的价格。前端传的价格可能被篡改或者下单后商家改了价格。支付时也要校验订单金额和实际支付金额是否一致防止「改价格」的恶意下单。5. 部署调试避坑记录启动失败和数据不一致的现场5.1 MySQL 时区报错导致应用启动不了现象Spring Boot 启动时报The server time zone value йʱ is unrecognized应用直接退出。原因MySQL 8.x 的驱动要求显式指定时区而系统的默认时区是 CSTChina Standard Time格式不被驱动识别。解决在 JDBC URL 上加serverTimezoneAsia/Shanghai并且要放在参数末尾。如果是 MySQL 5.7这个参数可加可不加但建议统一加上避免换环境时出问题。5.2 Redis 没启动导致项目起不来现象启动日志里报Unable to connect to Redis或Connection refused: /127.0.0.1:6379项目启动失败。原因项目里用了 Redis 做缓存启动阶段会初始化连接池Redis 服务没跑起来初始化直接失败。有些项目会做懒加载启动时不连 Redis但这个项目不行。解决先执行redis-cli ping确认返回PONG再启动应用。如果你在云服务器上部署记得在安全组里放通 6379 端口否则本地能连、线上连不上。另外检查一下 Redis 是否设置了密码如果设置了要在配置里补上不然会报NOAUTH Authentication required。5.3 数据库初始化后后台账号登录失败现象数据库脚本导入成功后台登录页面也能打开但输入初始账号密码一直提示密码错误。原因初始密码通常是加密后存进数据库的你在数据库里看到的密码字段可能不是明文用明文去比对当然失败。另一种可能是你导入的脚本版本和代码里的加密方式不一致比如代码用的是 BCrypt脚本里存的是 MD5。解决先确认sys_user表里密码字段的格式。如果是以$2a$开头就是 BCrypt需要在项目里写个临时接口或测试类来生成新密码如果是 32 位十六进制 MD5确认代码里passwordEncoder的实现。不要去数据库直接改明文改了也登录不了因为你绕过了加密逻辑。5.4 小程序端请求接口报 404 或 401现象后台管理页面正常但小程序端访问/api开头的接口要么 404 要么 401。原因404 一般是路径写错了小程序端接口路径和管理后台路径可能不在同一个前缀下或者项目里配置了 context-path 导致接口前缀变化。401 是拦截器拦截了请求小程序请求头里没带 token 或 token 已过期。解决先用 Postman 直接调接口确认路径是否正确401 的话检查拦截器的excludePathPatterns配置登录、商品列表、首页这些公开接口应该被排除不需要 token 的接口如果也要求 token就是配置问题。小程序端请求要确认在header里带了token字段字段名要和后端拦截器取的一致。5.5 订单支付回调出现重复通知导致数据错乱现象同一个订单被重复回调或者回调成功后订单状态还是待支付。原因支付平台的回调不是一次性的会多次通知直到你返回成功标记。如果业务代码在处理回调时没有做幂等处理同一个订单会被处理两次出现「已发货的订单又变成待支付」这种怪数据。解决在处理回调的业务代码里先查订单当前状态判断是否已经处理过。如果状态已经是已支付直接返回成功不再重复处理。另外回调处理要包在事务里处理失败要抛异常让支付平台继续重试但重试要满足幂等。6. 验证一次完整交易链路从商品浏览到订单支付的小闭环跑通一个完整交易链路比单独调试十几个接口能发现更多问题。我建议你按这个顺序走一遍全流程首页 → 商品列表 → 商品详情 → 加入购物车 → 提交订单 → 模拟支付 → 查看订单状态。前端小程序和后端 API 的联调是这套项目的一个基本功。打开微信开发者工具导入小程序端源码目录在app.js或专门的config.js文件里找到 API 地址配置改成你的本地地址。微信开发者工具有个「不校验合法域名」的选项本地开发时必须勾上不然所有请求都会被拦截。wx.request({ url: http://localhost:8080/api/addCart, method: POST, header: { token: wx.getStorageSync(token) }, data: { productId: 1, skuId: 11, quantity: 1 }, success(res) { if (res.data.code 0) { wx.showToast({ title: 已加入购物车 }); } } });这段代码有三个要点第一header里带token是从本地存储里取的如果用户没登录就加入购物车后端会返回未登录错误实际项目里通常要先判断登录态再调接口第二data里的skuId很关键同一个商品不同规格对应不同的 SKU ID加错了库存和价格就乱了第三code 0才是成功不是 HTTP 200 就代表成功。支付环节在本地环境通常没有真实的支付商户号实际做法是「模拟支付」订单提交后后端生成一个支付订单号前端模拟调起支付直接调后端一个「模拟支付成功」的接口。这个接口要校验订单是否存在、订单是否属于当前用户、订单状态是否为待支付。这些校验逻辑在真实接入微信支付时同样沿用只是把「模拟支付成功」换成微信支付回调。验证通过后可以做一次二次开发的尝试来检验你对这套代码的理解程度。一个比较容易入手的方向是「新用户注册送优惠券」。需要改动的点用户表中加coupon_status字段0 未赠送1 已赠送用户注册成功时判断该字段插入一条优惠券记录。这个改动覆盖了建表、写业务逻辑、加接口三个层次。linjiashop这套系统的管理后台是把商品、订单、用户、营销这些模块都放在了一个工程里跟那些动辄十几个微服务模块的「企业级」项目相比它最值得学的地方在于你能在一台电脑上跑起来并且完整读完整套业务逻辑不会因为服务间调用链路太长而迷失在哪一段。这个完整闭环本身就是很有价值的学习资源——从数据库表设计到后端接口再到小程序端调用所有链路都是通的。在这套源码上做了二次开发后我的一个习惯是每改一个功能就重启一次应用确认启动日志没有异常然后立刻复测一遍交易链路。这样做的好处是问题暴露在改完的那一刻而不是累计到三五处改动后再排查。从那以后我每次拿到新的商城项目第一件事就是先把下单到支付的主链路跑通再动手看别的模块。希望这份拆解对你跑通和用好这套商城项目有帮助。本文还有配套的精品资源点击获取
