企业官网建设流程全解析

简介：本资源是一套完整的基于SpringBoot的小区团购管理系统毕业设计项目源码，面向Java初学者、高校计算机专业学生及Web开发入门者，解决社区场景下团购信息发布、用户管理与素材维护等实际业务需求。系统采用前后端分离架构，后端以Java+SpringBoot+MyBatisPlus构建，前端使用Vue+ElementUI实现响应式界面，并集成MySQL数据库与AJAX异步交互，涵盖用户信息管理、图片/视频素材上传与展示等核心功能模块。压缩包共826个文件，含122个Java业务逻辑类、62个Vue组件页、160个JS脚本、52个CSS样式文件及79个GIF动效资源，整体大小为25.55MB，结构清晰，含完整build/run/install脚本与多层级目录（含绪论、技术选型、系统分析、数据库设计及详细实现章节）。目前已有63人学习下载，提供可直接运行的全栈代码、规范的Maven工程结构及配套文档骨架，适合课程设计、毕设参考与SpringBoot+Vue实战练手。

1. 项目概述：从零到一构建一个小区团购管理系统

最近几年，社区团购的模式可以说遍地开花，尤其是在一些大型社区里，几个热心的“团长”就能把邻里邻居的日常采买需求组织得井井有条。但随之而来的问题也很明显：订单靠接龙、收款靠转账、统计靠Excel，团长们累得够呛，还容易出错。作为一个有多年Java后端开发经验的“老码农”，我最近就接了个私活，帮朋友的小区开发一套专用的团购管理系统。核心目标很明确：用技术解放人力，让团购管理从“手工活”变成“自动化流水线”。

这个项目我选择了Java + Spring Boot这套经典且成熟的技术栈。原因很简单：Spring Boot的“约定大于配置”理念能让我快速搭建起项目骨架，把精力集中在业务逻辑上；而Java的稳定性和丰富的生态，对于这种涉及交易、用户管理的系统来说，能提供坚实的可靠性保障。整个系统需要覆盖从商品上架、订单生成、支付对账到团长分发的完整闭环，同时还要兼顾普通住户、团长、后台管理员三种不同角色的操作体验。接下来，我就把这个项目的设计思路、核心实现以及我踩过的那些“坑”详细拆解一遍，无论你是想学习Spring Boot实战，还是正有类似的管理系统开发需求，相信都能从中找到可以直接“抄作业”的干货。

2. 系统整体架构与核心模块设计

2.1 业务场景与角色权限拆解

在动手写代码之前，必须把业务场景和参与角色理清楚。小区团购虽然看起来简单，但涉及的角色和流程环环相扣。

首先是三种核心角色：

1. 住户（普通用户）：核心需求是浏览商品、下单支付、查看自己的订单和取货信息。他们对系统的要求是界面清晰、操作简单、支付方便。
2. 团长：这是整个流程的枢纽。他的后台需要能看到本团的所有订单明细，包括每个住户买了什么、付了多少钱、是否已提货。同时，团长还需要有基本的商品上架（通常是接收供应商的统一商品库后，选择在本团开放）、生成提货清单（用于现场核销）以及跟平台进行佣金结算的功能。
3. 平台管理员（超级管理员）：负责管理整个平台的基础数据，包括管理所有团长账号、审核供应商和商品、配置全局参数（如佣金比例、提货点设置）、查看全平台销售数据报表。

基于这些角色，我们可以梳理出几条核心业务流：

• 商品流：管理员创建供应商和商品 -> 团长从商品库选择商品上架到自己的团 -> 住户浏览并下单。
• 订单流：住户下单并支付 -> 订单进入“待成团”或“待发货”状态 -> 团购截止后，订单状态更新 -> 团长看到订单清单，进行备货或通知供应商发货 -> 货物到达提货点，团长标记订单可提货 -> 住户提货，团长核销订单。
• 资金流：住户支付订单款至平台（或第三方支付托管）-> 订单完成后，平台根据规则将货款结算给供应商，将佣金结算给团长。

注意：资金安全是重中之重。在实际设计中，强烈建议引入第三方支付平台（如微信支付、支付宝）的担保交易接口，让钱款先进入平台担保账户，待用户确认收货（或系统超时自动确认）后再结算给供应商和团长。切勿设计为“支付即到账”，这会给平台带来巨大的资金风险和纠纷。

