企业官网建设流程全解析

最近有不少在校生跟我聊毕业设计选题，其中“基于SpringBoot的校园项目众筹融资平台”是出现频率很高的一个。这类题目听起来确实讨巧：一方面紧跟“高校创新创业”“互联网+”这些热点，另一方面SpringBoot又属于Java后端的主流方向，做起来不会走偏。但真正动手之后，很多人发现这个题目不是简单的CRUD堆功能，里面涉及的审核流、资金流水、支付对接、状态机设计，每一块都能单独拿出来问一轮。这篇文章我就把这个系统从技术选型到核心功能落地的完整思路捋一遍，希望能给正在做类似选题的同学一些实际参考。

提示：文章基于SpringBoot 2.7.x版本，JDK 1.8环境，数据库使用MySQL，前端采用Vue 2 + Element UI。这个组合在校园项目里生态最成熟，碰到问题基本都能搜到答案。

1. 为什么是“校园众筹”：选题价值与整体认知

1.1 这类系统本质上解决什么问题

校园众筹和商业众筹最大的区别在于“信任半径”。校内项目往往是小范围传播：一个创业团队要做智能小车，一个社团要办大型活动，一个实验室要采购器材，这些需求体量不大，但真实存在。学生愿意支持身边的同学，却缺少一个方便、可信的工具来发起支撑、完成支付和跟踪进展。这个系统要解决的，就是让“我发起一个项目，大家在线支持，项目方按承诺回报”这件事在校园内闭环运转起来。

放在毕业设计的语境里，这个题目的工程量也很合适。它既有面向普通用户的浏览、搜索、支持、订单功能，又有面向管理员的审核、统计、资金管理功能，角色划分清晰，业务规则明确，数据库表之间的关联关系能体现设计能力，又不会复杂到一个人做不完。如果你的论文需要实证分析或系统测试，这类系统也方便构造数据。

1.2 核心角色与功能边界

系统设计的第一件事是分清角色，别把功能一锅烩。我实际建模时划分了四种角色：

• 游客：查看项目列表、项目详情、发起人信息公开内容，不能支持。
• 注册用户（学生/教师）：支持项目、发起项目、管理自己发起的项目、维护个人信息。
• 项目方（申请人）：填写项目信息、提交证明材料、接收支持款项、发布项目进度。
• 平台管理员：审核项目、管理用户、查看资金流水、处理举报、数据统计。

角色确定后，功能边界就很清晰了。系统不做开放注册之外的多余功能，比如不用做IM聊天，不用做复杂的推荐算法，而是把精力集中在“一个项目从申请到成功结束”这条主线上。我在实际开发中甚至砍掉了站内信，改为邮件通知，省了大量工作量。

1.3 选择这个题目的判断标准

如果你正在纠结是否选这个题，可以对照几条标准：第一，你对SpringBoot的核心机制（自动配置、启动流程、依赖注入）有基本掌握，不至于连项目都跑不起来；第二，你愿意花时间在状态流转和事务处理上，这部分的细节决定了系统质量；第三，你的论文需要能画出清晰的业务流程图和时序图，众筹系统在这方面素材非常充足。反过来，如果你更偏好纯工具型应用或者算法型题目，这个题目可能不是最优选。

2. 技术选型：为什么用SpringBoot这一套

2.1 后端框架的选型逻辑

现在做Java后端毕设，SpringBoot几乎是默认选项，但不是因为它最“高级”，而是因为它让开发变得务实。SpringBoot带来自动配置和起步依赖，把大多数配置项收敛到约定范围内。对毕业设计来说，这意味着你不用花大量时间折腾XML配置，而是把时间花在业务逻辑上。

可能有人会犹豫，现在Spring Cloud微服务那么火，要不要引入注册中心、网关、配置中心？我的建议是不要。校园众筹系统属于典型的单体应用，并发量不大，引入微服务只会让架构显得臃肿，还会增加部署和调试的难度。答辩时老师更容易问“为什么要用微服务”而不是“为什么不用微服务”，这个理由很难讲清楚。单体应用配合合理的包结构，完全能体现工程能力。

