SpringBoot+Vue3+MyBatis众筹平台实战：前后端分离架构设计解析

1. 项目概述与整体架构思路

1.1 这个项目到底解决什么问题

先说个很多人容易忽略的点。市面上能跑的众筹系统其实不少，但绝大多数是单体应用，或者只用模板引擎渲染页面，前后端代码搅在一起，改一行前端样式要重启整个后端服务。更麻烦的是，如果你想拿它当毕设或者接私活，想换个前端框架、想改个数据库，几乎是动一发而动全身。

这个"善筹网"项目走的是一条截然不同的路子：SpringBoot 负责纯后端接口，Vue3 负责纯前端页面，MyBatis 作为持久层框架负责与 MySQL 交互。前后端通过 RESTful API 通信，数据格式统一用 JSON。也就是说，前端页面和后端服务完全解耦，你可以把 Vue3 那套代码单独扔到 Nginx 上，也可以把 SpringBoot 服务单独跑在一台云服务器上，两边互不干扰。

我拿到这套源码之后第一感受是：它的功能边界切得非常干净。前台面向普通用户，有注册登录、浏览众筹项目、发起众筹、支持项目、个人中心这些模块；后台面向管理员，有会员管理、项目审核、订单管理、分类管理、系统公告等模块。前后台用的是同一套后端接口，只是通过权限角色来控制谁能访问哪些接口，而不是搞出两套完全独立的系统。这种设计在真实项目中很常见，也是面试官比较认可的一种做法。

1.2 技术选型背后的真实考量

先聊聊为什么是 SpringBoot + Vue3 这个组合，而不是别的。

后端选 SpringBoot，核心原因是它把 Spring 那堆繁琐的 XML 配置全部干掉，用自动配置加注解的方式让开发者把精力集中在业务逻辑上。对于众筹平台这种业务模式相对清晰、但业务规则有一定复杂度的系统，SpringBoot 的生态足够成熟，无论是安全框架、对象存储、还是支付对接，都有现成的轮子可以直接用。

前端选 Vue3，是因为它相比 Vue2 在响应式系统上做了重构，用 Proxy 替代了 Object.defineProperty，性能更好，同时对 TypeScript 的支持更加友好。我自己的习惯是，新项目能上 Vue3 就不回头用 Vue2，除非是要维护老项目。而且 Vue3 搭配 Vite 构建工具，开发环境的热更新速度确实要比 Webpack 快很多，体感差异非常明显。

持久层选 MyBatis 而不是 JPA，这个也需要说清楚。JPA（Hibernate）虽然能帮你自动生成 SQL 建表语句，减少大量样板代码，但它的黑盒属性也让不少人头疼——复杂查询搞不清楚到底生成了什么 SQL，性能出问题时排查起来很痛苦。MyBatis 则保持了 SQL 的完全可控，复杂的多表关联、动态查询、统计报表都能写得明明白白。众筹系统里"项目列表"这种查询往往需要 ON 很多张表，用 MyBatis 的动态 SQL 处理起来非常顺手，这也是很多国内团队更偏好 MyBatis 的原因。

数据库选 MySQL，就没有太多悬念了。它开源免费、部署简单、资料丰富，对于教学级或者中小型商业场景完全够用。配合 MyBatis 的逆向工程，数据表建好之后可以直接生成对应的实体类和 Mapper 接口，开发效率能提升一大截。

提示：如果你接手这类源码，建议先看它的依赖版本。SpringBoot 2.x 和 3.x 的写法有些地方不兼容，尤其是javax包改成jakarta包，这是改动时最容易踩的坑。

2. 数据库设计：众筹业务的地基工程

2.1 核心表结构拆解

一个众筹平台的数据库设计，往简单了说就是"谁在什么时候用什么方式支持了哪个项目多少钱"。这句话拆开，就是四张核心表：用户表、项目表、订单表（支持记录表）、分类表。但真要落地，远远不止这四张表能搞定。

我看到的这套设计，表结构规划得比较完整，大致包含以下角色：

