企业官网建设流程全解析

半年前接了一个公益服务平台的项目需求，当时第一反应就是：这活儿必须用前后端分离来做。后端采用Java SpringBoot，前端选择Vue3，持久层交给MyBatis配MySQL数据库，这套组合在社区里已经被验证过太多次，稳定性和开发效率都能兼顾。项目源码最终也整理成了可复用的模板，覆盖公益活动发布、志愿者报名、爱心捐赠、进度公示这些核心场景，对想学习前后端分离实战、或者打算做同类公益系统的人来说，都是可以直接参考的素材。

这篇内容我会把整个项目的落地方案拆开讲清楚——从需求拆解、数据库表设计、后端接口实现、前端页面组织，到联调阶段踩过的具体坑，再到最后打包部署上线，每一步都尽量还原当时实际操作时的思路和依据。比起单纯贴代码，我更想把"为什么这样做"讲明白，这才是有价值的地方。

1. 从需求到架构：公益服务平台的模块拆解与技术栈取舍

1.1 这个平台到底需要哪些功能

公益服务平台和普通电商后台有个很大的区别：它的核心不是交易，而是"信息透明+流程参与"。接到需求时，甲方列了一堆功能点，归纳下来其实集中在五块：

• 公益活动管理：管理员发布活动（标题、详情、地点、时间、名额）、上下架、编辑；
• 志愿者/用户端：注册登录、浏览活动列表、活动详情、在线报名、取消报名；
• 爱心捐赠模块：捐赠记录登记、捐赠物品/金额明细展示，方便社会监督；
• 审核与状态流转：报名需要审核、活动有"筹备中/进行中/已结束"状态流转；
• 公示与统计：志愿者时长统计、活动参与人次图表、捐赠汇总。

这个范围听起来好像不复杂，但它有一个隐性要求：状态变化多、流程链条长。用户报名一个活动，后台要生成报名记录，活动表的名额要扣减，如果涉及审核还要多一条审核记录，最后活动结束后要回填参与时长。这些操作每一步都牵扯数据一致性，稍不注意就会把系统写成一堆if-else糊在一起的"面条代码"。

所以架构上我在第一步就确定了思路：按业务模块拆Controller-Service-Mapper三层，不搞复杂的微服务，一个SpringBoot单体应用承载全部后端能力，前端用Vue3单页应用对接。这种规模的项目上微服务就是给自己找麻烦，单体反而更容易维护和部署。

1.2 为什么选了SpringBoot+Vue3+MyBatis这套组合

技术选型的时候，我对比过几套方案，最后定下来是以下几方面的考虑。

后端SpringBoot基本没有悬念。它是目前Java生态里启动和集成成本最低的框架，内嵌Tomcat、自动配置、丰富的Starter生态，能让我把精力集中在业务代码上而不是折腾容器配置。对于公益平台这种管理后台+用户端混合的项目，SpringBoot的Spring Security/拦截器、事务管理、参数校验这些能力可以直接复用。

Vue3则是我对比了Vue2之后确定的。组合式API（Composition API）让业务逻辑的组织比Vue2的Options API清晰得多，一个报名流程相关的响应式变量、计算属性、方法可以聚合在同一个setup作用域里，不用像以前那样data、computed、methods分散在几个大块之间来回跳。加上