2.2 技术栈选型与项目结构规划

确定了业务，接下来就是技术选型。我的选择是基于“稳健、高效、易维护”的原则：

• 后端框架：Spring Boot 2.7.x。这个版本是长期支持版，稳定性和社区资源都足够丰富。它内嵌了Tomcat，一键启动，省去了大量传统Spring MVC的XML配置。
• 持久层框架：MyBatis-Plus。相比原生的MyBatis，MyBatis-Plus提供了强大的CRUD封装和条件构造器，能极大减少单表操作的SQL编写量。它的分页插件和逻辑删除功能对于管理系统来说非常实用。
• 数据库：MySQL 8.0。关系型数据库是管理这种强事务性、数据一致性要求高的业务的不二之选。8.0版本在性能（如窗口函数）和JSON字段支持上都有提升。
• 缓存：Redis。用于存储用户登录的Session信息、高频访问的商品信息、以及秒杀场景下的库存缓存，能有效减轻数据库压力。
• 权限控制：Spring Security + JWT (JSON Web Token)。Spring Security提供了强大的认证和授权框架，结合无状态的JWT，非常适合前后端分离的架构。JWT Token中可以携带用户角色信息，后端接口通过注解（如@PreAuthorize(“hasRole(‘ROLE_ADMIN’)”)）即可轻松控制访问权限。
• 项目管理与构建：Maven。依赖管理清晰，生命周期明确。
• API文档：Swagger2 / Knife4j。自动生成在线API文档，方便前后端联调。

项目结构（Package）我通常按职责分层划分，这样结构清晰，便于团队协作：

src/main/java/com/community/groupbuy/ ├── config/ // 配置类（Security, Redis, Mybatis-Plus, Swagger等） ├── controller/ // 控制层，接收请求，调用Service ├── service/ // 业务逻辑层接口 │ └── impl/ // 业务逻辑层实现 ├── mapper/ // MyBatis Mapper接口层（对应Dao） ├── entity/ // 实体类，与数据库表对应 ├── dto/ // 数据传输对象，用于前后端交互和层间传递 ├── vo/ // 视图对象，专门用于接口响应数据封装 ├── common/ // 通用工具类、常量、异常定义、统一返回结果封装 └── GroupBuyApplication.java // Spring Boot主启动类

这种分层结构将web层、业务层、数据访问层分离，符合单一职责原则，后期维护和单元测试都会方便很多。

3. 数据库设计与核心表结构解析

数据库设计是系统的基石，设计得好，后期开发事半功倍。这里我列出几个最核心的表及其字段设计思路。

3.1 用户与权限相关表

sys_user(系统用户表)：这是所有角色的基表。

CREATE TABLE `sys_user` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '主键', `username` varchar(50) NOT NULL COMMENT '用户名（登录用）', `password` varchar(100) NOT NULL COMMENT '加密后的密码', `nickname` varchar(50) DEFAULT NULL COMMENT '昵称（显示用）', `phone` varchar(20) DEFAULT NULL COMMENT '手机号', `avatar` varchar(255) DEFAULT NULL COMMENT '头像URL', `user_type` tinyint(4) NOT NULL DEFAULT '1' COMMENT '用户类型：1-住户，2-团长，3-管理员', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '状态：0-禁用，1-正常', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_username` (`username`), KEY `idx_phone` (`phone`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='系统用户表';

实操心得：user_type字段用tinyint比用varchar存储角色名更节省空间，查询效率也更高。密码字段password长度建议给到100，因为BCrypt等加密算法生成的密文较长。utf8mb4字符集是为了支持存储Emoji表情。

sys_role(角色表) 和sys_user_role(用户角色关联表)：虽然当前角色简单，但用关联表设计是为了预留扩展性。比如未来可能增加“供应商”角色。

3.2 核心业务表

group_info(团信息表)：每个团长对应一个“团”，这个表定义了团的属性。

CREATE TABLE `group_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `group_name` varchar(100) NOT NULL COMMENT '团名称（如：XX小区5号楼团）', `leader_id` bigint(20) NOT NULL COMMENT '团长用户ID', `community` varchar(100) DEFAULT NULL COMMENT '所属小区', `pickup_address` varchar(255) NOT NULL COMMENT '提货点详细地址', `contact_phone` varchar(20) DEFAULT NULL COMMENT '团长联系电话', `status` tinyint(4) DEFAULT '1' COMMENT '状态：0-停用，1-运营中', PRIMARY KEY (`id`), KEY `idx_leader_id` (`leader_id`) ) COMMENT='团信息表';