• 前台用户侧：用户表、收货地址表、用户关注的项目表（用于"我关注的项目"功能）、用户发起的项目表。
• 众筹项目侧：项目表、项目分类表、项目图片表（一个项目通常有多张图，封面图、详情图）、项目回报档位表（不同支持金额对应不同的回报品）。
• 交易侧：订单表、支付流水表、退款记录表。
• 后台管理侧：管理员表、角色表、权限表（或者直接用简单的状态字段控制，根据项目规模而定）。

有一个比较容易被新手忽略的点：项目表里应该有一个字段专门存"当前已筹集金额"。这个字段是最容易出并发问题的。如果用户每次支持项目都去 COUNT 一遍所有订单，再 SUM 出总金额，数据量小的时候没感觉，等到订单量上来，一次查询要遍历几万条订单记录，性能会明显下降。所以这套设计里采用了冗余字段的方式，每次支付成功就原子性地更新这个累计金额，同时在代码里做好幂等控制，防止重复更新。

项目表的核心字段大概是这样：

2.2 为什么要单独设计一张回报档位表

这是众筹项目区别于普通商城系统的核心地方。普通商城下单买的是固定商品，价格是现成的；但众筹项目不一样，用户支持 50 元拿到的可能是"感谢信 + 电子证书"，支持 500 元拿到的可能是"定制纪念品 + 实物回报"，支持 5000 元可能直接获得"项目周边全套 + 优先体验资格"。

如果不在数据库里把回报档位建模，而是把回报信息塞进项目表的大文本字段里，后续统计"某个档位被支持了多少次""哪些档位最受欢迎"就会非常痛苦，也容易产生数据不一致。

回报档位表的字段大致如下：

• id：主键
• project_id：关联哪个项目
• level_name：档位名称，比如"支持者""铁杆粉丝""合伙人"
• support_amount：支持金额门槛
• reward_content：回报物说明
• reward_image：回报物图片
• limit_count：限购数量，null 表示不限量
• already_count：已被支持次数

有了这张表之后，前台展示"选择支持方案"的界面就非常好做了，后端只需要根据 project_id 查出所有档位返回给前端，前端渲染成几张卡片供用户选择即可。而且这张表还承担了业务判断的职责——某个档位如果设置了限购数量且已经售罄，就不允许再下单，这个逻辑在后端接口里要层层判断。

2.3 状态机设计：众筹项目的生命旅程

众筹项目的状态管理是整个系统最容易写乱的地方。我见过不少项目把状态字段做成一个 INT，但代码里到处是魔法数字，没人说得清 3 到底表示"审核通过"还是"众筹成功"。

这套设计把状态定义得比较清楚，项目状态从草稿开始，一路流转到成功或失败：

• 0 草稿：用户编辑中，尚未提交审核
• 1 待审核：用户提交后，等待管理员审核
• 2 审核通过：管理员审核通过，项目尚未开始计筹
• 3 筹集中：项目正式上线，用户可以支持
• 4 众筹成功：到达截止日期，且已筹金额 >= 目标金额
• 5 众筹失败：到达截止日期，但已筹金额 < 目标金额
• 6 已下线：管理员主动下线违规项目

这个状态机的好处是，所有关键业务分支都可以围绕状态来写。比如说，管理员只能审核"待审核"状态的项目，用户只能给"筹集中"状态的项目付款，项目一旦进入"众筹成功"或"众筹失败"状态，就不能再发起新的支持订单。状态机的设计就是业务的骨架，骨架立住了，后面的业务逻辑就好写很多。

注意：项目状态的变更不能只靠前端按钮控制，后端接口必须做状态校验。比如用户修改项目内容时，如果项目已经处于"筹集中"状态，后端要直接拒绝修改；否则就会出现项目上线后还能篡改目标金额和回报内容的严重漏洞。

3. 后端核心实现：SpringBoot + MyBatis 的项目落地

3.1 后端工程结构怎么组织

很多新手拿到源码会一头雾水，因为包结构五花八门。这套项目的包结构属于比较主流的"按功能模块分包"，比按技术类型分包更符合实际业务场景。

浅浅列一下：

com.shanchou ├── common // 通用模块：统一返回结果、全局异常、工具类 ├── config // 配置类：拦截器、跨域、文件上传等 ├── controller // 控制层 │ ├── admin // 后台管理接口 │ └── front // 前台接口 ├── service // 业务逻辑层 ├── mapper // MyBatis 映射接口 ├── entity // 数据库实体 ├── dto // 数据传输对象 ├── vo // 视图对象 └── utils // 工具类

