第 3 章：整体架构设计
“架构设计不是为了炫技，而是为了让代码在一年后还能被看懂。”
在深入具体的代码实现之前，我们需要对系统的整体骨架有一个清晰的认识。本章将带你领略前后端分离的云开发架构之美。
3.1 前后端分离的云开发架构
传统的前后端分离通常是：前端(Vue/React) <--> HTTP API <--> 后端服务器(Java/Go/Node) <--> 数据库。
而在 Serverless 云开发 架构下，我们的链路变得更短、更轻：
graph LR
Client[小程序端UniApp] -->|Cloud SDK| Gateway[云函数网关]
Gateway --> Function[云函数 Node.js]
Function --> DB[(云数据库 MySQL)]
Function --> Storage[云存储 COS]
核心优势：
- 免鉴权调用：小程序端调用云函数时，微信会自动注入用户信息（OpenID），无需手动维护复杂的 Session 或 Token。
- 弹性伸缩：活动报名高峰期，云函数自动扩容，不用担心服务器崩塌。
- 稳定可靠：MySQL 作为老牌关系型数据库，在处理复杂的报名事务、投票统计时，比 NoSQL 更让我们放心。
3.2 模块划分策略
一个好的目录结构就是最好的文档。我们采用了“按业务领域”划分的策略。
3.2.1 前端模块 (src/)
我们没有把所有页面都堆在 pages 里，而是按功能域分组：
pages/activity: 活动的核心领地。list: 活动广场。detail: 活动详情（展示页）。form: 活动创建/编辑表单。poster: 海报生成页。
pages/registration: 报名相关。my-list: 我的报名记录。verify: 管理员扫码核销页。
components/ActivityDesign: (重难点) 可视化编辑器模块。widget: 基础组件库（文本、图片、按钮等）。property: 属性编辑面板。- 这是整个项目中复用度最高、逻辑最复杂的部分。
3.2.2 后端模块 (server/)
云函数采用了 微服务 的思想，每个文件夹代表一个独立的服务：
auth: 鉴权中心。负责登录换取 Token、刷新 Token、校验权限。user: 用户管理服务。负责用户信息的更新、查询。activity: 活动领域服务。处理活动的 CRUD、状态变更。它不直接处理报名逻辑，保持单一职责。registration: 报名领域服务。处理提交报名、审核报名、支付凭证校验。vote: 投票领域服务。处理投票动作、实时统计、并发控制。barrage: 弹幕服务。负责弹幕的发送、拉取，甚至未来的审核。wechat: 微信集成服务。处理 AccessToken 获取、小程序码生成等与微信服务器的“外交”事务。
3.3 数据流转全景图
让我们通过一个“用户报名”的场景，看看数据是如何流转的：
- 触好 (UI): 用户在
ActivityDetail页面点击“立即报名”按钮。 - 表单 (Form): 前端根据后台配置的 JSON Schema 动态渲染出表单（姓名、电话、图片上传）。
- 上传 (Storage): 用户上传支付截图，前端调用
uniCloud.uploadFile将图片存入云存储，获得fileID。 - 请求 (Request): 前端调用云函数
registration/submit，携带表单数据和fileID。 - 逻辑 (Logic):
- 云函数接收请求，校验用户是否已登录。
- 检查活动状态（是否过期、名额是否已满）。
- 向 MySQL 数据库
registrations表插入一条记录，状态为pending(待审核)。
- 响应 (Response): 返回成功消息，前端跳转到“报名成功待审核”页面。
3.4 技术栈深度解析
为什么选择 UniApp？
- Vue 3: 组合式 API (
setup语法糖) 让逻辑复用变得极其简单，特别是在处理复杂的编辑器逻辑时，Hooks 模式（如useDraggable）大显身手。 - TypeScript: 我们的数据结构（如活动配置 JSON）非常复杂，TS 的类型定义能帮我们规避 90% 的
undefined报错。
为什么选择 MySQL？
- 事务支持: 报名扣库存、投票防刷，这些涉及到数据一致性的操作，MySQL 的事务机制是最佳保障。
- JSON 支持: 虽然是关系型数据库，但 MySQL 5.7+ 对 JSON 类型支持极好。我们可以把复杂的活动配置 (
config) 存为 JSON 字段，既享受了 SQL 的严谨，又有了 NoSQL 的灵活。
本章小结： 我们确立了 UniApp + CloudBase + MySQL 的铁三角组合。虽然架构图看起来很简单，但魔鬼都在细节里。下一章，我们将深入数据的灵魂——设计那个既严谨又灵活的数据库模型。
