1. 众筹平台的核心业务拆解：先搞清楚要做什么，再谈技术选型
说实话，最初接触这个项目需求的时候，我并没有直接动手拉代码框架，而是先花了两天时间把"众筹"这个业务场景拆了一遍。善筹网这类平台表面上看是"发起项目、用户捐款"的简单逻辑，但真正落地的细节非常多：用户分角色、项目有审核、筹款有上限、订单要闭环、后台要有统计。只要有一个环节没想清楚，后面写代码就会反复推翻重来。
拆完之后，其实核心就是三件事：项目生命周期管理、订单支付闭环、前后台权限体系。听起来不复杂，但每一条往下展开，都会牵扯出不少子问题。
先说角色。善筹网的用户体系不能只做一套"注册登录"，要区分普通用户、项目发起人、平台管理员。普通用户能做的是浏览项目、收藏、下单支持；发起人除了能浏览下单，还能发起众筹项目、管理自己的项目、查看筹款明细、发起提现申请；管理员则要处理项目审核、分类管理、用户管理、平台数据总览。这三类角色的功能边界一旦在需求阶段画清楚了，后端接口设计和前端页面划分就都有了依据。
再看项目生命周期。一个众筹项目从发起人提交开始，要经历草稿、待审核、审核通过（筹款中）、筹款成功、筹款失败、已关闭这几个状态。每次状态变更背后都对应着具体的业务操作：审核通过后项目才能在前台展示；筹款到期后系统要自动判断是否达到目标金额，达到则进入成功状态，未达到则需要触发退款逻辑；项目上线后如果有违规内容，管理员还要能强制关闭。这块的状态机设计，就是整个后台管理系统最核心的逻辑骨架。
最后是订单闭环。用户给某个项目捐款，不是简单往数据库里插一条记录就完事了，要经历创建订单、生成支付参数、用户付款、支付回调、更新订单状态、同步项目已经筹到多少钱这一整条链路。中间任何一步网络超时、回调重复、订单状态覆盖，都可能造成"钱收了但项目进度没更新"这种严重问题。所以支付这块，必须在设计阶段就把幂等处理、对账机制考虑进去。
理清这些业务之后，技术选型就顺理成章了：前端用Vue3，因为它对组件化、状态管理的支持成熟，配合Vite开发调试效率高；后端用SpringBoot，生态完善、开发效率高，和MyBatis配合做灵活的数据查询非常顺手；数据库用MySQL，业务数据是典型的关系型结构，事务要求高；前后端走RESTful API，用JWT做无状态认证，天然适配前后端分离架构。
2. 数据库建模：项目、订单、用户三条主线的状态流转设计
业务梳理清楚了，接下来的第一步不是写接口，而是建表。数据库设计一旦不合理，后期改起来就是牵一发而动全身。我把善筹网的核心表拆成三条主线：用户主线、项目主线、订单主线，外加若干辅助表。
2.1 用户表和角色权限的实现方式
用户表我保留了常规字段：id、用户名、密码（BCrypt加密）、手机号、邮箱、头像、身份证号（发起人实名认证用）、创建时间、最后登录时间。这里注意，不要用明文密码，哪怕项目不打算上线也要养成习惯——我曾经见过项目demo里直接存明文密码的，后面接真实支付了才发现安全隐患极大。
角色与权限这块，善筹网没有引入Spring Security的完整权限体系，因为开发成本略高。做一个用户角色关联表，存user_id和role_id，再用一个简单的拦截器在Controller层做角色校验就够用了。
2.2 项目表的设计与状态流转字段
项目主表我设计了这么几个关键字段：项目编号、项目名称、封面图、分类id、发起人id、目标金额、已筹金额、支持人数、项目简介、项目详情（富文本）、开始时间、结束时间、状态、审核备注。这里需要特别说明两个地方：
已筹金额字段要不要冗余存储？一开始我的做法是每次查询都SUM订单表里的金额，后来发现项目列表页、详情页、后台统计到处都要用这个值，实时计算非常伤数据库。最终方案是在项目表里冗余一个currently_amount字段，每次支付成功回调时累加更新。为了保证这个字段的准确性，所有更新操作都放在同一个事务里，并且用乐观锁（版本号）防止并发写覆盖。
状态字段用什么类型？我用的int型，0草稿、1待审核、2筹款中、3已成功、4已失败、5已关闭。状态枚举固定写在后端静态常量里，不要散落在业务代码各处。后续凡是涉及状态切换的逻辑，我统一封装在服务层方法里，避免Controller里到处改状态。
除了主表，项目侧还需要几张辅助表：项目图片表（一个项目可有多张图）、项目分类表、项目支持记录表。其中支持记录表其实就是订单表的只读视图接口，不一定单独建表，查询的时候关联订单和项目即可。
2.3 订单表与支付流水表
订单表是所有表里我花时间最多的。字段包括：订单号、用户id、项目id、项目名称快照、支持档位、金额、实际支付金额、支付渠道、交易流水号、支付状态、创建时间、支付时间、订单关闭时间。这里有两个设计细节值得展开：
一是为什么要存项目名称快照。如果以后项目改名，订单记录仍然能还原当时的场景，这个对统计对账很关键。数据冗余设计要适度，像这种"历史档案"性质的表保留快照是行业普遍做法。
二是支持档位怎么设计。很多众筹平台提供不同金额档位，比如 50元档、100元档、500元档，每个档位有不同的回报。我把档位设计成了独立的项目档位表，用户下单时展示档位信息，订单表记录用户实际选择的档位id。这样项目发起人配置档位、用户选择参与、后台统计档位分布都有据可查。
支付流水表记录的是每一笔真实资金流转，包括请求支付的原始参数、支付回调的原始报文、本地处理结果。这个表最大的作用是排错，用户反馈"我付款了怎么没到账"，查流水表一眼就能定位问题出在支付回调、通知解析还是数据库更新阶段。
3. SpringBoot + MyBatis 后端核心模块的实现思路
3.1 基于注解的接口开发模式与统一响应体
后端结构我采用的是经典的三层架构：Controller 层负责参数接收和响应、Service 层负责业务处理、Mapper 层负责数据访问。善筹网的接口返回值我统一封装成了R对象，包含code、message、data三个字段，前端axios拦截器统一处理code非200的情况，避免每个页面写一遍错误提示逻辑。
代码层面有一个强烈建议：用接口 + 实现类的结构来组织Service。很多人觉得项目小没必要这么抽象，但善筹网前后期功能一直在增补，比如新增一个"项目推荐置顶"功能，如果Service没有面向接口编程，改动面就会非常不可控。
Controller接口的分组也很重要，凡是管理员角色才能调的接口统一放到 /admin/ 路径下，凡是发起人特有的操作放到 /sponsor/ 路径下，前台浏览接口放在 /api/ 下。路径规范在项目初期就要定好，前后端联调阶段效率会高很多。
3.2 权限校验：拦截器 + JWT token 的方案为什么够用
善筹网登录认证采用的方案是JWT（JSON Web Token）+ 自定义拦截器。用户登录成功后，后端生成一个有效期为7天的token返回给前端，前端每次请求在Header里带上Authorization字段，后端拦截器解析并校验token合法性，然后放行。
为什么不用Spring Security + OAuth2这种重型方案？因为善筹网是自有的单一后端服务，不涉及第三方服务授权。JWT自包含用户id和角色信息，无状态、易扩展，配合拦截器完全够用。
这里有一个实现细节需要特别注意：拦截器解析token后，需要把用户信息塞到ThreadLocal或者Request attribute里，方便后续的Service层直接获取当前操作人。如果每层都传一个userId参数，代码会非常啰嗦且容易漏掉角色校验。
角色校验我是在拦截器里通过token解析出的角色做的。管理员接口路径统一走一个AdminInterceptor，校验规则是当前用户角色必须为1；发起人接口路径校验角色必须为1或2。一旦校验失败，直接返回统一错误码，前端收到后跳转到对应提示页。
3.3 众筹项目的审核与状态切换逻辑
项目审核是后台管理的重点功能之一。发起人提交项目后，项目状态变为待审核，管理员在后台列表看到新项目，点开详情查看项目资料、目标金额、图片信息，审核通过或驳回。这个流程逻辑不复杂，但是有一个我一开始没考虑周到、后来踩了坑的点：驳回操作一定要填写审核意见，并且要把意见反馈给发起人。
我的实现方式是审核表中记录审核人、审核时间、审核状态、审核意见，项目表只存最终状态。发起端查询项目状态时联表查出最近一条审核记录，把审核意见展示给发起人。一些平台网站在生成时也会包含这些核心字段，方法各不相同，但作用都类似：通过一个标准化的接口，让前端发起和后台审核都访问同一套模块处理流程，数据就非常一致。
状态切换方面，我统一封装了一个changeProjectStatus方法，内部做了前置状态校验、状态变更记录、业务后续处理三个步骤。以"筹款中 -> 筹款成功"为例，前置校验要求当前状态必须为筹款中且当前时间在结束时间之后，业务后续处理是关闭相关的支付入口、更新项目页面横幅为"已成功"。状态机的每一步都走这个统一方法，杜绝了在多个Controller里直接改状态字段导致的状态错乱。
3.4 订单生成与支付回调的幂等处理
用户下单支持的流程是这样的：前端创建订单 -> 后端插入订单记录（状态为待支付）-> 返回订单号给前端 -> 前端调起支付组件 -> 用户支付成功 -> 平台支付回调通知后端 -> 后端更新订单状态并累加项目的当前筹款金额。
这一段流程里最容易出错的是回调处理。因为平台支付系统通常情况下为了保证送达会多次回调同一笔订单，如果后端不做幂等处理，就会造成订单金额反复累加、项目筹款金额虚高。
幂等处理我的做法是：在支付回调处理的入口，利用订单表的订单号做唯一约束。回调逻辑先判断订单状态，如果已经处理过（状态为已支付），直接返回成功给支付平台，不再走重复的业务逻辑。同时，订单状态更新和项目金额累加放在同一个事务当中，任何一步失败整体回滚。这个"先查状态、再更新、事务包裹"的处理方式，非常适合高可靠资金链路。
还有一个细节是支付结果异步通知的验签。回调数据一定要验签，我遇到过本地调试时直接信任公网回调数据导致伪造订单的情况——以前开放平台回调接口时吃了大亏。善筹网开发时要严格按支付渠道的文档要求，对回调参数做签名校验，验签失败直接拒绝并记录异常日志。
4. Vue3 前端实战：从堡垒页面到完整交互链路
说实话，善筹网这种前后端分离的项目，前端的工作量不比后端小。我用Vite搭建的Vue3项目，采用了Composition API + script setup语法，配合Element Plus组件库和后端管理后台的UI框架，整体开发效率比传统Vue2要高不少。这一节重点讲我实现过程中的关键链路。
4.1 项目页面的拆分与路由设计
前端路由我用Vue Router做了按角色划分。前台路由包括首页、项目列表、项目详情、登录注册、个人中心；发起人相关页面放在发起人路由组下，包括发起项目、我发起的项目、审核状态查看；后台管理路由采用独立布局，包含项目审核、分类管理、用户管理、数据统计。
路由守卫这里有一个细节：不能只在前端做权限控制，后端接口照样要校验权限——这一点很多新手容易忽略。前端路由守卫的核心是用户体验层面的控制（没有权限的页面连进都不让你进），后端接口校验才是安全底线。我的实现是路由meta里定义requiresAuth、roles数组，beforeEach全局守卫里判断token是否存在以及角色是否符合路由要求，不满足则跳转到登录页或401页。
4.2 axios封装与token失效处理
axios封装看起来简单，但踩过的坑不少。我的做法是创建一个request实例，在请求拦截器里从localStorage读取token并注入到Authorization头。响应拦截器做两件事：当响应code为401（未登录或token过期）时，清除本地token，跳转到登录页，并且用Element Plus的Message提示"登录已过期，请重新登录"。
这里有一个很容易被忽略的点：并发请求下的401处理。如果多个接口同时返回401，就会触发多次跳转，而且本地状态清理可能被后返回的响应覆盖掉，导致前端状态管理混乱。解决方案是设置一个isRefreshing的全局标记，第一个401请求负责跳转，后续的401请求直接return，不要再重复跳转。这个小问题不解决，长期使用系统时用户经常会遇到"明明点了登录，却跳到奇怪页面"的体验。
4.3 项目发起的富文本编辑与图片上传
善筹网的项目详情支持富文本内容，且项目中会使用大量图片，所以前端要配置好阿里云OSS或本地存储文件上传的功能。我用的是Element Plus的Upload组件配合后端的上传接口，上传成功后将返回的URL塞到富文本编辑器内容里。
这部分的处理有个经验值得分享：图片上传后不能立刻把完整URL拼进富文本，而是要存一个相对路径或者URL占位符，最终提交时再统一做完整URL拼接。因为开发环境域名和线上域名是不一样的，存全路径会导致以后换域名时数据库里一堆废链接。善筹网项目中我把上传的图片文件路径存为相对地址如 /upload/2023/xxx.jpg，展示时才用全局配置的访问域名拼接，这个设计到线上部署时省了很多麻烦。
4.4 筹款进度展示与订单支付流程
前台最核心的交互是项目详情页：展示项目封面、已筹金额、目标金额、支持人数、剩余天数，同时渲染一个进度条，并且列出档位卡片使用户点击后进入支付环节。
进度条的实现不要用精确到小数点的百分比，而是向下取整，比如 63.4% 显示 63%，这样用户不会觉得数字跳动频繁。支持档位的选中状态我用ref维护，当前选中的档位高亮，点击"立即支持"后把档位id和项目id传给后端创建订单接口，然后跳转到订单确认信息展示，再唤起支付。
支付唤起是这个项目里交互比较复杂的部分。由于是模拟众筹平台，没有直接接真实支付网关，我用的是自定义支付参数加二维码模拟的方式：前端跳转到扫码收银页面，显示一个二维码和订单倒计时，然后每隔3秒轮询一次后端订单状态接口。支付成功后轮询接口返回已支付，前端自动跳转到"支持成功"页面。这种方案没有真实支付，但完整呈现了用户流程，对演示和教学来说足够了。如果后续要接真实支付，核心流程也基本类似，只需要替换前端唤起真实支付的方式即可。
5. 前后端联调与部署：最容易翻车的几个环节
代码写完只是第一步，联调和部署才是真正考验耐心的地方。这一节我把善筹网开发中真实遇到过的几个问题和最终的解决方案直接列出来，希望能帮后来者少走弯路。
5.1 MyBatis动态SQL里隐藏的0值陷阱
项目检索功能里有一个经典坑：查询项目时如果前端传了分类id=0表示"全部分类"，在MyBatis的XML文件里写SQL时用 where categoryId = #{categoryId}，这种情况不会出问题；但如果用 ，那么categoryId=0的时候，条件会意外不生效，导致结果集为空。
排查这个问题的思路是：在XML里输出打印实际执行的SQL，发现0被当成了空字符串处理。解决办法有两种：一是统一约定分类id从1开始，0表示全部；二是把判断条件改成 。最后项目里我统一采用的是第二种写法，不管传0还是负面值，只要存在就参与条件拼接，由业务层决定特殊值含义。像这样的诡异问题稍微不留神，前端传0的时候就全表查不出来。类问题在生产环境遇到过好几次了，MyBatis动态SQL的判断语句要格外注意。
5.2 跨域配置：开发环境与生产环境的区别
前后端分离模式下，前端运行在8080端口，后端运行在8081端口，开发环境必然存在跨域问题。我在后端写了一个全局CORS配置类，允许的源用allowedOriginPatterns，并加上allowCredentials(true)。注意allowedOrigins在某种情况下不支持通配符，踩过坑后建议直接用allowedOriginPatterns。
但是生产环境建议不要依赖后端CORS配置来解决跨域问题。前端部署在Nginx下，Nginx配置 proxy_pass 将 /api 路径反向代理到后端服务地址。这样浏览器访问的是同域下的 /api 路径，根本不产生跨域请求。这个部署方案比后端放开CORS更安全，也减少了CORS配置出错的风险。如果照抄我解决开发环境跨域的方法直接上生产环境，时间长了会发现Cookie和Authorization头被拦得很麻烦。
5.3 上线后的几点加固措施
项目部署到服务器后，我做了几个安全加固和性能优化，这些虽然不是必要条件，但对最终项目的质量影响很大。
第一是接口限流。善筹网的浏览接口和支付接口被人高频调用会对服务器产生压力。我用最简单的方式实现了一个基于IP的限流拦截器，配合Redis做计数器，单位时间内超过阈值的请求直接返回"操作过于频繁"。
第二是静态资源缓存。前端打包后的静态文件都带hash指纹，Nginx配置了img、css、js的缓存策略，刷新页面反复加载的速度会有质的提升。配合前端的路由懒加载，首屏加载质量从秒级降到百毫秒级。
第三是数据库连接池的合理配置。默认的HikariCP连接池在没有配置时候最大连接数是10，并发稍微一大就能把连接池打满。我在application.yml里调整了maximum-pool-size到30，并且配置了连接池最大等待时间，避免业务高峰期线程全部阻塞在获取连接上。
6. 一些写完整套系统后的个人体会
善筹网这个项目从需求分析到跑通完整流程，再到部署上线，整个开发周期大约十天左右。过程已经不算短，但总结下来，真正花时间的地方往往不是写代码本身，而是设计决策：订单状态机怎么定义、项目状态怎么流转、支付回调怎么做到幂等、前端路由怎么配合权限、部署用哪种方案。每一个决策如果在前期没有想清楚，后期都要付出数倍的时间来改。
如果你也想拿类似的众筹平台项目练手，我的建议是别急着写业务代码。先花一两天把项目角色、状态流转、字段含义完全想明白，画好流程图和表结构关系，再开始动手。这个准备工作并不会拖慢进度，反而会让后期开发轻松得多。
最后再分享一个小技巧：多看看真实平台的数据结构和工作方式，比如一些公益平台的详情页信息架构、状态展示方式、用户交互链路，然后思考如果你来实现这些功能，你的表结构和接口设计会怎么调整。带着问题去看别人的系统和设计自己的系统，吸收的知识点会牢固很多。希望这篇记录对你做类似项目有所帮助。