我特别说下dto和vo的区别，这个很多初级开发者搞不清楚。DTO（Data Transfer Object）是请求参数的载体，比如登录接口接收的LoginDTO里有账号和密码；VO（View Object）是返回给前端展示的数据载体，比如项目详情页需要的ProjectDetailVO，里面可能聚合了项目基本信息、发起人信息、回报档位列表、支持记录列表。把 VO 和实体类分开的好处是，你可以自由组合返回的字段，不用把实体里所有字段都暴露给前端——尤其是那些password之类的敏感字段，绝对不能出现在 VO 里。

3.2 登录鉴权方案：JWT 与拦截器

前后端分离的架构下，Session 方案体验不太好，原因在于前端不在同一域名下，跨域请求携带 Cookie 的时候要处理很多麻烦事。这套系统采用的是 JWT（JSON Web Token）方案。

用户登录成功后，后端生成一个 token 返回给前端，前端把它存在 localStorage 或者 Pinia 的 store 里，每次请求时在请求头加Authorization: Bearer ${token}。后端通过拦截器（HandlerInterceptor）统一校验 token，解析出用户 ID 后放入请求上下文。

有一个细节值得提：众筹项目不仅要做登录拦截，还要做权限区分。普通用户和后台管理员是两批人，访问的接口完全不同。所以拦截器要能识别当前用户角色，判断该角色是否有权限访问这个接口。最简单的做法是在自定义注解里声明接口要求的角色，比如@RequireRole("ADMIN")，然后拦截器里去解析注解、比对角色，没有权限的直接返回 403。

JWT 本身有一个绕不开的问题：token 一旦签发，在过期之前无法主动注销。对于管理员把某个用户拉黑这种场景，JWT 方案就无法立刻生效，必须等 token 自然过期。如果网站对实时安全性要求比较高，可以引入 token 黑名单机制，或者在 Redis 里存一份有效 token 列表，每次校验都查一下 Redis。不过对于教学级项目来说，纯 JWT 方案已经够用，只要把过期时间设置得合理（比如 7 天），就能在易用性和安全性之间取得平衡。

3.3 MyBatis 动态 SQL 的应用场景

MyBatis 的杀手级特性就是动态 SQL，它在众筹系统的项目列表查询里表现得淋漓尽致。前台的项目列表页一般需要支持多条件筛选：按分类查、按状态查、按关键词搜、按众筹进度排序、按目标金额区间筛选……这些条件组合起来，用一条固定的 SQL 是写不出来的，必须动态拼接。

我抄一段典型的 Mapper XML 写法，大家感受一下：

<select id="selectProjectPage" resultType="com.shanchou.entity.Project"> SELECT p.*, u.nickname AS creator_name, (SELECT COUNT(*) FROM t_order o WHERE o.project_id = p.id) AS order_count FROM t_project p LEFT JOIN t_user u ON p.creator_id = u.id <where> <if test="categoryId != null"> AND p.category_id = #{categoryId} </if> <if test="status != null"> AND p.status = #{status} </if> <if test="keyword != null and keyword != ''"> AND (p.title LIKE CONCAT('%', #{keyword}, '%') OR p.description LIKE CONCAT('%', #{keyword}, '%')) </if> <if test="minAmount != null"> AND p.target_amount &gt;= #{minAmount} </if> </where> ORDER BY p.create_time DESC </select>

<where>标签会自动处理第一个条件前面的AND，避免拼接出WHERE AND xxx这种语法错误。这个机制理解起来不难，但很实用，做多条件筛选离不开它。

不过也提醒一句：动态 SQL 虽然灵活，但写多了容易让 XML 变得臃肿难维护。一定要在 SQL 上面写注释，不然三个月后回过头来连自己都看不懂这个语句在干嘛。

3.4 订单支付流程与金额精度处理

众筹支持项目的核心链路是"选项目 → 选回报档位 → 创建订单 → 模拟支付 → 更新项目金额 → 更新档位已支持次数"。因为是教学项目，一般不会真的对接微信支付或者支付宝，而是用一个"模拟支付接口"来完成。但这个过程该有的业务逻辑一步都不能少。