product(商品表)：存储平台所有商品信息，由管理员或供应商创建。

CREATE TABLE `product` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `product_name` varchar(200) NOT NULL COMMENT '商品名称', `category_id` bigint(20) DEFAULT NULL COMMENT '分类ID', `supplier_id` bigint(20) DEFAULT NULL COMMENT '供应商ID', `main_image` varchar(500) DEFAULT NULL COMMENT '主图URL', `detail` text COMMENT '商品详情（富文本）', `original_price` decimal(10,2) DEFAULT NULL COMMENT '原价', `group_price` decimal(10,2) NOT NULL COMMENT '团购价', `stock` int(11) NOT NULL DEFAULT '0' COMMENT '总库存', `status` tinyint(4) DEFAULT '1' COMMENT '状态：1-上架，0-下架', PRIMARY KEY (`id`) ) COMMENT='商品表';

group_product(团-商品关联表)：这是关键表。团长并不是创建商品，而是从总商品库中“认领”商品到自己的团，并可以设置独立的团购时限和限购数量。

CREATE TABLE `group_product` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `group_id` bigint(20) NOT NULL COMMENT '团ID', `product_id` bigint(20) NOT NULL COMMENT '商品ID', `start_time` datetime NOT NULL COMMENT '团购开始时间', `end_time` datetime NOT NULL COMMENT '团购截止时间', `limit_per_user` int(11) DEFAULT NULL COMMENT '每户限购数量', `current_stock` int(11) NOT NULL COMMENT '当前剩余库存（动态减少）', PRIMARY KEY (`id`), UNIQUE KEY `uk_group_product` (`group_id`,`product_id`), -- 防止同一商品在同一团重复上架 KEY `idx_end_time` (`end_time`) -- 便于查询已截止的团 ) COMMENT='团商品关联表';

核心设计解析：为什么要把商品和团购信息分开？这是为了解耦。product表是商品档案，group_product表是商品在某个特定团里的销售策略和实时状态。这样，同一个商品可以在不同团以不同时间、不同限购规则同时进行团购，且库存（current_stock）是团维度独立的，避免了跨团抢库存的混乱。

order(订单主表) 和order_item(订单明细表)：这是经典的主子表设计。

• order表存储订单概要：订单号、用户ID、团ID、总金额、支付状态、支付时间、订单状态（待支付、待成团、待提货、已完成、已取消等）。
• order_item表存储订单详情：关联的订单ID、商品ID、购买数量、商品单价快照、商品名称快照。

避坑技巧：在order_item中存储商品信息的快照（如product_name_snapshot,price_snapshot）是必须的。因为商品的原价、名称未来可能会修改，如果只存商品ID，用户查看历史订单时显示的信息就可能对不上，引发客诉。这是电商系统设计的通用实践。

4. 后端核心功能实现与代码详解

4.1 用户认证与权限控制（Spring Security + JWT）

这是系统的安全大门。我的实现步骤如下：

1. 引入依赖：在pom.xml中添加spring-boot-starter-security和jjwt的依赖。
2. 编写JWT工具类：创建JwtTokenUtil，负责生成Token、从Token中解析用户名、判断Token是否过期等。
3. 实现UserDetailsService：创建一个类实现UserDetailsService接口，重写loadUserByUsername方法。这里根据用户名从数据库查询用户信息，并封装成Spring Security认识的UserDetails对象。关键点：需要将数据库中的用户角色（如ROLE_LEADER）转换为GrantedAuthority对象。
4. 配置Spring Security：通过继承WebSecurityConfigurerAdapter（Spring Boot 2.x）或使用SecurityFilterChainBean（Spring Boot 3.x）进行配置。主要配置包括：
   • 放行登录接口、Swagger文档路径、静态资源等。
   • 注册一个JwtAuthenticationTokenFilter过滤器，放在用户名密码认证过滤器之前。这个过滤器的逻辑是：从请求头Authorization中取出JWT Token，进行校验，如果有效，则根据用户名加载用户权限信息，并设置到SecurityContext中，这样后续的接口就能通过@PreAuthorize注解进行权限判断了。
   • 配置密码加密器，使用BCryptPasswordEncoder。
   • 禁用CSRF（因为前后端分离，且使用无状态的JWT）。