整合MyBatis-Plus也是一个性价比很高的选择，它对单表CRUD做了大量简化，内置分页插件、代码生成器，还能通过LambdaQueryWrapper写出比较优雅的条件查询。比原生MyBatis少写不少XML，同时保留了手写SQL的能力——多表关联、报表统计这类复杂查询照样可以自定义。

2.2 前端方案与前后端分离

前端选了Vue 2 + Element UI，主要看中三点：组件齐全、文档中文友好、社区案例多。对于需要快速搭建后台管理界面的项目来说，Element UI的后台模板（vue-element-admin）可以省掉从零写布局的麻烦。当然，如果你对前端不熟，直接用Thymeleaf服务端渲染也完全可行——SpringBoot对Thymeleaf支持出色，前后端不分离能减少跨域和联调的工作量。

不过我更推荐前后端分离的写法，原因有两点：第一，现在企业里前后端协作基本都是这个模式，写在简历上更有说服力；第二，后期如果要把系统扩展成小程序端，后端接口可以复用。前端代码使用npm维护依赖，本地开发用axios代理转发请求，避开跨域问题。

2.3 关键中间件：Redis、MySQL与文件存储

Redis在这套系统里的定位很明确，就是做缓存和数据保护。项目列表页的热门数据缓存到Redis里，详情页的浏览量用Redis的increment做原子自增，下单接口用Redis的setnx做防重复提交。这些都是实用场景，比单纯用Redis存Session更能说明你对中间件的理解。

MySQL负责持久化，数据库引擎统一采用InnoDB，字符集采用utf8mb4，排序规则utf8mb4_general_ci。唯一要提醒的就是金额字段不要用float/double，必须用decimal。众筹项目一旦涉及退款结算，浮点数的精度问题会让你头大。

文件存储方面，我最终没有用FastDFS这类分布式文件系统，而是把图片和附件存到服务器本地目录，通过SpringBoot的静态资源映射暴露访问路径。每张图片存两版：原图和一个压缩后的缩略图。如果没有特殊要求，这种方式足够毕业设计使用。

2.4 版本的坑：JDK和SpringBoot如何搭配

版本搭配是个容易踩坑的地方。SpringBoot 3.x要求JDK 17以上，很多学校教学环境还在用JDK 1.8，所以建议直接用SpringBoot 2.7.x + JDK 1.8的经典搭配。MyBatis-Plus使用3.5.x，MySQL驱动用mysql-connector-java（SpringBoot 2.7已经自动管理版本）。要注意SpringBoot 2.7和3.x在配置写法上有一些差异，网上很多教程是混着写的，调试时报错先检查版本是否匹配。

如果你非得用SpringBoot 3.x，那就要注意javax.servlet套件改名成jakarta.servlet的问题，MyBatis-Plus需要至少3.5.3以上的版本才支持，老教程里的写法大概率跑不通。这里不展开说了，直接给结论：毕设求稳，用2.7.x就对了。

3. 数据库设计：资金类项目的表结构核心

3.1 数据表总览与关系梳理

这个系统的数据库表我最终拆成了13张，核心表为：用户表（sys_user）、角色表（sys_role）、用户角色关系表、项目表（project）、项目图片表、项目分类表（category）、支持订单表（orders）、支付流水表（payment_record）、回报等级表（reward_level）、项目进度更新表（project_update）、项目审核记录表（audit_record）、系统公告表（notice）、举报反馈表。下面这张表是核心表及用途说明。

3.2 项目状态机：贯穿系统的生命线

众筹项目的状态是这个系统的灵魂，强烈建议用状态机的方式设计，不要用简单的status字段放任状态乱跳。我定义的状态流转路径是：