支付成功后要做的几件事需要在一个事务里完成：

1. 更新订单状态为"已支付"。
2. 更新current_amount增加本次支付金额。
3. 更新supporter_count加一。
4. 更新回报档位的already_count加一。
5. 检查项目是否已经因为本次支付而达到目标金额，如果达到了，直接更新项目状态为"众筹成功"。

这里有一个绕不开的坑：金额计算必须用 BigDecimal，不能用 Double 或者 Float。Double 在浮点运算时会产生精度误差，比如 0.1 + 0.2 在 Java 里运算结果是 0.30000000000000004，这在涉及钱的场景里是绝对不能容忍的。所以所有跟金额有关的字段，数据库用 DECIMAL(10,2)，Java 代码用 BigDecimal，传入参数要用金额格式校验。

再补充一个并发场景的处理。假设某个回报档位限购 50 份，两个用户同时下单购买最后 2 份，就会出现超卖问题。在主流做法里，最简单的兜底方案是在更新数量的 SQL 里加上条件判断：

UPDATE t_project_support_level SET already_count = already_count + 1 WHERE id = #{levelId} AND (limit_count IS NULL OR already_count < limit_count)

如果这次 UPDATE 影响的行数为 0，说明已经卖完了，后端直接抛业务异常。这种"乐观锁 + 条件更新"的方式比单纯在 Java 代码里判断并发安全要靠谱得多。

经验之谈：我接手过好几个众筹/秒杀类项目，超卖问题的根源永远都是"先查后改"的时序漏洞。正确的姿势是：用数据库的原子操作作为最终防线，代码层面的校验只是前置提醒。

4. 前端核心实现：Vue3 + 组件化开发

4.1 前端工程结构与核心依赖

前端部分采用 Vue3 + Vite + Pinia + Vue Router + Axios 这套主流组合。如果对 Vue 生态有一定了解，看到这几个关键词就能大概猜到工程结构了。

典型的目录组织如下：

src ├── api // 接口请求封装 ├── assets // 静态资源 ├── components // 公共组件 ├── layout // 布局组件（前台布局、后台布局） ├── router // 路由配置 ├── stores // Pinia 状态管理 ├── views // 页面视图 │ ├── front // 前台页面 │ └── admin // 后台管理页面 ├── utils // 工具函数 ├── App.vue └── main.js

views区分前台和后台，这个思想跟后端的controller区分admin和front遥相呼应，前后端的设计语言一致，维护起来省不少脑力。

Vite 相比 Vue CLI 的体验优势在开发阶段非常明显，冷启动速度快，热更新反应也快。如果你之前还在用 Vue CLI，我建议花点时间迁移到 Vite，配置 Vue CLI 的vue.config.js迁移到 Vite 的vite.config.js，改动量不大，收益却很大。

4.2 核心页面与交互逻辑

前台最重要的两个页面是项目列表页和项目详情页。

项目列表页采用瀑布流方案（两列或多列卡片布局），每张卡片展示封面图、项目标题、发起人昵称、当前已筹金额、目标金额、支持人数和进度条。进度条是众筹系统里非常关键的视觉元素，它需要根据current_amount / target_amount计算百分比，并配上不同的颜色——进度低于 30% 用灰色，30% 到 80% 用蓝色，超过 80% 用橙色，达到 100% 用绿色。这些视觉细节虽然不影响功能，但直接影响用户对项目的信任感。

项目详情页的信息层次要设计得很清晰：

• 顶部：项目封面大图 + 核心项目信息（标题、目标金额、已筹金额、进度条、剩余天数）。
• 中部：项目详细介绍，图文混排内容。
• 底部：支持方案卡片列表，每个卡片展示回报档位名称、支持金额和回报内容。
• 右侧或底部：项目发起人信息，包括头像、昵称、历史发起的项目。

在前端交互层，选中某个支持方案后点击"立即支持"，会弹出确认对话框，显示"支持金额：500 元，回报：定制纪念品 + 电子感谢信"，确认后调创建订单接口，跳转到订单确认页。这套交互流程看似简单，但做了很多 UX 设计上的细节打磨，比如"支持成功"后的反馈提示要足够明显，让用户感到自己的动作真的生效了。

4.3 API 封装：Axios 拦截器的正确用法