5. 登录接口：在AuthController中，接收用户名和密码，调用AuthenticationManager进行认证。认证成功后，使用JwtTokenUtil生成Token，并返回给前端。

// 示例：JwtAuthenticationTokenFilter 核心代码片段 @Component public class JwtAuthenticationTokenFilter extends OncePerRequestFilter { @Autowired private JwtTokenUtil jwtTokenUtil; @Autowired private UserDetailsService userDetailsService; @Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String authHeader = request.getHeader(this.tokenHeader); // 通常为 “Authorization” if (authHeader != null && authHeader.startsWith(this.tokenHead)) { // tokenHead 通常为 “Bearer ” String authToken = authHeader.substring(this.tokenHead.length()); String username = jwtTokenUtil.getUserNameFromToken(authToken); if (username != null && SecurityContextHolder.getContext().getAuthentication() == null) { UserDetails userDetails = this.userDetailsService.loadUserByUsername(username); if (jwtTokenUtil.validateToken(authToken, userDetails)) { // 创建认证通过的Token，并设置权限 UsernamePasswordAuthenticationToken authentication = new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } } } chain.doFilter(request, response); } }

4.2 团购商品上架与库存管理

这是团长的核心操作。当团长从后台商品库选择商品上架到自己的团时，后端需要创建一条group_product记录。这里的关键是库存的初始化。