1. 草稿（DRAFT）：用户填写项目信息后保存，还没有提交审核。
2. 待审核（PENDING_AUDIT）：提交审核后进入平台管理员待办列表。
3. 审核不通过（AUDIT_REJECTED）：管理员驳回，填写驳回原因，用户修改后可重新提交。
4. 众筹中（FUNDING）：审核通过后项目上线展示，用户可进行支持操作。
5. 众筹成功（SUCCESS）：项目在规定期限内达到目标金额，触发成功逻辑。
6. 众筹失败（FAILED）：项目到期未达到目标金额，系统自动回退资金（实际毕设里做状态变更和模拟退款）。
7. 已结算（SETTLED）：项目成功后，平台将募集资金扣除服务费后结算给发起人。

这里要特别留意“众筹成功”的判断逻辑。我采用的是：当已支持金额首次大于等于目标金额且在众筹进行中时，立刻改变状态并通知发起人。同时要允许“超募”，即目标金额达成后用户依然可以继续支持，但限制支持截止时间。这一逻辑在代码里要保证线程安全，详见第4章。

3.3 订单表设计：为什么订单和支付流水分两张表

订单表（orders）和支付流水表（payment_record）分开设计是资金系统的常见做法，也是答辩时的加分点。订单表记录业务层面的事实：用户在哪个时间支持了哪个项目多少钱，对应哪个回报等级。支付流水表记录资金层面的过程：一次支付尝试产生一条流水，包括支付单号、支付渠道、回调时间、支付状态。

这样分离有什么好处？第一，业务回滚和支付状态解耦，哪怕支付回调延迟，订单状态依然能正确反映业务状态；第二，一张订单可以对应多次支付尝试（比如第一次支付失败后重新发起），每笔尝试都有独立流水，方便对账；第三，审计时能清楚看到一笔订单的资金轨迹。在设计时，我给订单表设置了唯一订单号（order_no，业务生成，规则是日期+随机串），给支付流水表设置了唯一支付单号（payment_no，由支付渠道或系统生成），并给这两个字段建立了唯一索引。

3.4 冗余字段是刻意的：用户余额与项目已筹金额

有同学在设计表时追求“极致的第三范式”，坚决不放冗余字段，结果每次展示列表都要做一次SUM聚合查询，页面上数据一多就慢。我在项目表和用户表里刻意加入了冗余字段：

• project表里存raised_amount（已筹集金额），而不是实时统计订单表。
• sys_user表里存balance（可用余额），用于后续的余额支付和退款操作。

这些字段在用户支持成功、退款、提现时同步更新。虽然牺牲了一定的写操作性能，但换来了读操作的高效率和代码的简洁性。毕业设计的数据量根本体现不出写性能的差异，这种取舍是值得的。

4. 核心业务逻辑：从发布到放款的完整链路

4.1 项目发布与审核：提交了什么、审核什么

用户发起的项目，涉及编辑内容和上传图片。前端把富文本内容和图片地址提交到后端，后端做字段校验，比如：标题长度限制在5到50个字符，项目描述不少于200字，目标金额在1000到100000元之间，截止日期在当前时间一周以后、半年以内。这些校验规则不只是在后端做，前端表单也要同步校验，提升用户体验。

方案有两个字段需要单独说明：一个是“项目类型”，对应自定义的分类表，包括科技创新、公益环保、文体活动、学术研究、创业实践等；一个是“回报说明”，众筹不是单纯的捐款，发起人通常要承诺给支持者相应的回报，所以设计了回报等级表，比如支持1元表示感谢，支持50元赠送定制明信片，支持200元赠送最终产品体验装。

项目提交后进入审核待办列表，管理员可以看到项目所有信息，包括发起人的身份认证材料。审核操作是“通过”或“驳回”，驳回时必须填写原因。这里我加了一个不算复杂却很实用的功能：驳回原因模板。管理员常用理由例如“项目描述不完整”“目标金额不合理”“图片涉嫌侵权”，点击模板即可填入，省得每次手打。审核记录保存到audit_record表，支持用户多次提交多次审核的审核历史回溯。

4.2 用户支持项目：这一单经历的完整流程