前后端分离项目的体验好坏，很大程度取决于 API 层封得好不好。这套项目使用 Axios 做请求库，在拦截器里做了三件统一的事情：

第一，请求头统一注入 token。从 Pinia 的 store 或 localStorage 里取 token，加进Authorization头。这一步省去了每个接口手动传 token 的麻烦。

第二，统一处理 HTTP 错误和业务错误。后端返回的 JSON 格式通常是：

{ "code": 200, "message": "操作成功", "data": { ... } }

如果 code 不是 200，说明业务逻辑失败了，比如"项目已下线不能支持"。Axios 响应拦截器里判断这个 code，非 200 就弹出统一错误提示，并 reject 掉这个 Promise。页面里就不用到处写重复的if (res.code !== 200) { ... }了。

第三，统一处理 401 未授权。如果遇到 401 响应，说明 token 过期或无效，这时需要清掉本地 token，并跳转到登录页。这个行为要在拦截器里全局做，而不是每个页面单独处理。

// request.js 拦截器核心逻辑 axios.interceptors.request.use(config => { const token = useUserStore().token if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) axios.interceptors.response.use( response => { const { code, message, data } = response.data if (code === 200) { // 跳过二进制流等特殊情况 return data } else if (code === 401) { useUserStore().clearToken() router.push('/login') return Promise.reject(new Error(message)) } else { ElMessage.error(message) return Promise.reject(new Error(message)) } }, error => { // 处理网络错误 ElMessage.error('网络异常，请稍后重试') return Promise.reject(error) } )

这套封装方式我认为是教学级项目里比较标准的做法，照着写不会有问题。

4.4 声明式路由守卫与页面权限控制

前端路由守卫是实现权限控制的重要一环。在 Vue Router 4 中，可以通过全局前置守卫beforeEach来控制哪些页面需要登录、哪些页面需要管理员权限。

核心思路：

• 定义路由时在 meta 字段里声明requiresAuth和requiresAdmin。
• 在守卫里读取目标路由的 meta，判断当前用户是否登录、是否是管理员。
• 未登录跳登录页，已登录但没权限跳 403 页面。

router.beforeEach((to, from, next) => { const userStore = useUserStore() if (to.meta.requiresAuth && !userStore.isLoggedIn) { next({ path: '/login', query: { redirect: to.fullPath } }) return } if (to.meta.requiresAdmin && !userStore.isAdmin) { next({ path: '/403' }) return } next() })

需要注意的是，前端路由守卫只是用户体验层的控制，真正的权限校验必须要在后端完成。前端隐藏了入口并不能阻止恶意用户直接请求接口，后端拦截器里对每个需要权限的接口做校验才是根本保障。这也是我在跟学生评审代码时反复强调的一句话：前端做体验，后端做安全。

5. 前后端联调与部署实践经验

5.1 跨域问题的正确处理方式

前后端分离架构下，本地开发时前后端分别跑在不同端口（Vite 默认 5173，SpringBoot 默认 8080），必然产生跨域请求。

省事的解决方式是后端开启跨域支持：

@Configuration public class CorsConfig { @Bean public CorsFilter corsFilter() { UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource(); CorsConfiguration config = new CorsConfiguration(); config.addAllowedOriginPattern("*"); config.addAllowedHeader("*"); config.addAllowedMethod("*"); config.setAllowCredentials(true); source.registerCorsConfiguration("/**", config); return new CorsFilter(source); } }

但更推荐的做法是前端用 Vite 的代理功能。在vite.config.js里配置：

export default defineConfig({ server: { proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true } } } })

前端请求/api/project/list时代理到http://localhost:8080/api/project/list。这样做的好处是浏览器只向同源地址发起请求，不存在跨域问题，而且后续上线时，可以用 Nginx 做同样的路径转发，配置风格保持一致。

5.2 数据库初始化与数据迁移

后端项目的resources目录下一般会附带db/shanchou.sql数据库脚本文件，里面包含建表语句和初始数据。导入数据库时要注意执行顺序：先建库，再建表，最后插入初始数据。

强烈建议你在本地测试时往数据库里准备一批种子数据。一个众筹系统如果首页空空如也，看起来就跟失败了一样。种子数据至少要包含：