@Service public class GroupProductServiceImpl implements GroupProductService { @Autowired private ProductMapper productMapper; @Autowired private GroupProductMapper groupProductMapper; @Transactional(rollbackFor = Exception.class) // 开启事务 @Override public boolean addProductToGroup(Long groupId, Long productId, GroupProductDTO dto) { // 1. 校验商品是否存在且已上架 Product product = productMapper.selectById(productId); if (product == null || product.getStatus() != 1) { throw new BusinessException("商品不存在或已下架"); } // 2. 防止重复上架 LambdaQueryWrapper<GroupProduct> queryWrapper = new LambdaQueryWrapper<>(); queryWrapper.eq(GroupProduct::getGroupId, groupId) .eq(GroupProduct::getProductId, productId); if (groupProductMapper.selectCount(queryWrapper) > 0) { throw new BusinessException("该商品已在本团上架"); } // 3. 创建团商品记录 GroupProduct groupProduct = new GroupProduct(); groupProduct.setGroupId(groupId); groupProduct.setProductId(productId); groupProduct.setStartTime(dto.getStartTime()); groupProduct.setEndTime(dto.getEndTime()); groupProduct.setLimitPerUser(dto.getLimitPerUser()); // 关键：初始化库存。这里可以设置一个“团库存”，通常小于或等于商品总库存。 // 更复杂的场景可能还需要锁总库存，这里简化处理，直接使用传入的库存数。 groupProduct.setCurrentStock(dto.getInitStock()); return groupProductMapper.insert(groupProduct) > 0; } }

库存扣减的并发控制：当多个用户同时抢购同一团商品时，会出现“超卖”问题。最简单的解决方案是在更新库存的SQL语句中加上条件判断：

UPDATE group_product SET current_stock = current_stock - #{quantity} WHERE id = #{id} AND current_stock >= #{quantity}

然后检查MyBatis的update操作返回的affected rows（影响行数）。如果为0，说明库存不足，更新失败，业务层应抛出“库存不足”异常。这是利用数据库的行锁实现的乐观锁，在并发量不是极高的场景下简单有效。对于秒杀级场景，则需要引入Redis分布式锁或消息队列来削峰填谷。

4.3 订单创建与支付状态流转

用户下单是一个事务性很强的操作，涉及订单主表、明细表的插入，以及团商品库存的扣减。

@Service public class OrderServiceImpl implements OrderService { @Autowired private GroupProductMapper groupProductMapper; @Autowired private OrderMapper orderMapper; @Autowired private OrderItemMapper orderItemMapper; @Transactional(rollbackFor = Exception.class) @Override public String createOrder(OrderCreateDTO createDTO, Long userId) { // 0. 基础校验（略） // 1. 扣减库存（使用上面提到的带条件更新的SQL） GroupProduct gp = groupProductMapper.selectForUpdate(createDTO.getGroupProductId()); // select for update 行锁 if (gp == null || gp.getCurrentStock() < createDTO.getQuantity()) { throw new BusinessException("商品库存不足"); } int updateStock = groupProductMapper.decreaseStock(gp.getId(), createDTO.getQuantity()); if (updateStock == 0) { throw new BusinessException("库存扣减失败，请重试"); } // 2. 生成订单号（雪花算法或时间戳+随机数） String orderNo = generateOrderNo(); // 3. 插入订单主表 Order order = new Order(); order.setOrderNo(orderNo); order.setUserId(userId); order.setGroupId(gp.getGroupId()); order.setTotalAmount(gp.getGroupPrice().multiply(new BigDecimal(createDTO.getQuantity()))); // 计算总价 order.setStatus(OrderStatusEnum.UNPAID.getCode()); // 初始状态：待支付 orderMapper.insert(order); // 4. 插入订单明细表（记得保存快照信息！） OrderItem item = new OrderItem(); item.setOrderId(order.getId()); item.setProductId(gp.getProductId()); item.setProductNameSnapshot(gp.getProduct().getProductName()); // 快照！ item.setPriceSnapshot(gp.getGroupPrice()); // 快照！ item.setQuantity(createDTO.getQuantity()); orderItemMapper.insert(item); // 5. 后续：可能触发消息通知，如发送新订单提醒给团长 return orderNo; } }

支付成功后，第三方支付平台会通过异步回调通知我们的服务器。我们需要提供一个安全的回调接口，验证回调签名，然后更新订单状态为“已支付”，并可能触发“待成团”->“待发货”的状态流转。

核心注意事项：支付回调接口必须做好幂等性处理。因为支付平台可能会多次回调。我们的逻辑应该是：根据回调中的商户订单号查询本地订单，如果订单已经是“已支付”状态，则直接返回成功，不再进行后续业务操作。防止重复给用户增加积分或发货。

5. 典型问题排查与性能优化实战

在实际开发和部署过程中，我遇到了几个比较典型的问题，这里分享排查思路和解决方案。

5.1 慢SQL查询导致页面加载缓慢

现象：团长在后台查看订单列表时，当订单量超过几千条，页面加载需要十几秒。排查：打开MySQL的慢查询日志（slow_query_log），定位到一条SQL：

SELECT o.*, u.nickname, gp.product_name FROM `order` o LEFT JOIN sys_user u ON o.user_id = u.id LEFT JOIN group_product gp ON o.group_product_id = gp.id WHERE o.group_id = #{groupId} ORDER BY o.create_time DESC LIMIT 0, 20;

分析：虽然只查20条，但ORDER BY在大量数据时，如果create_time字段没有索引，MySQL需要做全表扫描和文件排序（filesort），非常耗时。解决方案：

1. 为order表的group_id和create_time字段建立联合索引：idx_group_create (group_id, create_time)。这样，根据group_id筛选和按create_time排序都可以利用这个索引，效率极大提升。
2. 考虑对查询进行改造，如果nickname和product_name不是列表页必须展示的，可以放到详情接口中去查询，减少JOIN。

5.2 事务超时与数据库连接池耗尽

现象：在晚高峰下单时段，偶尔会出现“系统繁忙，请稍后再试”的错误，日志里看到TransactionTimeoutException或CannotGetJdbcConnectionException。分析：下单方法createOrder加了@Transactional，整个方法在一个数据库事务中。如果方法内业务逻辑复杂（比如还有复杂的校验、发消息等），或者网络延迟导致数据库操作慢，事务持有时间过长。同时，高并发下大量请求创建事务，会快速占满数据库连接池（如HikariCP默认的10个连接），新的请求获取不到连接就报错。解决方案：

1. 优化事务范围：将非核心的、非必须事务一致性的操作移到事务外。例如，发送通知消息（短信、微信模板消息）可以在事务提交成功后，通过异步事件（如Spring的ApplicationEvent）或消息队列来处理。
2. 调整超时时间：在@Transactional注解中设置timeout属性，例如@Transactional(timeout = 5)，单位为秒，避免单个事务无限制等待。
3. 优化数据库连接池配置：根据实际服务器性能和数据库承载能力，适当调大maximum-pool-size（最大连接数）。但这不是根本办法，连接数太多会压垮数据库。根本在于优化事务和SQL性能。
4. 引入异步处理：对于创建订单后的非实时任务，如生成提货码、更新用户购买统计等，可以放入线程池或消息队列异步执行，快速释放主事务连接。

5.3 微信支付回调验签失败

现象：用户支付成功，但我们的订单状态没有更新，查看日志发现支付回调接口报“签名验证失败”。排查：

1. 检查微信支付商户平台的API密钥是否正确配置在项目中。
2. 检查回调接口接收参数和生成签名参数的顺序。微信支付的签名生成规则要求所有参与签名的参数按照ASCII码从小到大排序（字典序）。我们自己验签时，也必须严格按照同样的规则拼接字符串。
3. 检查是否有特殊字符（如空格、换行）被错误地引入。最好在验签逻辑前后打印出待签名字符串和接收到的签名，进行对比。解决方案：编写一个可靠的验签工具方法，并对其进行充分的单元测试，模拟微信回调的各种参数情况。确保线上和测试环境的密钥配置隔离，避免误用。

5.4 前端页面频繁请求接口导致服务器压力大

现象：商品列表页为了显示实时库存，前端每几秒就轮询一次后端接口。分析：这种短轮询在用户量大的时候会给后端造成不必要的压力，很多请求返回的数据并没有变化。解决方案：

1. 对于实时性要求不极高的数据（如库存），可以在后端引入缓存（Redis）。将商品库存缓存起来，设置一个较短的过期时间（如5秒）。前端请求先查缓存，大大减轻数据库压力。库存变更时，同步更新缓存。
2. 对于需要强实时性的场景，可以考虑WebSocket或Server-Sent Events (SSE)技术，建立长连接，由后端在数据变化时主动推送。但这会带来额外的连接维护开销。
3. 最实用的优化：与前端协商，调整轮询频率。例如，用户停留在当前页面时，每10秒或30秒请求一次；当用户进行翻页、筛选等操作时，再实时请求。这是一种平衡用户体验和服务器压力的折中方案。

6. 部署上线与后期运维建议

项目开发完成后，部署是临门一脚。我习惯使用Docker进行容器化部署，这能保证环境一致性。

1. 编写Dockerfile：基于OpenJDK镜像，将打包好的Spring Boot Jar包复制进去，指定启动命令。