当用户在前端项目详情页发起支持时，后端处理逻辑是一套严谨的流程，用代码描述大致是这样的：

@Transactional(rollbackFor = Exception.class) public PayResult supportProject(SupportRequest request) { // 1. 幂等校验：防止同一次请求重复提交 String requestId = request.getRequestId(); Boolean ifAbsent = redisTemplate.opsForValue() .setIfAbsent("support:req:" + requestId, "1", Duration.ofSeconds(30)); if (!ifAbsent) { throw new BizException("重复请求，请勿频繁操作"); } // 2. 状态校验：项目必须处于众筹中 Project project = projectMapper.selectById(request.getProjectId()); if (project == null || !ProjectStatus.FUNDING.equals(project.getStatus())) { throw new BizException("项目当前不可支持"); } // 3. 截止时间校验 if (project.getDeadline().isBefore(LocalDateTime.now())) { throw new BizException("项目已截止"); } // 4. 创建订单（状态为待支付） Order order = new Order(); order.setOrderNo(generateOrderNo()); order.setUserId(request.getUserId()); order.setProjectId(project.getId()); order.setAmount(request.getAmount()); order.setStatus(OrderStatus.WAIT_PAY); orderMapper.insert(order); // 5. 创建初始支付流水 PaymentRecord record = new PaymentRecord(); record.setOrderId(order.getId()); record.setPaymentNo(generatePaymentNo()); record.setAmount(request.getAmount()); record.setStatus(PayStatus.UNPAID); paymentRecordMapper.insert(record); // 6. 返回待支付信息，由前端调用支付接口 return new PayResult(order.getOrderNo(), record.getPaymentNo(), request.getAmount()); }

流程拆开看有这么几个关键点：

• 幂等控制：利用Redis的setnx命令做防重。用户在支付前可能会点多次“立即支持”按钮，如果不加这个控制，会生成多条相同金额的待支付订单。

• 事务边界：创建订单和创建支付流水在同一个事务中，要么都成功，要么都回滚。这里用@Transactional（rollbackFor）确保运行时异常触发回滚。

• 乐观校验：在检查项目状态和创建订单之间有时间差，如果项目在这期间被终止（比如管理员下架），会在支付回调阶段再次校验。

生成订单号的时候我用的是一个简单的规则：时间戳（yyyyMMddHHmmss）+ 用户ID后四位 + 4位随机数字，确保唯一性。实际开发中还可以用雪花算法，但毕业设计场景不必引入额外的生成器组件。

4.3 支付模块：模拟支付才是正确的打开方式

很多同学一看到“支付”就害怕，觉得要申请微信支付商户号、支付宝开放平台，流程繁琐还有资质门槛。其实毕业设计的支付模块完全可以做成“模拟支付”：

• 系统维护一个“虚拟支付通道”，后端提供一个模拟支付接口，接收订单号、支付卡号等信息。
• 前端展示一个模拟支付弹窗，用户点击“确认支付”后，后端把订单状态置为已支付，同步更新项目已筹资额。
• 在支付这步之前，加上“余额支付”或者“模拟第三方支付”的选项，处理逻辑可以做成策略模式，方便后续扩展真实的支付渠道。

这样做的好处是：开发周期可控，不需要申请商户号，也不涉及真实资金风险，而且业务闭环依然完整——订单、流水、回调、后续逻辑照样都在。答辩时如果老师问“你的支付怎么实现的”，你可以如实说“采用了模拟支付的方式，接口设计参考了微信支付V3的接口规范，预留了替换为真实支付的扩展点”。这个回答比支支吾吾说“不方便接真实支付”要高一个档次。

4.4 支持成功后：项目金额的同步与版本控制

用户支付成功后，除了更新订单状态，还要做下面这几件事：

1. 把订单状态从待支付更新为已支付。
2. 在乐观锁的机制下增加项目表的raised_amount。
3. 增加用户对项目的支持记录（用于项目详情页展示“支持者名单”）。
4. 给项目发起人发送站内消息（或邮件）通知。

第2步是并发控制的关键，直接用如下SQL语句，避免并发更新丢失：

UPDATE project SET raised_amount = raised_amount + #{amount} WHERE id = #{projectId}

这种写法利用数据库行锁和单条UPDATE的原子性，比先查后改（select then update）安全。每次更新后判断新的raised_amount是否达到target_amount，如果是，调用项目成功处理逻辑。判断动作在事务内完成，避免了并发场景下两个请求同时触发“项目成功”的问题。

还需要注意的是，项目成功状态变更后要同时更新项目表的success_time字段，之后结算流程依赖这个时间计算周期。

4.5 项目结算：提现与退款的处理思路

项目众筹成功后，进入结算流程。此时平台要从募集金额中抽取一定比例的服务费（比如5%），剩余金额转入发起人可提现余额。这个流程我在系统中拆成了两个操作：

• 结算操作：管理员在后台确认结算，系统生成一条结算记录，把项目募集金额按比例拆分后，在发起人账户余额中增加“可提现金额”，并把项目状态改为已结算（SETTLED）。
• 提现操作：发起人发起提现申请，管理员审批，审批后状态变更为“提现成功”。通知模块记录提现申请单和审批记录。

众筹失败的项目走另一条逻辑：系统性遍历已支付订单，执行“模拟退款”操作——把订单状态变为已退款，并把支持金额退回支持者的余额。这里我用了一个定时任务（Spring Task），每秒扫描所有状态为“已支付”且对应项目状态为“众筹失败”的订单，分批处理退款。定时任务的表达式是每10秒执行一次，实测足够及时且不会对数据库造成压力。

5. 多维度加分项：让系统从“能跑”变成“耐看”

5.1 定时任务与状态自动流转

系统有三个定时任务必须做：

• 项目到期检测：每5分钟扫描所有处于众筹中但已过截止时间的项目，把未达到目标金额的项目改为“众筹失败”，达到的改为“众筹成功”。注意这个任务要和前文提到的“实时判断成功”逻辑共存，二者是互补的：实时判断保证用户支付后立即生效，定时任务兜底保证到期自动处理。
• 超时未支付订单关闭：每10分钟扫描创建超过30分钟且状态为待支付的订单，自动置为“已关闭”。这模拟了真实电商系统的超时关单，避免僵尸订单占用数据。
• 退款批处理：每10秒扫描需要退款的订单，执行退款更新操作。

SpringBoot的定时任务非常好用，主启动类加@EnableScheduling，业务类加@Scheduled(cron = "表达式")即可。要注意的是定时任务默认是单线程串行执行的，如果有多个任务，建议配置线程池：

@Configuration public class SchedulingConfig implements SchedulingConfigurer { @Override public void configureTasks(ScheduledTaskRegistrar taskRegistrar) { taskRegistrar.setScheduler(Executors.newScheduledThreadPool(5)); } }

5.2 消息通知：站内信还是邮件

一开始我做了站内信，后来发现功能复杂度上来了：要标已读、未读、列表分页，还要在前端做小红点。为了控制工作量，我最终选择了邮件通知作为主要的通知方式：项目审核通过/驳回、项目众筹成功/失败、每笔支持成功、项目结算完成都会触发邮件。SpringBoot整合JavaMailSender非常简单，在application.yml里配置邮箱SMTP信息就能用。

用到邮件有一个小坑需要注意——发送邮件是IO操作，比较耗时，如果是在支付回调的业务逻辑里同步发送，用户请求会变慢。我的做法是引入Spring的事件监听机制：业务方法里发布一个“支付成功事件”，监听器异步处理邮件发送。

@Service public class OrderEventListener { @Async @EventListener public void onPaySuccess(PaySuccessEvent event) { mailService.sendPaySuccessMail(event.getEmail(), event.getOrderNo(), event.getAmount()); } }

记得在启动类或配置类开启@EnableAsync，否则@Async不生效。这个设计也是一个不错的答辩加分点。

5.3 文件上传：图片压缩与资源映射

项目申请时的图片上传、进度更新时的图片上传，都走同一个上传接口。我在Config中配置了虚拟路径映射：

@Configuration public class WebConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

这样前端访问“/upload/xxx.jpg”就能直接映射到服务器的实际存储目录。上传时我会用Thumbnator库压缩图片，存一张原图一张800px宽度的缩略图，压缩质量设为0.8，既保证了加载速度，又不会过度损失清晰度。为了安全，文件名统一用UUID重命名，不保留用户上传的原始文件名，防止路径穿越和非法文件覆盖。

5.4 数据统计：管理员的仪表盘

管理后台首页我放了一个统计面板，包含以下指标：用户总数（本周新增）、项目总数（按状态分布）、众筹成功总金额、平均项目达成率、分类热度排行Top5。这些统计用三条SQL就能查出来，配合ECharts展示，比堆砌一堆无用图表要清晰得多。这里有一条SQL是统计各分类项目数量和平均达成率的，写法如下：

SELECT c.name, COUNT(p.id) AS project_count, AVG(p.raised_amount / p.target_amount) AS avg_rate FROM category c LEFT JOIN project p ON p.category_id = c.id AND p.status IN ('SUCCESS', 'FUNDING') GROUP BY c.id ORDER BY project_count DESC LIMIT 5

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

6.1 项目启动失败：建立数据库连接超时

场景：本地启动SpringBoot项目，控制台一直报“Cannot create PoolableConnectionFactory”。多半是MySQL没有启动，或者用户名密码配置错误。检查步骤：先确认MySQL服务是否运行（Windows下查看服务列表，Mac下用brew services list）；再确认数据库是否创建（需要手动执行CREATE DATABASE，MyBatis-Plus不会自动建库）；最后核对application.yml中的url、username、password。url中的serverTimezone要设置为Asia/Shanghai，否则会报时区错误。

另外一个隐蔽问题：pom.xml依赖引入了MySQL驱动但版本和数据库不兼容。SpringBoot 2.7默认管理的mysql-connector-java版本是8.0.x，如果你的MySQL是5.7，一般也能连，但如果遇到连接协议报错，可以显式指定驱动版本为5.1.49，同时url里添加useSSL=false。

6.2 登录会话失效：刷新页面就跳登录

前后端分离模式下，前端axios请求必须携带Cookie或Token，否则后端每次都会认为是新会话。我用的是JWT方案：用户登录成功后，后端生成Token返回给前端，前端存储在本地并拦截器统一在请求头添加Authorization字段。遇到“刷新页面就跳登录”的问题，一般是前端路由守卫判断Token是否存在的方式不对，或者Token过期没有做刷新处理。排查思路：先看浏览器的LocalStorage里是否有Token，再看网络请求头是否带了Authorization，最后看后端拦截器是否放行了登录接口和静态资源。

6.3 支付成功后列表金额没变：事务没生效或缓存未刷新

这是典型的“回调成功但显示滞后”问题。可能的原因有三个：第一，更新项目金额的SQL写错了条件，WHERE里没有加project_id；第二，事务没有正常提交，检查类上是否有@Transactional，以及是否被同类内部方法调用导致代理失效；第三，列表页读取的是Redis缓存，支付成功后没有删除或更新缓存。我的建议是：列表页缓存设置一个可接受的过期时间（比如60秒），支付成功后调用缓存删除方法强制刷新，两相结合，数据一致性体验最佳。

6.4 并发测试：两个人同时支持同一项目，金额会漏吗

这类问题在答辩时经常被问。其实用前面提到的UPDATE原子操作，不会漏算。为了验证，我写了一个并发测试类：用CountDownLatch模拟100个线程同时支持同一个项目，每个支持1元，目标金额100元，运行后checkedAmount与预期无误。这也验证了项目状态只被变更一次。如果你在测试中发现金额少了，大概率是代码里用了“先select再update”模式，需要按上文修改。

6.5 常见问题速查表

7. 论文与技术文档：怎么把工作量“写出厚度”

7.1 从“功能叙述”升级为“需求分析”

很多毕业论的第二章就是列功能菜单，这太单薄了。正确的做法是往前一步，先写“可行性分析”：从技术可行性（SpringBoot成熟生态）、经济可行性（开源工具为主，部署成本低）、操作可行性（界面友好，用户学习成本低）、法律可行性（涉及模拟资金操作，不触犯真实金融法规合规问题）四个维度论证。再写“功能性需求”和“非功能性需求”，非功能性需求里要提到安全性（密码加密传输，使用BCrypt哈希存储）、性能（列表页响应时间低于500ms）、可用性（核心操作有确认提示和操作回滚）等。

用例图、活动图、时序图这一套UML图在论文里也是必需的。“项目支持”这个场景至少可以画三张图：用户支持下单的时序图、系统支付回调的状态活动图、管理员审核项目的用例图。这些图不需要用专业建模工具画，用ProcessOn在线工具就能搞定。

7.2 数据库设计说明书：每个表都要有故事

论文里的数据库设计章节，不能只放表结构。每个核心表要说明：为什么这张表要存在，它解决了什么业务问题，字段设计的考虑是什么。比如orders表，你要写清楚为什么需要order_no和payment_no两个编号，为什么要冗余project_id而不是通过某个中间表关联，什么时候会出现一个订单对应多条支付流水。把这些写透，比堆10张ER图更能体现设计能力。

7.3 测试章节：不只是截图

测试章节最容易写成“点了一下按钮，功能正常”，这毫无技术含量。建议至少包含：

• 单元测试：对核心工具类、Service层的关键方法写JUnit测试，展示测试通过。
• 接口测试：用Postman导出接口测试用例，展示对接口的请求和响应。
• 功能测试：对每个功能模块编写测试用例表格，字段包括用例编号、前置条件、操作步骤、预期结果、实际结果。覆盖正常流程和异常流程各至少一个场景。
• 性能测试：在学校机器上用JMeter跑一个简单的压测，比如100线程并发访问项目列表接口，记录响应时间、吞吐量、错误率，把结果和分析写进论文。

做到这四层，论文的测试章节就非常扎实了，答辩时可以理直气壮地说“系统经过了系统的测试验证”。

7.4 部署文档：本地跑通和服务器部署怎么选

如果只需在答辩现场演示，本地部署完全没问题，准备一份启动说明文档：环境要求、数据库初始化脚本、配置文件修改说明、启动步骤。如果想加分，可以买一台轻量云服务器，把项目部署上去。部署方案是：后端jar包用nohup后台启动，前端dist目录用Nginx托管，MySQL用云数据库，Redis自建或用云Redis。首次部署踩坑最多的就是防火墙端口和安全组，记得开放8080（后端）、3306（数据库）等端口，后端接口的跨域配置要改成生产环境对应的域名地址。

8. 写在最后的几点个人心得

做这个系统前前后后花了大概三周课余时间，如果把写论文的时间也算上，差不多是五周。第一周搭建框架并完成用户和项目模块，第二周处理订单和支付逻辑，第三周补上定时任务、统计报表和部署，之后两周集中写文档。时间分配上，业务逻辑和状态设计占了大头，前端反而没有花太多精力。

回头看，有两点体会比较深。第一，状态机设计真的要在编码前想清楚，把所有可能出现的事件和状态变更列成表格，代码实现就是水到渠成的事；否则边写边改，很容易出现“某个状态下不该有的操作居然被允许”的漏洞。第二，别怕用模拟方案，支付用模拟、消息通知发邮件、文件存本地，这些都是毕业设计里合理的工程取舍，关键在于你要能说清楚模拟和真实方案之间的差异。

最后分享一个小技巧：写代码时，把每个核心业务场景的关键路径日志打清楚，包括进入方法、关键判断结果、异常堆栈、方法调用的返回结果。答辩的时候打开日志现场演示，比口述一百句“没问题”都有说服力。