• 5 个以上的众筹项目，覆盖不同分类、不同进度状态
• 每个项目至少 2~3 个回报档位
• 若干条用户支付记录，让进度条看起来是真实有进度的
• 一个初始管理员账号，方便进入后台验证功能

很多教学项目的 db 脚本里都只给了一条 admin 数据，其他业务数据完全没有。这种情况下建议自己用 SQL 往库里插几十条测试数据，用 SQL 写个循环插数据，这种准备工作在排查 bug 时价值巨大。

5.3 生产环境部署方案

生产环境的部署，我推荐用这套最简单的组合：

• 前端：npm run build生成dist静态目录，扔给 Nginx。
• 后端：mvn package打成 jar 包，用java -jar运行，或者用 systemd 托管。
• 数据库：MySQL 8.x 独立运行。
• 反向代理：Nginx 将/api路径转发到后端服务。

Nginx 配置核心片段：

server { listen 80; server_name your-domain.com; # 前端静态资源 root /opt/shanchou/dist; index index.html; location / { try_files $uri $uri/ /index.html; } # 后端 API location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

这里要注意location /里必须写try_files $uri $uri/ /index.html;，这个配置的作用是解决 Vue Router 的 history 模式下，刷新页面时 404 的问题。如果你用了createWebHistory而没配上这个，那刷新任何二级路由页面都会白屏，这是新手部署时最容易遇到的坑。

5.4 文件上传方案的对比

众筹项目需要用户上传图片，比如项目封面、回报物图片、个人头像。这套系统里文件上传是直接存到本地磁盘的——后端接收 MultipartFile，保存到服务器某个目录，然后返回访问 URL。

如果是教学级项目，本地存储完全够用。但你要搞清楚这种方案的两个隐患：

第一，重启丢文件。如果后端打成 jar 包运行，上传到 jar 包同级目录的文件不会丢；但如果用 IDE 直接跑，文件可能被存在 IDE 的工作目录，换个环境就找不到了。建议在配置里使用绝对路径，不要用相对路径。

第二，扩容困难。应用服务器的磁盘空间有限，图片一多就容易写满。真实项目中一般用云对象存储或第三方存储。不过对于教学系统，本地存储优势是简单直观，便于理解文件上传的完整流程。

6. 常见问题排查与技术避坑实录

6.1 后端启动失败排查速查表

很多读者在拿到源码后第一步就卡住了，后端项目启动不起来。这里把最常见的情况整理成表格：

6.2 前端常见疑难问题

前端跑起来后，比较常见的坑：

npm install 失败。这种情况大概率是网络问题或依赖版本冲突。建议直接删除node_modules和package-lock.json，重新执行安装。

接口 404。这大概率不是后端代码问题，而是 Vite 代理路径配置不对。检查前端请求的 URL 路径和代理的 target 拼接后的最终地址，是否跟后端@RequestMapping的路径一致。这个排查要用浏览器的开发者工具，看网络请求的实际地址，别靠猜。

页面刷新白屏。这个基本就是路由模式问题。如果用了 history 模式，本地开发环境没问题，但部署到 Nginx 后刷新就404，就是 Nginx 没有配置try_files兜底，回到上文说的那个配置项做处理。

6.3 数据库层面的性能陷阱

众筹系统虽然并发量不算极高，但有一些性能问题会在数据量上来后暴露。

一个是列表页查询返回了过多字段。前端只需要 10 个字段，后端却把整张表所有字段全查出来了，尤其是description这种大文本字段，会占用大量传输带宽和内存。解决办法是 SQL 里明确列出所需字段，不要把TEXT类型字段默认包含进去。

另一个是列表页的统计查询没有用索引。比如按status过滤项目、按create_time排序，这些字段要记得加索引。加索引的 SQL 建议写进初始化脚本，别手动在数据库里操作，这样能保证不同环境下的一致性。

还有一个容易被忽略的问题：分页查询用LIMIT 1000000, 20这种写法。当页码很深时，MySQL 要扫描前一百万行数据再丢弃，性能极差。真实的优化方案是使用"延迟关联"或者基于游标的分页方式。对于教学项目，你只需要意识别写到这个深坑就够了，不需要真的去实现。

6.4 前后台同时访问时的 Session 与权限坑

这套系统在部署时，如果前台和后台跑的是同一个域名下的不同路径（比如https://example.com/和https://example.com/admin），并配了不同的 Nginx 规则，要特别注意 cookie 的SameSite属性和跨域的CORS配置是否协调。否则前台登录成功了，后台却拿不到用户态，会莫名出现各管各的假象。

我在实际项目里还遇到过一个问题：后台管理的上传接口因为文件太大，超过 Nginx 默认的client_max_body_size（通常是 1MB），导致上传总是报错。排查方法也简单，去看 Nginx 的 error.log，如果发现client intended to send too large body，在 server 块里加一句client_max_body_size 20m;就完事了。

6.5 几个容易让代码出 bug 的细节

写这套系统的时候，有几个细节值得单独拎出来强调：

第一，MyBatis Mapper 接口的 XML 文件路径和 namespace 必须完全匹配。如果 Mapper 接口在com.shanchou.mapper.ProjectMapper，那 XML 文件里的<mapper namespace="com.shanchou.mapper.ProjectMapper">必须一致，否则 MyBatis 启动时会直接报错。

第二，前端传日期字符串时，格式要保持一致。前端默认是2025-06-01 12:00:00这种格式，后端的 LocalDateTime 一般也能自动转化，但如果前端用了 ISO 标准格式2025-06-01T12:00:00，后端的 JsonFormat 注解又没配置，就会解析失败。解决办法是全局配置一个 Jackson 的日期格式化规则。

第三，零金额订单要拦截。众筹平台不允许用户输入 0 元或者负数金额，这要在后端接口的参数校验里做掉。否则恶意用户构造一个负金额的请求，项目金额反而会越来越少，破坏系统完整性。

7. 这个项目还能怎么扩展

如果不想停留在课程设计级别，动手给这个众筹系统加几个扩展方向，会让自己对整套技术栈的理解上一个台阶。

扩展一：引入 Redis 做缓存与计数器。把项目的点赞数、关注数、部分热点数据的访问用 Redis 缓存，同时利用 Redis 的INCR原子操作来维护计数，能够大幅降低数据库的写入压力。实战中也能学到一个系统从"纯数据库扛压"到"Redis 缓冲"的演进过程。

扩展二：对接真实的支付网关。虽然教材项目一般用模拟支付，但如果你愿意接触微信支付或支付宝的沙箱环境，把下单到支付的闭环补完整，会理解"回调验签""幂等处理""订单超时关闭"这些真实世界的玩法。这部分难度不小，但也是简历上可以写出来的亮点。

扩展三：引入消息队列。当用户下单后，系统需要发送通知（站内信 + 邮件或者短信），这时可以在下单成功事件上接一个消息队列，把通知发送异步化。可以选用 RocketMQ 或 RabbitMQ，从"同步拖慢主流程"到"异步解耦"的体验变化非常直观。

扩展四：管理后台加入数据可视化。用 ECharts 展示平台的核心指标：每日众筹金额趋势图、众筹分类占比饼图、项目成功率统计、用户增长曲线等。这些图表接口大多是SELECT SUM/COUNT/GROUP BY的 SQL，前端渲染用 ECharts 的现成组件，做起来不复杂，但整个系统的价值感会提升一大截。

说实话，如果在原有这套代码上做了 Redis 缓存 + 数据可视化这两个方向的扩展，并真正跑通前后台联调，一个月的时间就能让一个课程设计级别的项目成长到一个可以直接写在简历上的"个人项目"。我在带团队的时候筛选简历，最在意的不是项目平台有多大，而是候选人对"项目里某个模块为什么这么做、资源冲突怎么解决、并发场景怎么兜底"有没有自己的理解——这套众筹系统恰恰能成为训练这种理解能力的完整载体。

最后再分享一个我在实战中反复验证的经验：拿到任何一套前后端分离的源码，第一件事不是急着跑起来，而是先把数据库脚本看一遍。把所有表的关系理清楚，结合项目标题理解每张表的业务定位，再看后端代码时就会有一条清晰的主线。只要这一步做到位，剩下的项目启动、功能调试、二次开发都会顺畅很多。反过来，如果一上来就埋头跑代码，十有八九会在联调阶段被各种诡异的 bug 耗到怀疑人生。