   FROM openjdk:11-jre-slim VOLUME /tmp COPY target/community-groupbuy-0.0.1-SNAPSHOT.jar app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

2. 使用docker-compose编排：将Spring Boot应用、MySQL、Redis等服务定义在一个docker-compose.yml文件中，一键启动整个环境。

   version: '3' services: mysql: image: mysql:8.0 environment: MYSQL_ROOT_PASSWORD: your_strong_password MYSQL_DATABASE: groupbuy volumes: - mysql_data:/var/lib/mysql ports: - "3306:3306" redis: image: redis:alpine ports: - "6379:6379" app: build: . depends_on: - mysql - redis environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/groupbuy?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai SPRING_REDIS_HOST: redis ports: - "8080:8080" volumes: mysql_data:

3. 日志收集与监控：在application.yml中配置好日志级别和输出格式（JSON格式便于后续用ELK收集）。使用Spring Boot Actuator暴露健康检查、指标等端点，配合Prometheus和Grafana搭建监控看板，关注应用QPS、响应时间、错误率以及JVM内存、GC情况。
4. 数据库备份：这是生命线。必须设置定时的MySQL全量备份和Binlog增量备份策略。可以利用云数据库的自动备份功能，或者自己写脚本通过mysqldump和crontab实现。

最后，关于这个系统，我个人最大的体会是：业务逻辑的清晰度永远优先于技术炫技。在开发过程中，我花了最多的时间不是在写代码，而是在和“团长”朋友反复沟通，画流程图，确认每一个状态（比如“已提货”和“已核销”是不是一回事？）。把业务边界和异常流程（比如用户下单后团长想修改商品价格怎么办？）想清楚，代码实现起来反而会顺畅很多。另一个小技巧是，对于这种给非技术人员使用的系统，后台操作的每一步成功或失败，都要给出明确、友好的提示信息，这能减少大量的客服沟通成本。这个项目上线后平稳运行了半年多，确实帮朋友那个小区把团购管理效率提升了好几个档次，这也算是我们码农用键盘创造的一点小小价值吧。

本文还有配套的精品资源，点击获取