知食份子队——项目系统设计与数据库设计

这个作业属于哪个课程	2601_FZU_SE社区-CSDN社区云
这个作业要求在哪里	https://bbs.csdn.net/topics/620554714
这个作业的目标	完成项目概要设计、数据库设计；输出体系结构、模块层次、ER图、表结构、类图、权限安全设计；针对需求分析作业进行迭代改进；记录团队分工贡献；制定后续开发时间与人员分工计划，为答辩准备材料
其他参考文献	《构建之法（第三版）》、国标《系统设计说明书》、国标《数据库设计说明书》、UML类图相关教程、RBAC权限设计文档

🔗华为云团队仓库链接：https://codehub.devcloud.cn-north-4.huaweicloud.com/941777e6fed343219ac31bea3ee72293/dafu-shike.git

📎相关文档下载链接：

• 大福食刻-系统设计说明书.pdf
• 知食份子_数据库设计说明书.pdf
• 大福食刻-系统设计与数据库设计答辩.pdf

目录

一、系统和数据库设计

1.1 体系结构设计与功能模块层次图

设计思路：

1. 前后端分离：让多终端共享同一套业务规则。

• 项目约束：系统同时面向移动端师生和 /admin 管理端，并保留 H5 / 小程序 / App 的演进空间；业务规则集中到服务端，各端共用同一套判定口径。
• 设计选择：前台与管理端由同一套 Vue 3 + Vite 单页应用承载，uni-app 作为多端演进载体，后端提供统一 REST API。
• 作用：界面按终端适配，业务规则在服务端维护一次；新增终端时复用现有接口，前端专注于页面渲染与交互。

2. 单体分层：由部署资源和部署规模决定。

• 项目约束：部署目标为 2 核 2G 轻量服务器，采用 Docker Compose 六容器单机编排；单体部署与这一资源基线匹配，进程数量、通信链路和运维单元保持在可控范围。
• 设计选择：服务端保持单体部署，内部按 14 个业务服务模块划分代码边界。
• 作用：部署单元集中，资源占用可控；模块边界让多名成员可以按模块并行开发，减少对同一份代码的交叉修改。

3. 分层与单向依赖：按请求处理路径划分职责。

• 项目约束：鉴权、限流、参数校验、错误处理被 114 个 API 端点共用，点位、评价、推荐、AI、治理等业务规则各有特点；公共能力集中到接入层，业务规则集中到业务服务层，存储访问集中到数据访问层，可以让每层职责保持稳定。
• 设计选择：接入层统一处理跨域、四级鉴权、Redis 限流、参数校验、响应封装和 404 兜底；业务服务层执行项目规则；数据访问层封装 MySQL、Redis、MinIO 的访问差异；层间采用单向依赖，调用路径从接入层流向存储层。
• 作用：公共能力改一处即可覆盖全部接口，业务规则与存储实现可以分别演进，模块之间的调用路径清晰。

4. 外部服务侧接：按调用方和故障边界划分系统边界。

• 项目约束：高德地图由客户端直连，LLM 与校园身份认证由后端调用，抠图由后端通过容器内 HTTP 调用；这些能力由外部平台提供，接口与可用性属于外部责任。
• 设计选择：将地图、LLM、校园认证和抠图作为侧接依赖，由实际调用方适配接入，并在五层内部链路之外单独表达。
• 作用：系统边界清晰，故障责任落在对应调用模块；LLM 侧配置规则推荐回退，地图侧配置纯文本列表回退，抠图侧只影响贴纸提取，浏览、搜索、评价、打卡链路保持可用。

5. 功能模块分三大板块：按使用对象和复用关系归属。

• 项目约束：系统同时服务普通师生、平台管理员和点位维护员；认证、媒体、通知被多个板块共同使用。
• 设计选择：前台用户端 M1—M8 对应师生浏览、评价、收藏、AI 辅助、个人中心、饮食记录与内容共建等任务；管理端 M9—M12 对应审核治理、基础数据维护、用户授权、系统配置与运维；M13—M15 作为公共支撑，被多个板块共同调用。
• 作用：每项功能有明确归属，职责交叉少，公共能力维护一份。需要说明的是，15 个是功能模块（业务视角），后端 14 个是服务模块（代码视角），两者按职责映射。

6. 两张图分别表达结构与功能。

• 项目约束：体系结构和功能层次是两个视角，需要分别回答“系统由什么组成、如何协作”和“系统可以做什么”。
• 设计选择：体系结构图描述客户端、Nginx 入口、服务端各层、存储与侧接依赖；功能模块层次图以“大福食刻系统”为根节点，展开三大板块和 15 个模块。
• 作用：前者支撑部署形态与请求链路说明，后者支撑业务范围和模块归属说明，两图共同界定系统边界。

1.1.1 逻辑分层架构（五层 + 侧接外部依赖）

系统逻辑上划分为客户端层、接入层、业务服务层、数据访问层、数据存储层五层，层间采用单向依赖，调用路径从接入层流向数据存储层；高德地图、LLM、校园身份认证、抠图服务等外部能力以“侧接”方式接入，在五层内部链路之外单独表达。

图 2-1　总体架构图（分层）

1. 客户端层

• 组成：Vue 3 + Vite 单页应用，同时承载前台用户端页面与 /admin 管理端页面（含移动端自适应）；uni-app 多端工程作为 H5 / 小程序 / App 的多端演进载体。
• 职责：页面渲染、交互、路由与登录 / 管理员守卫、状态管理；业务判断以接口返回为准，前端负责呈现结果。
• 关键技术：Vue 3、Vite、Pinia、Vue Router、Element Plus、ECharts；高德地图由客户端直连 JS SDK。

2. 接入层（路由层）

• 组成：Express 路由表，共 114 个 API 端点，其中 /admin 子路由 44 个；鉴权、限流、参数校验、统一错误捕获等中间件。
• 职责：跨域与 JSON 解析、四级鉴权拦截（auth_optional / auth_required / write_required / admin_required）、业务键限流、统一参数校验、统一响应封装、404 兜底。
• 关键技术：Express 中间件管线、JWT 无状态令牌、Redis 固定窗口计数。令牌只承载用户身份，角色与账号状态每请求实时查库，权限回收即时生效。

3. 业务服务层

• 组成：14 个业务服务模块——内容聚合、评价、评分维度、AI 助手、媒体上传、用户数据、通知、推送、贴纸、手账、机审、榜单聚合、后台治理、档口负责人。
• 职责：承载全部核心业务规则，包括机审三级分流、评分与榜单聚合、AI 提问解析与降级、打卡联动手账 / 足迹 / 成就、审核治理与通知生成等。
• 关键技术：服务模块之间允许显式依赖；SQL 禁止写在本层，只能交给数据访问层；AI 按供应商注册表与协议类型分发。

4. 数据访问层

• 组成：MySQL 连接池、Redis 客户端（含降级包装）、MinIO 对象存储客户端。
• 职责：屏蔽 MySQL、Redis、MinIO 的访问细节；参数化 SQL 防止注入；事务保证多表写入一致性；DECIMAL 以数值形式返回，时区统一为 +08:00。
• 关键技术：mysql2 连接池与手写参数化 SQL（参数化直连，SQL 由数据访问层统一维护）、ioredis、MinIO SDK；Redis 异常时返回兜底值，主业务继续可用。

5. 数据存储层

• 组成：MySQL 8（utf8mb4，时区 +08:00）、Redis 7、MinIO 私有桶 dafu-images。
• 职责：MySQL 持久化 78 张业务数据表，事务保证写一致性；Redis 承担限流计数、图形验证码与 dHash 图片判重池；MinIO 存储评价图片、头像、贴纸与手账背景等文件对象。
• 关键技术：数据库事务、固定窗口计数、私有桶 + 后端 / Nginx 代理访问。

6. 侧接外部依赖

• 高德地图 JS API 2.0：客户端直连，提供矢量底图与自定义标记，坐标统一使用 GCJ-02 火星坐标系，由客户端直接发起请求。
• LLM 大模型供应商：后端调用，支持 OpenAI 兼容协议与 Anthropic 原生协议，按供应商注册表配置化分发；提示词仅注入平台真实数据，调用失败自动降级为规则推荐。
• 校园身份认证：真实环境走 CAS-SSO（302 跳转 → ticket 回调 → 服务端校验）；当前以模拟校园身份认证用于演示，认证服务与业务逻辑解耦，后续替换认证实现时前端流程保持不变。
• matting 抠图服务：后端通过容器内 HTTP 调用，将图片转换为透明底 PNG 贴纸；服务不可用时贴纸提取降级，主链路保持可用。

1.1.2 物理部署架构（Docker Compose 六容器）

系统以 Docker Compose 单机编排六个容器，整体可承载于 2 核 2G 轻量服务器。

图 2-2　部署架构图

容器	技术 / 镜像	端口	职责
frontend	Nginx（静态托管 + 反向代理）	宿主 8095 → 容器 80	对外唯一入口；托管前端静态资源，转发 /api/ 与 /img/
backend	Node.js + Express	3000（仅内部调试映射，生产部署关闭）	承载接入层、业务服务层与数据访问层
mysql	MySQL 8	3306（仅容器网络内）	业务数据持久化，首次启动执行库表初始化脚本
redis	Redis 7	6379（仅容器网络内）	限流计数、图形验证码、dHash 判重池
minio	MinIO（私有桶 dafu-images）	9000（仅容器网络内）	评价图片、贴纸、手账背景等对象存储
matting	rembg / U2Net 抠图服务	容器内 HTTP，仅后端调用	图片换透明底 PNG，重计算与主服务隔离

• 对外入口与反向代理：外部请求统一到达 frontend 容器的 Nginx（宿主端口 8095 → 容器 80），/api/* 转发至 backend，/img/* 转发至 MinIO 对象存储桶；HTTPS 在入口层终结，域名与证书由部署环境配置。静态资源按内容哈希长期缓存（1 年），入口页与前端路由兜底页不缓存。
• 启动顺序：mysql、redis、minio、matting 四个基础容器健康检查全部通过后，才启动 backend；backend 就绪后再启动 frontend，消除启动竞态。
• 健康检查：mysql / redis / minio 间隔 5s、重试 20 次；matting 间隔 10s、重试 30 次、启动宽限 15s。
• 重启策略：六个容器全部配置异常退出自动重启。
• 硬件基线：2 核 2G 轻量服务器，单机部署，以单机单实例运行。
• 数据卷与配置：mysql-data、minio-data 持久化数据；数据库、Redis、MinIO 连接串、令牌签名密钥、AI 密钥、校园认证参数全部通过环境变量注入，代码仓库只保留模板变量；调试开关默认关闭。
• 外部服务：高德地图、LLM 供应商、校园身份认证位于容器编排之外，由客户端或后端适配模块调用。

1.1.3 功能模块层次（三大板块、15 个模块）

图 2-3　功能模块层次图（H 图）

系统功能按使用对象分为前台用户端、管理端、公共支撑三大板块，共 15 个模块。下表补充每个模块的职责与代表端点。

板块	模块	主要职责	代表端点
前台用户端	M1 点位浏览	食堂、永嘉天地、学生街、周边与外卖分类浏览；食区—档口—菜品三级内容、食堂档口导览图、分类字典；卡片展示名称、分类、综合评分、价格区间、代表标签与营业状态	GET /canteens、/points、/points/map、/stations/:id、/dishes(/:id)、/categories
前台用户端	M2 搜索与推荐	关键词检索（菜品 / 档口 / 点位分组返回）与筛选排序、榜单、首页个性化推荐（含推荐理由与数据不足兜底）、横向对比（2—4 个同类对象）、评分维度字典	GET /search、/rankings、/recommendations、/dimensions
前台用户端	M3 评价与社区内容	短评价发布 / 修改 / 删除、有用投票与点赞、申诉、档口负责人回复、机审分流提示；社区长帖（图文、关联多个点位或菜品、评论、分享）	/reviews（POST / PUT / DELETE）、/reviews/:id/vote、/like、/appeal、/reply
前台用户端	M4 收藏	收藏与分组（默认“想吃”，可选“常吃”与自定义分组）、收藏态查询与取消；收藏菜品时异步生成贴纸素材	POST /favorites、DELETE /favorites、GET /favorites、/favorites/status
前台用户端	M5 AI 助手（福宝）	提问解析 → 平台真实数据检索 → LLM 生成，失败自动降级规则推荐；口味画像、个性化饮食计划（单日 / 3 日 / 7 日）、智能饮食推荐；模型与供应商配置、问答历史；输出统一标注“仅供参考”	POST /ai/ask、/ai/models*、/ai/providers、/ai/history*
前台用户端	M6 个人中心	资料 / 头像 / 改密、校园认证、饮食档案与隐私授权、我的评价与收藏、通知、用户主页、个人统计与头衔、虚拟宠物	PUT /me/profile、/me/password、GET /me/reviews、/me/favorites、/notifications、/users/:id/profile
前台用户端	M7 记饮食（打卡·手账·贴纸）	打卡记录、打卡日历、个人就餐足迹、本人统计；美食手账增删改查与背景上传；抠图生成的贴纸与贴纸库管理	/stickers(/:id)、/stickers/extract、/journal(/:id)、/journal/bg、打卡接口
前台用户端	M8 内容共建	新点位 / 档口 / 菜品提交与信息纠错、提交记录与审核结果、违规内容举报	POST /points-submit、POST /reports
管理端	M9 审核与治理	待复核队列（status=1）、通过 / 下架 / 屏蔽处置、举报处理（覆盖短评价与社区长帖）、敏感词库维护、运营看板	/admin/audit/pending、/admin/audit/:reviewId、/admin/reports*、/admin/words*、/admin/dashboard
管理端	M10 基础数据维护	食区 / 档口 / 菜品增删改、标签与价格维护、上下架独立接口、导览图位置拖拽校准、档口公告、提交审核	/admin/canteens*、/stations*、/dishes*、/posts*、/point-submits*
管理端	M11 用户与授权管理	用户检索、状态变更（禁言 / 封禁含到期时间）、档口负责人绑定；档口负责人端经营摘要与点位信息维护	/admin/users、/admin/users/:id/status、/admin/stations/:id/manager、/manager/*
管理端	M12 系统配置与运维	AI 供应商与平台托管模型管理、推送触发、榜单 / 评分聚合重算维护、贴纸素材同步	/admin/ai-providers*、/platform-models*、/push/run、/maintenance/recalc、/stickers/sync
公共支撑	M13 认证模块	注册、登录、图形验证码、模拟校园身份认证与真实 CAS-SSO 适配、JWT 签发、校内已认证标识	/auth/captcha、/register、/login、/fzu/*
公共支撑	M14 媒体模块	上传校验（≤5MB、文件头白名单）、dHash 判重、MinIO 私有桶入库、图片代理	POST /uploads、GET /img/*
公共支撑	M15 通知模块	审核处置、举报结果、回复、申诉、禁言封禁等通知生成，未读计数与已读标记，同类高频消息合并与订阅开关	GET /notifications、POST /notifications/read

1.2 ER 分析与表结构设计

设计思路：

1. 按数据域组织 78 张表，保持表归属稳定

• 项目约束：15 个功能模块共享 user、review、station、upload_asset、notification 等表；按业务边界划分数据域，可以让每张共享表有唯一归属。
• 设计选择：按业务边界划分为 D1 用户与身份、D2 餐饮基础数据、D3 点评与互动、D4 打卡与成长、D5 社区与内容治理、D6 推荐与 AI 助手六个数据域，表数分别为 17/11/12/14/11/13。
• 作用：同一数据域由同一责任方维护、变更频率相近，跨域只做只读引用，表结构在多人协作中保持稳定。

2. 用“概念—逻辑—物理”三层表达数据模型

• 项目约束：ER 分析需要同时说明业务对象、联系和具体表、字段、索引，概念图、逻辑表、物理设计分别承载这三类信息。
• 设计选择：概念层用陈氏菱形记法画 1 张总览图 C-0 和 6 张分域图 C-1—C-6，只画实体与联系；逻辑层给出 78 张表的主键、外键、唯一键和多态字段；物理层确定 InnoDB、utf8mb4、索引与事务。
• 作用：概念图回答“业务世界由哪些对象构成”，逻辑表回答“关系如何落地”，物理设计回答“如何存储和查询”。

3. 按 1:1、1:N、M:N 分别落地关系

• 项目约束：系统同时存在用户—认证、点位—营业信息这类一对一关系，食区—点位、评价—评分明细这类一对多关系，以及用户—角色、菜品—标签这类多对多关系；按基数选择落地方式可以让结构贴合业务语义。
• 设计选择：1:1 用独立表并加 UK(user_id) / UK(location_id)；1:N 在外键侧建 *_id；M:N 用关联表和复合主键；7 组多态引用用 biz_type + biz_id / parent_type + parent_id，通过应用层校验目标存在性。
• 作用：关系表达与业务基数一致，多对多通过关联表展开，多态目标可以在同一套结构中覆盖评价、帖子、评论等多种对象。

4. 主键、外键、唯一键按“可追溯、防重、可扩展”设计

• 项目约束：系统需要支持软删除、重复点赞 / 收藏、并发审核和内容重提；把防重放到数据库层，可以在并发下保持唯一性。
• 设计选择：主键用单列 id BIGINT UNSIGNED AUTO_INCREMENT，关联表用业务复合主键；106 条物理外键统一 ON DELETE RESTRICT ON UPDATE CASCADE，因存在循环引用分两遍 ALTER 添加；7 组核心唯一键直接落到数据库，软删除表用生成列 valid_flag 参与唯一键。
• 作用：主键单调递增、聚簇索引写入友好；外键保证引用完整；唯一键把防重从“应用层约定”提升为“数据库保证”。

5. 完整性约束尽量下沉到数据库

• 项目约束：评价状态、用户状态、举报类型、提审状态等枚举需要稳定取值，数据库约束可以在写入阶段校验取值。
• 设计选择：78 张表全部设主键；关键枚举字段加 16 项 CHECK；非空、默认值、DECIMAL 范围、坐标精度在列定义中约束；跨表业务组合由服务层校验。
• 作用：数据库在写入阶段校验取值，应用层可以专注于可预期冲突，聚合和审核流程获得稳定的数据口径。

6. 读多写少处适度反范式，并统一存储口径

• 项目约束：档口详情、榜单等读路径远多于评价写入，实时 JOIN 三张表求均分的成本高；将聚合结果物化可以降低读路径成本。
• 设计选择：review_summary 保存“对象 × 维度”的物化聚合，只统计 status = 0 AND deleted_at IS NULL，在发布、删除、下架、申诉通过四处重算；review.location_id 作为由 station_id 推导的受控冗余；4 个 JSON 列只做附属数据整体读写，查询和索引由结构化字段承担。
• 作用：高频读路径直接命中汇总表，写放大集中在低频评价写入；冗余列和 JSON 列都有明确的一致性保障和边界。

1.2.1 ER 分析

1. 概念模型与图集

概念结构设计采用陈氏菱形记法：矩形表示实体，菱形表示联系，线上数字表示基数（1 / N / M），概念层不画属性。设计共输出 1 张总览图 C-0 和 6 张分域图 C-1—C-6，覆盖系统全部业务对象。

图号	图名	实体数	联系数
C-0	概念 ER · 总览	12	11
C-1	概念 ER · 用户与身份（含 RBAC）	11	13
C-2	概念 ER · 餐饮基础数据	12	14
C-3	概念 ER · 点评与互动	12	12
C-4	概念 ER · 打卡与成长	15	14
C-5	概念 ER · 社区与内容治理	12	11
C-6	概念 ER · 推荐与 AI 助手	14	13
合计	—	88（含跨图重复）	88

图面合计 88 个实体、88 个联系，公共实体在相关视图中重复绘制。按实体名称去重后共 69 种对象，其中 68 种对应实体表；“业务对象（多态）”是抽象目标，由 biz_type 与 biz_id 定位实际业务记录。逻辑结构另设 7 张权限关联表、2 张标签关联表和 1 张评分维度适配表，形成 68 + 10 = 78 张表。

2. 总体骨架：三条主链

图 C-0　大福食刻 · 概念 ER 图（总览）

总览图把六个分域的主干压缩成三条链：

• 场景链：场地分类 / 食区 → 点位 → 档口 → 菜品。点位是餐饮基础数据的核心枢纽，向上接场地分类与食区，向下连档口。
• 评价链：档口 — 被评 → 评价 — 发布 → 用户。评价必须归属档口，用户是评价的发布者。
• 用户放射链：用户向外连打卡、帖子、通知，并以 M:N 关系连角色与成就。总览图只表达骨架，不展开各分域的细节联系。

3. 分域 ER 分析

D1 用户与身份（C-1，11 个实体、13 个联系，17 张表）

图 C-1　概念 ER · 用户与身份（含 RBAC）

• 身份侧：用户 1:1 校园身份认证、饮食档案、隐私设置；用户 1:N 搜索历史；饮食档案 1:N 饮食限制；校园身份认证通过学号与模拟身份数据集比对。
• 权限侧：用户 M:N 角色、角色 M:N 权限、用户 M:N 权限（直授）、用户 M:N 用户组、组 M:N 权限、组 M:N 角色、组 M:N 点位。
• 数据范围：组—覆盖—点位关系由 user_group_location 承载，解决“权限只到组级、无法表达覆盖哪些点位”的问题；权限树通过 permission.parent_id 自引用。

D2 餐饮基础数据（C-2，12 个实体、14 个联系，11 张表）

图 C-2　概念 ER · 餐饮基础数据

• 层级链：场地分类 1:N 点位，食区 1:N 点位，点位 1:1 营业信息、1:1 地图位置，点位 1:N 档口，档口 1:N 菜品。
• 扩展关系：菜品 M:N 标签，档口 1:N 档口公告，用户 M:N 档口（station_manager 负责人绑定），内容共建申请可提交点位、档口或菜品。
• 设计要点：location.canteen_id 可空表示校外点位，校外点位与校内点位共用同一套点位结构；营业状态只在 business_info 维护；station.owner_id 为预留列，当前 RBAC 范围计算以角色与权限关联表为准。

D3 点评与互动（C-3，12 个实体、12 个联系，12 张表）

图 C-3　概念 ER · 点评与互动

• 评价轴心：评价 N:1 用户、点位、档口、菜品（菜品可空）；评价 1:N 评分明细、评价图片、点赞；评价 M:N 标签；评价 1:N 申诉。
• 互动关系：用户 1:N 收藏、举报；收藏 N:1 收藏分组；评分明细 N:1 评分维度字典；评分维度 M:N 就餐方式。
• 汇总设计：review_summary 以“对象 × 维度”为聚合粒度，一条记录汇总该对象在该维度上的全部评分，因此与评分维度关联；点赞、收藏、举报、申诉四类互动围绕评价展开，其中申诉针对评价本身。

D4 打卡与成长（C-4，15 个实体、14 个联系，14 张表）

图 C-4　概念 ER · 打卡与成长

• 打卡轴心：打卡 N:1 用户、点位；打卡 1:N 打卡菜品、打卡图片；打卡生成手账，手账 1:N 手账图片。
• 成长支线：用户 1:1 宠物，宠物 1:N 喂食记录；用户 M:N 成就（user_achievement）；用户 1:N 金币流水；任务 1:N 任务领取记录；用户 1:N 贴纸。
• 设计要点：足迹按“用户 × 点位”唯一，多次打卡复用同一条足迹；一次打卡同步写入打卡日历、就餐足迹、手账、成就与宠物奖励，用户操作保持一步完成。

D5 社区与内容治理（C-5，12 个实体、11 个联系，11 张表）

图 C-5　概念 ER · 社区与内容治理

• 社区侧：用户 1:N 帖子、通知、草稿；帖子 1:N 评论、帖子关联；用户 M:N 关注；帖子关联可指向点位或菜品。
• 治理侧：审核记录与操作日志通过 biz_type + biz_id 指向多态业务对象；敏感词库独立存在，用 severity 分级、action 记录处置动作。
• 设计要点：审核记录用 submitter_id 追踪提交人、auditor_id 关联审核人；评论父对象是多态的（帖子 / 评价），用 parent_type + parent_id 表达，避免“评价区的评论无处安放”。

D6 推荐与 AI 助手（C-6，14 个实体、13 个联系，13 张表）

图 C-6　概念 ER · 推荐与 AI 助手

• 推荐侧：用户 1:N 推荐结果、饮食计划、偏好分析、浏览行为；用户 1:1 口味画像；推荐规则 1:N 推荐结果；推荐结果 1:N 推荐项；饮食计划 1:N 计划项。
• AI 侧：用户 1:N 发起 AI 会话，AI 供应商 1:N 提供会话，会话 1:N 会话消息；用户配置自配模型，自配模型引用平台模型目录。
• 设计要点：推荐项多态指向点位或菜品；AI 供应商以注册表配置化接入，平台托管模型与用户自配模型分表承载，避免密钥与配置混在一起。

4. 关系类型与落地方式

关系类型	典型例子	落地方式
1:1	用户—校园认证、用户—饮食档案、点位—营业信息、用户—宠物	独立表 + UK(user_id) 或 UK(location_id)
1:N	食区—点位、点位—档口、档口—菜品、评价—评分明细 / 图片	N 侧外键
M:N	用户—角色、角色—权限、菜品—标签、评价—标签、用户—成就、用户—关注	关联表 + 复合主键
多态	点赞、收藏、举报、审核记录、通知跳转、帖子关联、评论父对象	biz_type + biz_id / parent_type + parent_id，不建外键，应用层校验 + 复合索引

5. 关键设计取舍

• 评价的落点：评价必关联档口 station_id，location_id 作为受控冗余同时保留；服务层校验评价、菜品、档口与点位的归属关系。
• 评价是否可编辑：不支持编辑，只支持软删除与申诉恢复；review.status 取 0 已发布 / 1 待人工复核 / 2 已下架折叠 / 3 已驳回四态，避免“改过内容”破坏已聚合评分。
• 营业状态只在一处维护：business_info.business_status 是唯一维护点，点位与档口不重复存该字段。
• 评分维度由就餐方式决定：review.meal_mode 是评分维度适配的唯一依据，场所类型不参与打分；维度规则由 review_dimension 与 review_dimension_meal_mode 配置驱动。
• 不建宠物道具表：宠物玩法只保留 pet、feed_record、coin_transaction 三表，奖励与消耗都走金币流水。
• 多态字段不建物理外键：7 组多态引用由应用层校验存在性，并以 idx(biz_type, biz_id) 支撑反查；删除对象时由定时任务清理悬挂引用。
• 软删除与唯一键冲突：引入生成列 valid_flag = IF(deleted_at IS NULL, 1, NULL)，唯一键包含该列，使有效记录满足业务唯一性，同时允许保留多条软删除历史。
• AI 供应商密钥只存密文：用户自带密钥以 AES-256-GCM 密文入库，ai_provider.api_key_ref 只存引用或密文，禁止明文入库。

6. 功能模块与数据域对应

模块	数据域	核心表
M1 点位浏览 / M10 基础数据维护	D2	canteen、location、station、dish、business_info、map_location、dish_tag
M2 搜索与推荐	D2 + D6	search_history、browse_event、review_summary、recommendation、recommendation_item
M3 评价与社区内容 / M4 收藏	D3	review、rating_detail、review_image、review_tag、favorite、review_appeal
M5 AI 助手（福宝）	D6	ai_provider、ai_conversation、ai_chat_message、taste_profile、diet_plan、diet_plan_item
M6 个人中心	D1 + D5	user、campus_auth、dietary_profile、privacy_setting、notification、pet
M7 记饮食（打卡·手账·贴纸）	D4	check_in、check_in_dish、check_in_image、journal、journal_image、footprint、sticker
M8 内容共建	D2 + D5	report、audit_record、post、post_link、draft
M9 审核与治理	D5	audit_record、banned_word、report、operation_log、notification
M11 用户与授权管理	D1	user、role、permission、user_role、user_permission、user_group、station_manager
M12 系统配置与运维	D6 + D5	ai_provider、recommendation_rule、upload_asset、notification
M13 认证模块	D1	user、campus_auth、mock_identity_dataset
M14 媒体模块	D2 + D5	upload_asset、review_image、check_in_image、journal_image
M15 通知模块	D5	notification

1.2.2 表结构设计

1. 总体规模与命名约定

数据库采用 MySQL 8（InnoDB，utf8mb4，时区 +08:00），共 78 张表、545 个实际列，其中建模字段 460 个；另有 106 条外键、16 项 CHECK 约束和 22 条关键业务约束。

命名与通用约定如下：

• 表名全小写 snake_case、一律单数，如 review、station；关联表按“主体表_客体表”命名，如 dish_tag。
• 字段全小写 snake_case；主键统一 id；外键为“目标表单数名_id”，如 station_id；布尔用 is_ / has_ / enabled；时间点用 _at，日期用 _date，计数用 _count。
• 全表统一追加 id / created_at / updated_at / deleted_at 四列；deleted_at DATETIME NULL，NULL 表示有效。
• 金额 DECIMAL(10,2)，评分 DECIMAL(2,1)，坐标 DECIMAL(10,7) 且全链路 GCJ-02；多态字段用 biz_type TINYINT + biz_id BIGINT。

2. 六域表总览

数据域	表数	核心业务对象	主要责任方
D1 用户与身份	17	用户、校园认证、饮食档案、隐私设置、RBAC	平台管理员
D2 餐饮基础数据	11	食区、点位、档口、菜品、标签、营业信息、地图位置	数据维护人员
D3 点评与互动	12	评价、评分明细、维度字典、图片、点赞、收藏、举报、汇总	用户 / 管理员
D4 打卡与成长	14	打卡、手账、足迹、成就、宠物、金币流水、任务	用户
D5 社区与内容治理	11	帖子、评论、关注、通知、审核记录、敏感词、操作日志	用户 / 管理员
D6 推荐与 AI 助手	13	推荐结果与规则、口味画像、饮食计划、AI 供应商与会话	算法 / 管理员
合计	78	—	—

3. 核心表结构简要说明

表名	用途	主键	关键字段	主要外键 / 关联
user	用户账号	id	nickname、avatar、student_no、phone、phone_hash、status	被评价、打卡、帖子、通知等引用
campus_auth	校园身份认证	id	user_id、student_no、status、verified_at	UK(user_id)、UK(student_no)
role / permission / user_role	RBAC 角色、权限与用户角色关联	id / user_id + role_id	role_code、role_name；perm_code、parent_id、grantable	另配 6 张权限关联表
canteen	食区	id	name、type、campus、status、sort	被 location.canteen_id 引用
location	点位	id	name、address、scene_category_id、canteen_id、map_location_id、business_info_id	canteen_id 可空表示校外点位
station	档口	id	name、location_id、map_location_id、business_hours、owner_id、status	档口 1:N 菜品
dish	菜品	id	station_id、name、price_unit、image、status	station_id 非空
review	评价	id	user_id、location_id、station_id、dish_id、content、meal_mode、status	station_id 非空；location_id 受控冗余
rating_detail	评分明细	id	review_id、dimension_id、score	UK(review_id, dimension_id)；score 1.0—5.0
review_summary	评价汇总（物化聚合）	id	biz_type、biz_id、dimension_id、review_count、均分	UK(biz_type, biz_id, dimension_id)
favorite	收藏	id	user_id、biz_type、biz_id、group_id	UK(user_id, biz_type, biz_id, valid_flag)
check_in	打卡记录	id	user_id、location_id、check_in_date、visibility、note	1:N 打卡菜品 / 图片；生成手账
journal	美食手账	id	check_in_id、note、template、is_private	1:N 手账图片
post	社区帖子	id	user_id、content、images、post_type、journal_id、status	1:N 评论、帖子关联
notification	通知	id	user_id、type、biz_type、biz_id、is_read、content	多态跳转目标
audit_record	审核记录	id	biz_type、biz_id、submitter_id、auditor_id、status、reason、version	UK(biz_type, biz_id, version)
ai_provider / ai_conversation	AI 供应商与会话	id	base_url、api_key_ref、model、is_active；user_id、provider_id、title	会话 1:N 消息

4. 主键、外键与唯一约束

• 主键：78 张表全部设置主键，采用单列 id 或业务复合主键；单列主键为 BIGINT UNSIGNED AUTO_INCREMENT，关联表用 user_id + role_id 等复合主键。
• 外键：106 条物理外键覆盖全部确定性关系，统一 ON DELETE RESTRICT ON UPDATE CASCADE；因存在循环引用（如 location.map_location_id 与 map_location），建表与加外键分两遍执行。
• 唯一键：7 组核心唯一键把防重落到数据库层。

表	唯一键	保证的规则
review_like	UK(user_id, biz_type, biz_id, valid_flag)	一人一条点赞，软删后可重
favorite	UK(user_id, biz_type, biz_id, valid_flag)	一人一条收藏
follow_relation	UK(follower_id, followee_id, valid_flag)	关注防重
footprint	UK(user_id, location_id)	一用户一点位一足迹
task_claim	UK(user_id, task_id, claim_date)	每日限领一次
rating_detail	UK(review_id, dimension_id)	一评价一维度一行
review_summary	UK(biz_type, biz_id, dimension_id)	对象 × 维度汇总唯一

• CHECK：16 项约束覆盖用户状态、评价状态、就餐方式、评分范围、举报对象类型与处置状态、提审类型与审核状态、角色数据范围、敏感词分级与动作等关键枚举。
• 多态：7 组多态引用不建物理外键，写入时由应用层校验目标存在性，读取时按 biz_type 走对应 JOIN，巡检任务定期清理悬挂引用。

5. 索引与性能

• 唯一索引：7 组核心唯一键，保证“同一用户对同一对象只有一次有效行为”。
• 热点复合索引：12 条，按实际查询场景设计，遵循最左前缀，等值列在前、范围 / 排序列在后。具体为 review(location_id, status, created_at)、review(station_id, status)、review(dish_id, status)、review(user_id, created_at)、review(status, created_at)、check_in(user_id, check_in_date)、check_in(location_id, check_in_date)、notification(user_id, is_read, type, created_at)、audit_record(status, created_at)、report(status, created_at)、ai_conversation(user_id, created_at)、ai_chat_message(session_id, id)。
• 多态索引：7 组多态字段统一建 idx(biz_type, biz_id)，支撑“某对象有多少赞 / 多少举报 / 被多少帖子引用”的反查。
• 覆盖索引：review_summary 另建 idx_review_summary_dim(dimension_id)，支持按维度反查高分对象，避免回表。
• 负面清单：不建外键列单独索引（MySQL 会自动建）、不建单列 status 索引（区分度低）、不建超过 4 列的复合索引、不给 4 个 JSON 列建索引。
• 分区与容量：本期不做表分区。按日活约 2 万、评价日增约 2000 行估算，一年约 73 万行，InnoDB B+ 树深度约 3 层，普通索引足够；分区还会与 7 组唯一键防重冲突。
• 事务：评价发布采用“评价 + 评价图片 + 评价汇总”同事务写入，失败整体回滚；汇总表在发布、删除、下架、申诉通过四处触发重算。

6. 数据安全与权限落库

• RBAC 落库：role、permission、user_group 三张定义表，加 user_role、user_permission、role_permission、user_group_member、group_permission、group_role、user_group_location 七张关联表，覆盖“经角色、经组、直接授权”三条权限来源。
• 数据范围：user_group.data_scope 取 1 仅本人 / 2 组范围 / 3 全量；user_group_location 保存组覆盖的点位集合；档口负责人额外叠加 station_manager 绑定校验。
• 口令与密钥：用户口令只存散列；AI 供应商密钥与用户自配密钥以 AES-256-GCM 密文入库，主密钥不入库，接口不回传明文。
• 查询安全：数据访问层统一参数化 SQL，不拼接用户输入；排序字段走白名单；多态目标写入前做存在性校验。
• 审计与软删除：audit_record、operation_log 保留审核与管理员操作留痕；业务表统一 deleted_at 软删除，保留审计所需的历史记录。

说明：本节只列核心表结构与关键约束，78 张表的完整字段、545 列注释、建表 SQL 与索引清单见《数据库设计说明书》附录 A、附录 B。

1.3 数据流图设计

设计思路：

1. 用三级分解覆盖边界、组成与步骤

• 项目约束：1.1 从结构视角描述分层与部署，1.2 从数据视角描述实体与表，系统行为需要独立的数据流模型支撑；12 张图的信息量要求分级组织。
• 设计选择：顶层图 P0 界定系统与 E1—E7 七个外部实体的边界；一层图把系统分解为 P1—P8 八个加工与 D1—D11 十一个数据存储；二层图选取 P1、P3、P4、P5、P7 五条核心链路细化到加工内部步骤。
• 作用：读者按“系统边界 → 加工组成 → 加工步骤”逐层展开，每一层承担一种粒度的阅读需求。

2. 一层图按业务主线拆分，共用同一套存储编号

• 项目约束：八个加工与十一个存储绘制在同一张图面时连线交叉密集；五张分图之间的数据往来相对稀疏。
• 设计选择：按业务内聚性拆为身份与浏览（P1、P2）、内容生产（P3、P4）、个性化（P5）、社区与通知（P6）、治理与管理（P7、P8）五张分图；D1—D11 编号全文复用，同一编号代表同一份存储。
• 作用：每张分图的连线密度可控，主线之间通过共享存储衔接，五张分图合并后与顶层图的数据流总量一致。

3. 父图与子图保持平衡

• 项目约束：分级绘制时，子图需要与父图的边界数据流保持一致。
• 设计选择：顶层的外部实体与进出数据流在一层完整保留；二层仅绘制与该加工相关的实体与存储；加工编号与加工说明逐条对应。
• 作用：任意一张子图都可以向上追溯到父图，评审时按编号核对即可定位差异。

4. 业务约束落在加工判定与数据流路径上

• 项目约束：先发后审、共建内容审核通过后进入公共搜索、隐私授权按用途分别校验、AI 与地图服务异常时降级，这些约束需要在行为模型中可见。
• 设计选择：约束写成加工内部的判定分支与读写路径，例如 P3.2 先校验档口归属再写入评价、P7.2 审核通过后由 P7.3 发布进 D3、P5.1 按用途读取 D2 授权开关。
• 作用：评审时沿数据流路径即可核对约束的落实位置，设计、开发与测试共用同一套行为依据。

1.3.1 顶层数据流图

图 4-0　顶层数据流图（P0）

说明： P0 把系统整体视为单一加工，界定 E1—E7 七个外部实体。游客与 C 端用户是同一用户的不同登录状态，游客状态仅与浏览类数据流交互，对应“浏览免费、写操作需登录”的需求条目。食堂监督员按 RBAC 方案仅拥有食堂运营汇总的只读查看权限，其数据流与平台管理员的汇总信息流向一致，合并为同一实体绘制。高德地图 API 与 AI 服务接口为外部系统：地图服务异常时导览图降级为档口列表，AI 服务异常时推荐降级为规则化结果，两项降级由系统内部加工完成，边界数据流保持稳定。

1.3.2 一层数据流图

一层图统一采用双向边画法，标签格式为“加工接收的数据 / 加工输出的数据”，同一节点对之间绘制一条连线；同一数据存储在多张分图中复用同一编号。

1. 图 4-1 身份与浏览主线（P1、P2）：

P1 承担登录认证、权限计算与令牌签发，P2 承担分类浏览、搜索、详情、对比与导览。C 端用户向 P1.1 提交登录凭证，P1.2 按“直接授权 ∪ 角色权限 ∪ 组权限”计算权限集，P1.3 签发仅含用户 ID 的 JWT 并返回；P1.4 在每次受保护请求中读取 D1 的用户信息与权限完成鉴权，审计日志写入 D10。浏览请求经 P2 读取 D3 基础数据与 D4 评价数据，返回列表、详情、榜单、对比视图与导览图；地图服务异常时导览图降级为档口列表。

2. 图 4-2 内容生产主线（P3、P4）：

P3 处理评价、点赞、收藏与举报提交。评价提交先由 P3.1 按就餐方式适配评分维度，再由 P3.2 读取 D3 完成档口归属校验，评分明细与图片写入 D4；P3.3 聚合评分仅统计状态正常的有效评价，并回写 D3 的对象总分；违规评价经 P3.5 下架，触发聚合重算与缓存失效，获赞与审核结果通知写入 D9，操作写入 D10。P4 处理一体化打卡，打卡记录与菜品清单写入 D5，日历、足迹、成就与金币奖励随同一次打卡联动完成。

3. 图 4-3 个性化主线（P5）：

P5 覆盖首页推荐与 AI 助手两类场景，按“场景”字段区分并共用同一条生成链路。P5.1 读取 D2 的饮食档案与隐私授权开关，按用途分别校验饮食授权、行为授权与匹配授权；P5.3 在候选集阶段按严重过敏与忌口规则硬过滤，再结合 D8 画像与 D3 基础数据生成推荐结果与饮食计划；AI 服务异常时由 P5.4 降级为热门或规则推荐，画像数据不足时返回数据不足提示，其余分支照常输出。

4. 图 4-4 社区与通知主线（P6）：

P6 处理长帖、评论、点赞与收藏，社区内容读写 D6，举报转 D7；五类通知（评价获赞、帖子互动、审核结果、举报处理结果、系统消息）由 D9 汇总后经 P6 展示，同类高频通知合并呈现。通知输出经加工完成，展示时按接收人做 SELF 数据范围检查。

5. 图 4-5 治理与管理主线（P7、P8）：

P7 处理内容共建提交与审核，P8 处理后端数据维护、权限配置与审计检索。维护员提交的维护数据按 GROUP 范围过滤后写入 D3；权限配置由超级管理员经 P8 写入 D1，变更后触发权限缓存失效；审核、处置与权限变更均写入 D10，D10 在业务侧只追加、只由 P8 检索。

1.3.3 二层数据流图

二层图从一层图选取五条核心链路展开，P7 按审核线与举报线拆为两张。

1. 图 5-1 登录认证与权限校验（P1）：

P1.1 读取 D11 模拟身份认证数据集完成学号与姓名比对，认证通过时触发 verified_user 角色切换；P1.2 按“自身权限 ∪ 角色权限 ∪ 组权限”计算总权限并读取 D1；P1.3 签发仅含用户 ID 的 JWT，令牌在后续请求中承担身份凭证；P1.4 在每次受保护请求中从 D1 读取当前权限、账号状态与组点位集合，完成鉴权与数据范围过滤，GROUP 范围按本次权限编码绑定的维护组点位集合计算。游客访问公开浏览接口时按 guest 只读权限集放行；角色、权限与组成员变更后权限缓存立即失效，下一次请求按新状态判定。

2. 图 5-2 写评价与聚合评分更新（P3）：

P3.1 按本次就餐方式适配评分维度：堂食取口味、份量、排队体验，打包取口味、份量、包装，外送取口味、份量、包装、配送速度；评分明细按维度逐行写入 D4。评价必选关联档口，P3.2 读取 D3 校验档口归属，菜品为可选项且校验其属于该档口。评价发布即对外可见，违规评价由平台管理员经 P3.5 下架并通知作者；P3.3 聚合评分仅统计状态正常的有效评价，下架成功后触发受影响对象的聚合重算与缓存失效；P3.4 同一用户对同一内容维护一条有效点赞或收藏记录，重复操作按去重切换处理。菜品缺失时，用户可经 P3.2 提交新增菜品申请，转入 P7 审核队列，通过后进入 D3。

3. 图 5-3 一体化打卡（P4）：

P4.1 校验菜品归属点位与打卡资格；同一点位当日重复打卡时返回确认提示，确认后补记一条打卡记录用于日历展示，并按“用户 + 点位 + 日期”幂等去重，统计与奖励各计入一次。P4.2 把打卡记录与所含菜品清单一并写入 D5 并更新当日日历；P4.3 在首次到访时点亮足迹，以“是否首次到访”标记控制点亮次数；P4.4 依据有效打卡事件刷新成就进度，并按打卡直接入账模式生成金币流水。宠物采用表情反馈机制，喂食直接消耗金币并保存喂食记录，反馈以表情切换呈现，余额不足时返回提示，喂食记录以余额充足为生成条件。手账默认私有，用户主动转为帖子草稿后经 P6 进入社区公开范围。

4. 图 5-4 AI 助手与推荐生成（P5）：

P5 按推荐结果的“场景”字段区分首页推荐与 AI 助手，共用同一条生成链路。过敏与忌口约束贯穿全部生成路径：P5.3 在候选集阶段按 D2 的严重过敏与忌口规则硬过滤，安全类规则动作取“剔除”；AI 结果返回后再次核对菜品标识仍在允许候选集内；热门与规则降级路径执行同一约束。饮食授权、行为授权与匹配授权按用途分别校验：口味画像读取行为数据需行为授权，饮食计划基于显式饮食档案生成，饭搭子匹配需匹配授权。画像数据不足时仅画像分支返回数据不足提示，首页推荐降级为通用热门，饮食计划走规则与模板，两条分支各自输出。用户撤回授权后先停止按该用途读取行为数据，再按确认规则处理 D8 中已有的画像与派生结果。

5. 图 5-5 内容共建与审核（P7）：

P7.1 接收点位、档口、菜品与纠错内容的共建提交并写入 D7；P7.2 由平台管理员审核，审核通过后由 P7.3 发布进入 D3，公共搜索仅能检索到“通过”状态的记录；驳回记录保留在 D7，用户可重新编辑后再次提交，重新提交生成新的提交版本并保留先前驳回原因。审核结果、原因、审核人与提交版本回写 D7；通过与驳回均经 P7.5 写入 D9 并通知提交者；审核操作写入 D10，支持责任追溯。

6. 图 5-6 举报处置（P7）：

P7.4 与审核线共用 D7、D9、D10 与 P7.5。举报范围覆盖评价、打卡、帖子与评论：帖子与评论经 D6 读取举报内容并回写状态，评价经 D4、打卡经 D5 读取被举报对象并执行处置，历史关系保留，状态变更后从公共检索与聚合评分中排除。P7.4 从 D7 读取待处理举报，核实后由平台管理员执行处置措施；处置结论回写 D7，并触发对应对象的聚合评分重算与检索缓存失效；结果经 P7.5 写入 D9 并通知举报用户；处置操作写入 D10。

说明：本节按《大福食刻 数据流图设计方案》V1.1 的图序插入 12 张图；数据流完整组成、外部实体定义与数据存储清单见该文档第 6 章数据字典，加工处理要点见第 7 章加工说明。

二、类图、系统安全和权限设计

2.1 设计类图

设计思路：

1. 以领域实体为类，按模块拆成 7 张图

• 项目约束：系统有 15 个功能模块、78 张表；单张总览图信息密度过高，拆成 1 张总览图 + 6 张模块图可以让职责和关系清晰可读。
• 设计选择：1 张领域总览图（图 3-1）+ 6 张模块类图（图 3-2—图 3-7）。
• 作用：总览图给出系统骨架，模块图展开属性、方法和多重度；读者可以先看整体，再按模块查细节。

2. 用组合表达整体—部分与生命周期

• 项目约束：评价—评分明细/图片、帖子—评论、打卡—打卡菜品、饮食计划—计划项、推荐结果—推荐项都存在“整体删除后部分随之失效”的关系。
• 设计选择：这些关系用实心菱形组合表示，部分对象随整体创建、删除；本期领域模型中的整体—部分关系均具有强生命周期，统一用组合表示，聚合关系留待部分对象具备独立生命周期时引入。
• 作用：类图直接表达级联删除和事务边界，评分明细、评论等对象按部分对象管理。

3. 用多态关联替代实体继承

• 项目约束：评价、帖子、打卡、评论的字段各有特点；点赞、收藏、举报、审核记录、通知需要指向多种业务对象。
• 设计选择：类图采用扁平实体结构；跨类型引用统一用“目标类型 + 目标 ID”表达。
• 作用：减少空字段子类；新增对象类型时只需增加类型枚举和校验分支，继承树保持稳定。

4. 关联表达业务语义，表结构细节交给映射表

• 项目约束：类图与数据库设计属于两种抽象；类图聚焦业务对象与多重度，外键和表结构放在映射表中说明，可以保持可读性。
• 设计选择：类图只画 1:1、0..1、1:N、M:N 和多重度；类与表的对应集中放在 2.1.7 的映射表。
• 作用：类图保持业务可读性，数据库细节留在 1.2 和建表脚本中。

5. 领域行为放在类上，跨类编排放在服务层

• 项目约束：评价发布涉及评价、图片、汇总三张表的事务；类方法表达领域行为，事务边界由服务层承担。
• 设计选择：类图保留 发布()、创建打卡()、加入收藏()、更新() 等关键领域方法；事务、鉴权、聚合重算由服务模块编排。
• 作用：类图能说明对象能做什么；服务层负责事务、鉴权和聚合重算。

6. 外部依赖用依赖关系表示，保持领域模型边界清晰

• 项目约束：地图、LLM、校园身份认证、抠图都是外部能力，接口与可用性由外部平台负责。
• 设计选择：领域类图只画业务对象；校园认证对模拟身份数据集用虚线依赖，推荐结果对推荐规则用虚线依赖；AI 供应商、会话作为支撑类在接口层说明。
• 作用：系统边界清楚，外部服务替换或降级时领域模型保持稳定。

2.1.1 类图范围与建模约定

• 图集：图 3-1 领域总览；图 3-2 用户与身份；图 3-3 餐饮基础数据；图 3-4 点评与互动；图 3-5 打卡与成长；图 3-6 社区与内容治理；图 3-7 推荐与 AI 助手。
• 记法：类矩形分三栏（类名、属性、方法）；实线表示关联，线上标注 1 / 0..1 / * / 1..*；实心菱形表示组合；虚线箭头表示依赖。
• 属性只保留业务字段（如用户 ID、状态、就餐方式），不画 created_at、updated_at 等审计列。
• 方法只保留领域行为（发布()、打卡()、收藏()、刷新()），不画 getter / setter。
• 本系统类图没有继承箭头，继承相关的取舍见 2.1.5。

2.1.2 核心业务类

模块	核心类	主要职责
总览 3-1	用户、评价、打卡、帖子、点位、档口、菜品、审核记录	系统骨架：基础数据链、内容链、治理链
3-2 用户与身份	用户、饮食档案、隐私设置、校园身份认证、模拟身份认证数据集、组、角色、权限	身份、档案、隐私、RBAC
3-3 餐饮基础数据	场景分类、点位、档口、营业信息、地图位置、菜品、标签	四级基础数据与营业状态
3-4 点评与互动	评价、评分明细、标签、图片、收藏、收藏分组、点赞、举报	评价、评分维度、互动
3-5 打卡与成长	打卡、打卡菜品、手账、足迹、成就、用户成就、宠物、喂食记录、金币流水	打卡、手账、成长联动
3-6 社区与治理	帖子、评论、帖子关联对象、点赞、举报、审核记录、通知	社区内容、审核、通知
3-7 推荐与 AI	偏好分析、口味画像、推荐结果、推荐规则、推荐项、饮食计划、计划项	推荐、画像、饮食计划

2.1.3 领域总览类图（图 3-1）

图 3-1　领域总览类图

图 3-1 只保留最核心的类与关系，展示系统整体骨架：

• 基础数据主干：点位 → 档口 → 菜品；上游场景分类见图 3-3，本图从简未画。
• 内容主干：用户发布评价、打卡、帖子；评价必选关联档口，打卡关联点位，帖子可关联多个点位或菜品。
• 治理主线：评价与帖子按“先发后审”治理，发布即可见，违规后经审核记录处置下架；打卡不进入审核链路，其治理由举报处置线承接。
• 角色与营业状态：图中“角色”为集合含义，用户与角色的多对多关系见图 3-2；营业状态统一由营业信息维护（图 3-3），本图不重复列出。

2.1.4 分模块类图

1. 用户与身份（图 3-2）

图 3-2　用户与身份模块类图

• 用户 1:1 拥有饮食档案（忌口、过敏、预算区间、口味偏好、饮食目标）和隐私设置（饮食、行为、通知、匹配四类授权开关）；0..1 持有校园身份认证，仅已认证用户有记录。
• 校园身份认证通过虚线依赖“比对”模拟身份认证数据集，认证通过后写入认证记录。
• RBAC：用户—角色、用户—组、用户—权限、组—角色、角色—权限、组—权限均为多对多；用户总权限 = 自身直接授权 ∪ 角色权限 ∪ 组权限。
• “可授权”记录在授权关系上，随授权对象不同而变化；同一权限对普通持有者仅可使用，对超级管理员可再分配。
• 组通过“数据范围”属性承担维护员的行级数据权限，按食堂 / 场景划分。

2. 餐饮基础数据（图 3-3）

图 3-3　餐饮基础数据模块类图

• 按“场景分类 → 点位 → 档口 → 菜品”四层组织基础数据，覆盖食堂、永嘉天地、学生街、小摊、私厨等就餐场景。
• 点位拥有 1:1 的营业信息（营业时间、营业状态、联系方式）和地图位置；档口可选配 0..1 的导览坐标，用于食堂档口导览图。
• 菜品与标签为多对多标注（忌口、食材、场景适配）；菜品停用只改“状态”，保留历史评价与打卡。
• 营业状态统一由营业信息维护，点位侧通过关联读取，避免两处冗余。

3. 点评与互动（图 3-4）

图 3-4　点评与互动模块类图

• 评价必选关联档口，可选关联菜品；提交时校验“菜品属于该档口、档口属于所选点位”。
• 就餐方式（堂食 / 打包 / 外送）决定展示的评分维度：堂食→排队体验，打包→包装，外送→配送速度 + 包装；一条评价对应多条评分明细。
• 评价 1:N 评分明细、1:N 图片、M:N 标签；状态字段支撑先发后审下的违规下架，已下架评价不参与聚合评分。
• 点赞与收藏均通过“目标类型 + 目标 ID”支持多类对象；同一用户对同一内容仅产生一个有效点赞和一个收藏关系；收藏归入收藏分组（“想吃”“常吃”为默认分组）。

4. 打卡与成长（图 3-5）

图 3-5　打卡与成长模块类图

• 打卡 N:1 用户、点位；打卡 1:N 打卡菜品，0..1 关联手账；手账默认私有，可转为帖子草稿。
• 首次打卡某点位时自动点亮足迹，重复打卡不重复点亮；打卡同时更新用户成就进度。
• 用户 1:1 宠物，宠物 1:N 喂食记录；喂食消耗、打卡奖励、成就奖励统一走金币流水，不建独立道具表和任务类。
• “是否首次到访”“可见范围”支撑足迹统计与隐私控制。

5. 社区与内容治理（图 3-6）

图 3-6　社区与内容治理模块类图

• 帖子 1:N 评论、1:N 帖子关联对象；帖子关联对象可指向点位或菜品，支持攻略类多对象分享。
• 评论通过父对象类型 + 父对象 ID 支持帖子和评价；图中以帖子为主，评价侧复用同一逻辑类。
• 点赞、举报采用“目标类型 + 目标 ID”统一覆盖帖子与评论，与图 3-4 为同一逻辑类。
• 审核记录记载目标、提交者、审核人、状态与原因；内容共建走发布前审核，评价 / 帖子走先发后审。
• 通知记录“发送方类型 + 发送方 ID”区分系统通知与用户互动，“目标类型 + 目标 ID”支持点击跳转，并按类型合并展示。

6. 推荐与 AI 助手（图 3-7）

图 3-7　推荐与 AI 助手模块类图

• 每个用户 0..1 拥有唯一口味画像，数据不足时不强行生成；用户 1:N 推荐结果、1:N 饮食计划。
• 推荐规则 1:N 推荐结果；推荐结果 1:N 推荐项，推荐项可指向点位或菜品并带得分；饮食计划 1:N 计划项，计划项按“用餐日期 + 餐次”排期并可跳转菜品。
• 推荐规则采用“条件 + 动作 + 权重”三段式：偏好类规则填权重做软排序，安全类规则填动作 = 剔除，在候选集阶段硬过滤过敏 / 忌口，降级类规则填动作 = 降级。
• AI 接口不可用时降级为规则推荐或热门内容；所有 AI 输出仅供参考，使用前受隐私授权开关二次约束。
• 图 3-7 主要展开推荐侧；AI 供应商、AI 会话、AI 会话消息属于接口层支撑类，结构见 1.2 的 ai_provider、ai_conversation、ai_chat_message。

2.1.5 类之间关系分析

关系类型	UML 表示	本系统例子	设计含义
1:1 关联	实线 + 1—1	用户—饮食档案、用户—隐私设置、点位—营业信息	一对一扩展信息，独立表承载
0..1 关联	实线 + 1—0..1	用户—校园身份认证、打卡—手账	可选关系，未认证 / 未写手账时为空
1:N 关联	实线 + 1—*	场景分类—点位、点位—档口、档口—菜品、评价—评分明细	强归属，N 侧持有外键
M:N 关联	实线 + —	用户—角色、角色—权限、菜品—标签、帖子—点位 / 菜品	关联表落地，类图不画关联类
组合	实心菱形	评价—评分明细 / 图片、帖子—评论、打卡—打卡菜品、计划—计划项、推荐结果—推荐项	部分随整体删除，事务一起提交
聚合	空心菱形	本期领域模型未单独使用	整体—部分均按强生命周期处理，避免把可独立对象误判为部分
依赖	虚线箭头	校园认证→模拟身份数据集、推荐结果→推荐规则、通知→目标对象	仅引用目标，目标变化时主体保持稳定
继承	空心三角箭头	本期无继承	类型差异由多态关联与服务层策略承载

继承关系的处理。

本系统采用扁平实体模型：评价、帖子、点赞、收藏等对象各自独立建模，类型差异通过“目标类型 + 目标 ID”的多态关联表达，原因有三点：

1. 业务对象字段差异大，扁平建模让每个类只保留自身字段，表结构保持紧凑。
2. 点赞、收藏、举报、审核、通知的目标类型会持续增加，多态关联只需追加类型枚举，类型体系保持稳定。
3. 发布、审核、聚合等规则差异放在服务层策略中，由策略组合实现扩展，类结构保持稳定。

实体之间统一用“目标类型 + 目标 ID”表达跨类型引用，由服务模块处理不同对象的发布、审核和聚合规则。这样新增一种被赞 / 被举报对象时，只增加类型枚举和校验分支，类图结构保持不变。

2.1.6 遵循的设计原则

• 单一职责：每个类只表达一个业务对象；评价负责评价内容本身，聚合重算与规则配置分别由独立对象承担。
• 高内聚、低耦合：类按模块分图，跨模块只通过 ID 或关联对象引用，模块边界保持独立。
• 组合优于继承：整体—部分用组合表达，类型差异用多态关联与策略承载。
• 多态替代类型爆炸：点赞、收藏、举报、审核、通知统一用“类型 + ID”，新增目标类型时类图结构保持稳定。
• 依赖倒置与接口隔离：地图、LLM、校园认证、抠图通过适配接口接入，领域类只依赖抽象接口。
• 开闭原则与配置驱动：评分维度、推荐规则、AI 供应商、敏感词均可通过管理端配置扩展，新能力以追加配置的方式接入。
• 领域模型与持久化分离：类图只画领域对象，类到表的映射由 2.1.7 统一说明。

2.1.7 类图与数据表映射

类图	核心类	主要对应表
3-2	用户、校园认证、组、角色、权限	user、campus_auth、user_group、role、permission 及各关联表
3-3	场景分类、点位、档口、菜品、标签	scene_category、canteen、location、station、dish、tag、dish_tag、business_info、map_location
3-4	评价、评分明细、图片、收藏、点赞、举报	review、rating_detail、review_image、review_tag、favorite、favorite_group、review_like、report、review_summary
3-5	打卡、手账、足迹、成就、宠物、金币	check_in、check_in_dish、journal、journal_image、footprint、achievement、user_achievement、pet、feed_record、coin_transaction
3-6	帖子、评论、审核、通知	post、review_reply、post_link、audit_record、notification、banned_word、operation_log
3-7	推荐、画像、计划、AI	recommendation、recommendation_item、recommendation_rule、taste_profile、diet_plan、diet_plan_item、ai_provider、ai_conversation、ai_chat_message

补充说明：

• 一个类可对应多张表，如评价类对应 review + review_image + rating_detail。
• 多态关联在数据库中落为 biz_type + biz_id，类图中不画关联类。
• 类方法是领域行为，具体事务、鉴权与聚合重算由服务模块执行；完整字段与索引见 1.2 和《数据库设计说明书》附录 B。

2.2 系统安全和权限设计

设计思路：

1. 身份与权限分离：令牌只证明身份，权限由服务端实时判定

• 项目约束：令牌有效期 7 天，管理员在有效期内可能被回收角色、禁言或封禁；令牌一旦签发，在客户端侧持续有效。
• 设计选择：JWT 载荷仅含用户 ID，鉴权中间件在每次受保护请求中实时查库，读取角色、账号状态、认证标识与组点位集合；权限缓存键 perm:user:{userId} 在角色、权限、组成员变更后立即失效。
• 作用：角色回收、禁言封禁、解绑认证在下一请求即生效，令牌有效期与权限时效各自独立。

2. RBAC 三来源授权：直接授权、角色授权、组授权统一到 perm_code

• 项目约束：系统同时面向普通用户、认证用户、档口负责人、数据维护人员和平台管理员；权限既来自岗位角色，也来自跨岗位的维护组与临时授权。
• 设计选择：用户总权限 = 用户直接授予 ∪ 角色权限 ∪ 组权限；组权限 = 组直接授予 ∪ 组角色；所有判定以 permission.code 为唯一标识。
• 作用：同一权限可以由三条路径获得，授权模型覆盖固定岗位与临时协作；撤销某一来源时，其余来源保持有效。

3. 权限与数据范围绑定：同一权限按 perm_code 解析 SELF / GROUP / ALL

• 项目约束：超级管理员查看评价列表需要全量，查看档口经营摘要只需要绑定档口；可见范围由本次操作决定。
• 设计选择：范围随授权路径落库——user_permission.scope 记录直接授权的 1 仅本人 / 2 组范围 / 3 全量，user_group.data_scope 记录组范围；角色作为权限模板，范围继承自组或直接授权；三类来源按 SELF ⊂ GROUP ⊂ ALL 取并集。
• 作用：同一账号在不同接口获得不同可见范围，数据范围与操作权限一一对应。

4. 默认安全：写接口默认 write_required，公开只读接口显式声明

• 项目约束：114 个 API 端点同时包含公开浏览、UGC 写入和后台管理；鉴权配置遗漏会直接暴露写能力。
• 设计选择：所有写接口默认 write_required，按业务叠加限流；公开只读接口显式声明 auth_optional；后台接口统一 admin_required；四级鉴权在接入层中间件完成。
• 作用：新增接口默认落在受保护一侧，公开范围由显式声明界定，便于逐项审查。

5. 纵深防御：接入层、服务层、数据库层分别设卡

• 项目约束：注入、越权、恶意上传、刷接口从不同入口进入系统，单点校验容易遗漏。
• 设计选择：接入层负责参数校验与限流，服务层负责资源归属与业务规则校验，数据访问层负责参数化 SQL、排序白名单与多态目标白名单，数据库层负责类型、非空、唯一键与外键兜底。
• 作用：每层承担各自擅长的校验，攻击面在多层收窄，单层失效时仍有后手。

6. 审计独立留痕：授权、撤销与失败尝试都可追溯

• 项目约束：评价复核、举报处理、角色变更、档口负责人绑定变更需要事后追责，失败尝试同样具有取证价值。
• 设计选择：operation_log 采用 append-only；撤销授权与日志在同一事务提交；失败尝试独立留痕、与业务事务分离；audit_record 仅允许服务层单一入口推进状态。
• 作用：成功操作与失败尝试都形成记录，审计链完整可查。

2.2.1 认证与会话

1. 登录链路： 登录接口为 POST /api/auth/login，限流 10 次/10 分钟。处理顺序为：校验图形验证码 → 按用户名查询用户 → bcrypt 比对口令 → 写入最近登录时间 → 签发 7 天 JWT。验证码错误、用户名或口令错误统一返回 422（40001），文案为“用户名或密码错误”；超出配额返回 429（42901）。

2. 令牌设计： 令牌通过 Authorization: Bearer <JWT> 请求头传递，载荷仅含用户 ID，签名密钥由环境变量注入。客户端在改密与退出时清除本地登录态；服务端吊销通过权限版本号或会话撤销记录实现。

3. 校园身份认证： 真实环境走 CAS-SSO：302 跳转 → ticket 回调 → 服务端校验；当前版本以模拟校园身份认证数据集演示。verified_user 角色仅由认证通过触发切换，管理员无法手工授予，认证服务与业务逻辑解耦。

4. 四级鉴权： 接入层中间件按端点的声明执行拦截，游客未携带令牌访问公开接口时按 guest 只读权限集放行。

级别	判定条件	典型端点
auth_optional	游客可读；携带令牌时补充用户上下文	点位列表、榜单、评价列表
auth_required	须登录，校验登录态与本人归属	个人资料、改密、AI 模型配置
write_required	须登录，且账号状态允许写入	评价发布、打卡、长帖、举报
admin_required	须管理员角色	/admin 子路由（44 个）

禁言与封禁对 write_required 接口返回 403（40302），公开读取与个人数据读取保持可用；改密、资料修改等账号安全类操作仅校验登录态与本人归属。

5. 账号枚举与验证码： 注册与登录均须图形验证码；登录（10 次/10 分钟）、注册（5 次/时）、校园认证换取令牌（10 次/10 分钟）各自独立限流。账号不存在与口令错误返回同一文案，避免通过错误信息探测账号是否存在。

2.2.2 权限模型（RBAC）

1. 表结构： RBAC 由四类主体表和七张关联表承载，另用 station_manager 记录档口负责人绑定。

表	职责
user	账号主体，记录账号状态与认证标识
role	角色，作为权限模板
permission	权限项，code 即 perm_code，grantable 标记可转授
user_role	用户—角色关联
role_permission	角色—权限关联
user_permission	用户直接授权，scope 记录数据范围，granted_by 记录授予人
user_group	维护组，data_scope 记录组范围
user_group_member	组成员
group_permission	组—权限关联
group_role	组—角色关联
user_group_location	组—点位覆盖，用于组范围解析
station_manager	档口负责人绑定，is_primary 标记主负责人

2. 权限公式

用户对某一权限的来源共三条：

用户总权限 = 用户直接授予 ∪ 角色权限（经 user_role）
           ∪ 组权限（经 user_group_member）
组权限     = 组直接授予 ∪ 角色权限（经 group_role）

3. 数据范围与操作绑定

授权范围按授权路径分别落库，各类路径的取值规则如下：

授权路径	承载表	范围字段	计算规则
用户直接授权	user_permission	scope	直接取该行范围：1 仅本人 / 2 组范围 / 3 全量
用户经角色	user_role → role → role_permission	继承	角色为权限模板，范围取自直接授权或组授权
用户经组 / 组角色	user_group_member → user_group → group_role → role_permission	data_scope	取该组范围；跨组取并集，任一组为 3 则整体为 3

三类来源按并集合并，SELF ⊂ GROUP ⊂ ALL，任一来源给出更大范围即以更大范围为准。scope = 1 落地为 user_id = 当前用户；scope = 2 按组覆盖点位解析；scope = 3 为全量。

4. GROUP 范围到点位集合

解析步骤如下：

1. 取用户所属的全部组 G₁…Gₙ（经 user_group_member）。
2. 对每个组，取经 group_role → role_permission 获得的 perm_code 集合。
3. 若某 perm_code 的组范围为 2，则可操作点位 = 组成员中任一方档口负责人（station_manager.is_primary = 1）所绑定的档口所属点位 ∪ 该组直接指派维护的点位。
4. 若该 perm_code 属于 station:manager:*，额外叠加 station_manager 绑定校验，只允许操作本人被绑定且 is_primary = 1 的档口。

同一用户属多组时点位集合取并集；同一点位被多组覆盖按同一 perm_code 合并，不做减法。移除 user_group_member 记录后，该组贡献的范围随即失效，下一次请求重新解析。

5. 转授规则： permission.grantable = 1 与超级管理员角色同时满足时允许转授，写入 user_permission 时 granted_by 记录当前操作者。“可再授权”记录在授权关系上，同一权限对普通持有者仅可使用，对超级管理员可再分配。

6. 生效与撤销： 权限缓存键为 perm:user:{userId}，角色、权限、组成员变更后立即删除。撤销事务在同一事务内完成三步：删除对应关联行 → 写一条 operation_log（记录被撤销的 perm_code 与授权双方）→ 提交；事务失败时关联行与日志一并回滚。撤销失败同样写 operation_log 并标记结果，该日志与业务事务分开提交。即使缓存清理失败，下一次请求实时查库仍会解析到已撤销的权限。

关联表	撤销方式	说明
user_role	受控 DELETE	撤销用户与角色的关联行
user_permission	受控 DELETE	撤销用户的直接授权行
user_group_member	受控 DELETE	移出组，该组贡献的数据范围失效
role_permission / group_permission / group_role	受控 DELETE	调整角色或组与权限的映射

7. 数据库账号分权

按最小权限原则划分四类账号：

账号类型	权限	说明
应用账号	业务表 SELECT / INSERT / UPDATE；授权关联表 DELETE	业务数据统一软删除，物理删除由运维账号执行
只读账号	全库 SELECT	用于报表、导出、数据分析
运维账号	DDL 与全表权限	仅 DBA 持有，密码由部署环境管理
审计账号	operation_log、audit_record SELECT	只读，记录由应用写入

2.2.3 行级与列级数据权限

1. 行级数据范围

按 perm_code 决定可见行，角色与范围对应关系如下：

角色	数据范围	效果
游客 / 普通用户	按资源区分	游客只读公开数据；普通用户可读写本人的评价、打卡、收藏
档口负责人	GROUP	只维护 station_manager 中绑定档口的数据
数据维护人员	GROUP	只维护所属组覆盖的点位
平台管理员	ALL	全量

2. 资源归属校验： 私有手账图与背景图仅本人可读，他人访问返回 404；公开评价图对所有人可见，头像公开；手账转社区草稿在发布时才按帖子规则生成公开访问。

3. 列级保护

敏感列的保护方式如下：

敏感列	保护方式
user.password_hash	查询层白名单排除，不进入任何 SELECT 列表与接口返回
ai_provider.api_key_ref / ai_model.api_key_cipher / ai_platform_model.api_key_cipher	仅后端服务读取，接口只返回掩码后 4 位
user.student_no	展示层脱敏为 2023000****，仅本人或管理员可见完整值
mock_identity_dataset.student_no / real_name	模拟数据集，仅用于认证比对，列表页统一脱敏

2.2.4 接口与输入安全

1. 威胁与对策

结合系统说明书 §8.4 与数据库说明书 §5.2，主要威胁的防御措施如下：

威胁	对策	落实位置
SQL 注入	全参数化查询；多态 biz_type 走白名单映射；排序字段白名单	数据访问层
越权访问	RBAC 关联表 + 按 perm_code 绑定数据范围；档口负责人叠加 station_manager 校验	接入层中间件
敏感数据泄露	展示层脱敏；学号、手机号中间位掩码	应用层
密码泄露	bcrypt 慢哈希（代价因子 10、自带盐）；改密校验旧口令	应用层
密钥泄露	api_key_cipher 存 AES-256-GCM 密文，主密钥由环境变量提供	应用层 + 表约束
上传恶意文件	文件类型、文件头与大小校验；上传频率限制；对象键归属校验	媒体服务
越权删除	逐表删除策略，操作前校验权限与资源归属	应用层
审计缺失	operation_log append-only，仅提供写入与检索	审计模块
拖库	分业务限流、异常访问告警、最小权限账号	接入层 + 数据库

2. SQL 注入防护： 全部 SQL 使用占位符绑定，业务代码统一通过参数数组传值。ORDER BY 无法参数化，前端传语义名（latest、hot），后端用常量映射（{latest: "created_at DESC", hot: "like_count DESC"}）生成排序子句。多态字段按业务表维护 biz_type → 目标表名 的白名单常量，biz_id 始终走占位符；assertBizExists 依次校验业务表名、对象类型编码、目标存在性与软删状态，任一不在白名单内直接返回 422。

3. XSS 与 CSRF： UGC 先经敏感词机审，替换级词打码后照常发布，人工级词转后台复核；前端渲染统一转义，图片以 URL 引用。令牌通过 Authorization 请求头传递，经典 CSRF 场景在令牌模式下不成立。

4. 恶意上传防护： 上传链路依次执行大小上限、文件头白名单（扩展名仅作参考）、dHash 感知哈希判重（与近 7 天上传池比对，汉明距离 ≤ 5 判为重复）、解码复核；upload_asset 以 UK(hash_dhash) 兜底。

5. 三层校验

层次	职责
接入层	assert / assert_str / page_int 工具族先行校验，非法输入返回 422
服务层	业务规则校验，如评价维度与就餐方式匹配、菜品归属档口
数据库层	类型、非空、唯一键、外键兜底

6. 分业务限流与降级

业务	配额	限流组件故障时的行为
评价发布	REVIEW_PER_H	转本地保守额度
点赞 / 收藏	VOTE_PER_H	转本地保守额度
AI 问答	AI_PER_H	转本地保守额度
文件上传	UPLOAD_PER_H	返回 503
举报	10 / 时	转本地保守额度
登录 / 注册 / SSO / 验证码	各独立配额	明确提示失败，验证状态不可读时按未通过处理
公开读取（点位、榜单、评价列表）	较宽松	直接放行

7. 降级原则： 读路径优先保障可用性，写路径优先保障安全，认证路径以严谨为先。

2.2.5 数据加密与隐私

1. 传输安全

项目	措施
外部传输	仅经 https://dafu-moment.zviolin.online/ 暴露，TLS 终结于 Nginx
后端端口	3000 仅容器内可达；对外入口为 frontend 容器的 8095
数据库端口	MySQL 容器端口不映射宿主机，仅 Docker 内部网络可达
连接加密	生产环境 MySQL 启用 require_secure_transport
对象存储	MinIO 私有桶，访问经后端图片代理端点转发

2. 口令： 口令以 bcrypt 落库，代价因子 10（约 250 ms/次），自带盐，库内不存在可逆口令信息；改密接口先校验旧口令。

3. 密钥： ai_provider.api_key_ref 存配置中心引用或 AES-256-GCM 密文，ai_model.api_key_cipher 与 ai_platform_model.api_key_cipher 存 AES-256-GCM 密文；主密钥（KEK）由环境变量注入，不落库、不落版本库；解密仅在调用供应商接口前于内存中执行，用后即弃；任何日志均不打印密钥明文或密文。

4. 隐私授权： privacy_setting 统一保存四类授权开关：饮食（diet_authorized）、行为分析（behavior_analysis_allowed）、通知、匹配。开关表达用途授权，资源可见范围另由归属校验与分享规则决定；浏览行为明细在线保留 90 天，撤回授权后停止新读取并使画像缓存失效。

5. 展示层脱敏

字段	库中存储	接口返回
user.student_no	完整学号	2023000****
user.nickname	完整昵称	完整昵称
mock_identity_dataset.real_name	真实姓名（模拟数据集联查）	张*
user.password_hash	bcrypt 串	不返回
api_key_cipher	AES-256-GCM 密文	仅后 4 位

2.2.6 审计与异常留痕

1. 审计范围： 评价复核处置、举报处理、点位 / 档口 / 菜品提交审核、用户禁言 / 封禁、角色变更、档口负责人绑定变更、AI 供应商配置变更。

2. 审计字段： operation_log 记录 operator_id（操作人）、action_type（动作）、biz_type + biz_id（对象）、result（结果）、content（内容）、reason（原因）、operated_at（操作时间）、created_at（落库时间）。授权类变更同时记录 user_permission.granted_by 与被修改主体。

约束	实现
operation_log 仅追加	应用账号只持有 INSERT 与 SELECT 权限，服务层只提供写入与检索入口
audit_record 受控推进	状态仅由服务层单一入口从“待审”推进到“通过 / 驳回”，每次变更另记一条 operation_log；驳回后重新提交以 resubmit_from_id 串成重提链
失败尝试独立留痕	失败操作同样写 operation_log 并标记结果，与业务事务分开提交
成功操作同样留痕	敏感管理操作独立于错误日志，成功与失败都记录
同事务落库	审核决定、结果通知与审计记录按顺序在同一事务提交

3. 检索权限： 审计记录仅管理员可按对象、操作人、时间检索；记录经只读接口查看，编辑入口统一关闭。

三、改进分析

3.1 针对上次需求分析作业的问题改进

上次评审老师、助教、其他队伍提出问题汇总：

1. 问题 1：以网站作为主要交付形态，与校园食堂点评的使用场景匹配度有限

评审意见：项目把网站作为主要呈现形式，而食堂点评的核心行为发生在移动场景中，网站形态的实用性需要进一步说明。

改进方案与改进过程：

• 确认产品形态：产品定位由“网站为主”调整为“移动端为主、Web 端为辅”。C 端以微信小程序与移动 App 为主要入口，Web 端承担两类职责：一是 /admin 管理后台，承载审核、举报处置、数据维护与权限配置；二是 H5 页面，用于扫码进入、分享查看与免安装浏览。
• 梳理场景依据：食堂场景集中在取餐与就餐的短时段内，用户在档口前完成扫码、拍照、定位与提交评价，移动端具备相机、定位、扫码与消息推送能力；打卡照片、评价配图、审核结果通知都依赖这些系统能力。使用频次高、单次时长短，小程序与 App 的入口路径更短，符合“到店即用、离店即走”的使用节奏。
• 落实技术方案：前端由 Vue 3 + Vite 单页应用承载 Web 端（管理后台与自适应 H5），uni-app 工程作为小程序、App 与 H5 的统一演进载体，两端共用同一套 REST API、鉴权中间件与 RBAC 权限模型。后端按“C 端移动接口 + /admin 管理接口”两类调用方组织路由，其中 /admin 子路由 44 个端点专供管理后台使用；C 端接口面向移动端，图片经 MinIO 上传并由后端代理转发。数据库沿用现有的 78 张表，端形态调整集中在接入层与展示层，数据模型保持一份。
• 同步文档与图：体系结构（1.1）把服务对象表述为“移动端师生与 /admin 管理端”，并在逻辑分层中标注 uni-app 多端载体；部署架构（图 2-1）以 frontend 容器作为统一的 Web 与 H5 入口；功能模块层次（图 2-3）按管理端与 C 端两组组织模块，点评、打卡、社区、AI 助手归入 C 端移动场景；数据流图（1.3）的外部实体按游客、C 端用户与各管理角色划分，与具体端形态解耦。
• 调整开发计划：本学期先交付 Web 端可运行版本，用于演示与评审；小程序与 App 在后续迭代中复用 uni-app 工程与现有接口，鉴权、权限与数据模型直接沿用，新增工作集中在页面适配与移动端系统能力接入。

改进结果： 产品形态调整为“移动优先、多端复用”，核心链路与使用场景的匹配度提升；Web 端保留管理后台与免安装浏览两类价值，评审关注的实用性问题在设计层面得到回应，后续迭代的端扩展成本也保持在可控范围。

3.2 LLM 协助完成设计的 3 个示例

三个示例分别对应系统架构、权限建模与数据建模，prompt 为实际粘贴给大模型的提示词节选，模型输出均经团队评审后写入设计文档。

1. 示例一：AI 助手模块的供应商路由方案（系统架构）

提问 prompt：

我们是 8 人团队开发校园美食评价平台（Node.js + Express + MySQL），需要一个 AI 助手模块：底层对接多家国内 LLM 供应商（协议各不相同），要求：1) 新增/停用供应商不改代码；2) 供应商故障时 AI 功能不能不可用；3) AI 回答只允许基于我们数据库里的真实点位与评价数据，禁止编造商铺。请给出该模块的架构设计方案，并说明落库表结构。

LLM 输出结果简述： 方案主线为“供应商注册表 + 协议分发 + 真实数据注入 + 失败降级”。供应商信息落库为 ai_provider 注册表，字段含 provider_key、name、protocol_type、base_url、api_key、enabled、sort_order，配套 ai_model 管理同一供应商下的多个模型；服务启动时执行 ensure_ai_providers() 播种缺省供应商；调用时按协议类型选择适配器，OpenAI 兼容协议走对话补全接口；检索阶段只从平台数据库取候选（上限 6 个、每候选摘录 2 条评价），调用失败时降级为基于真实评分的规则推荐。

我们如何使用 / 修改该结果： 采纳供应商注册表与协议分发，新增与停用供应商落在数据行上，发版范围随之收窄到协议适配层；采纳启动自愈播种，部署环境免去手工初始化 SQL；采纳候选数上限与“仅基于给定数据”的提示词约束，名称、价格与评分由平台数据回填。团队在此基础上补充密钥管理口径：api_key 改由 AES-256-GCM 密文承载，主密钥由环境变量注入，接口只返回掩码后 4 位。模型提出的向量库语义检索与消息队列异步生成两案，团队评估后纳入后续迭代，本期以关键词加规则检索满足数百级点位规模，2 核 2G 单机部署保持轻量。

2. 示例二：RBAC 按钮级权限模型（权限与类图）

提问 prompt：

我在做一个校园食堂服务平台「大福食刻」，后台管理涉及一区食堂、三区食堂、学生街、小摊、私厨、永嘉六个点位的点位/档口/菜品信息维护。请帮我设计一套基于 Spring Security 的 RBAC 权限模型，要求：

1. 权限粒度到按钮级（如「新增档口」「删除菜品」各自独立为一条权限）；
2. 不同维护员只能操作自己负责的点位的行级数据；
3. 给出核心表结构（表名、关键字段、表间关系）。
   约束：系统没有商家角色，管理端只有超级管理员、平台管理员、点位信息维护员。

LLM 输出结果简述： 模型给出经典 RBAC 四对象模型（用户、角色、权限、权限组），包含用户—角色、角色—权限、用户—权限组、权限组—权限四张关联表；权限以“资源 + 操作”两列编码（如 stall:add、dish:delete）实现按钮级控制；行级数据权限以数据范围字段承载，通过权限组绑定点位维度过滤；另建议预留审计员、临时访客等扩展角色与菜单表、租户表。

我们如何使用 / 修改该结果： 采纳 RBAC 四对象框架、“资源 + 操作”的权限编码与组承载行级范围的思路，落到 2.2 的 12 张表：permission.code 即 perm_code，user_permission.scope 与 user_group.data_scope 记录数据范围，范围取 SELF / GROUP / ALL 三档。结合项目实际做了三处调整：权限组按六个点位划分，超级管理员持有全量权限并独立于维护组；角色拆为用户线（游客、注册用户、校内已认证用户）与管理线（超级管理员、平台管理员、点位信息维护员），管理线继承用户线全部 C 端权限，这层继承由团队补充；用户总权限明确为“直接授权 ∪ 角色权限 ∪ 组权限”的计算式并写入设计文档。团队评审后按本期业务范围收敛表结构，保留 12 张表覆盖角色、权限、组授权与档口负责人绑定，扩展角色、菜单表与租户表进入后续迭代评估。

3. 示例三：评价功能的数据粒度与表结构（数据库设计）

提问 prompt：

为校园餐饮点评设计评分体系，要求同时满足：1）列表页 O (1) 读平均分与评分人数；2）堂食 / 打包 / 外送可评的维度不同；3）违规下架后不计入评分但记录保留可申诉。对此三种方案：① 只存明细、实时聚合；② 一评价一汇总；③ 按对象 × 维度汇总。说明各自的键设计，并指出每种方案的致命缺陷（不是 "缺点"，是 "会死在哪"）。给出待审（status=2）是否参与聚合的结论，以及汇总行的重算时机。构造反例：多维打分、下架后平均分未变、待审评价被计入。

LLM 输出结果简述： 模型给出“评价表 + 评分维度表”一对多结构：评价表存用户、文本与图片，评分维度表存维度名与分值；建议评价时可自由关联点位、档口或菜品任意层级；同时建议为菜品单独维护一份聚合评分缓存表。

我们如何使用 / 修改该结果： 采纳评价主表与评分维度子表的一对多结构，多维评分拆行存储，便于按维度统计。评价粒度由团队拍板为“只评档口”：评价必选关联档口，菜品作为可选项，由此评价对象唯一、统计口径一致；同时补充两条归属校验——选了菜品时校验菜品属于该档口、档口属于所选点位。另外增加就餐方式字段（堂食、打包、外送），由就餐方式决定可见评分维度的适用矩阵，对应 review_dimension_meal_mode 表；聚合评分落 review_summary，以“对象 × 维度”为聚合粒度，同一套结构覆盖点位、档口、菜品三类对象，表结构与约束见 1.2 与数据库说明书 §3.3、§4.5。

四、团队绩效

团队共 8 名成员，课程表与空闲时段存在差异。为保证设计作业在有限周期内完成，团队采用“线上例会为主、线下集中为辅、群内异步留痕”的协作方式：需要当面讨论的架构图、ER 图与版式问题放到线下集中处理，日常进度同步与逐页评审放到腾讯会议，省去往返路程并留存会议录屏，日常进度与文件流转留在群内并形成记录。整个过程按六个阶段推进，每个阶段都有明确的主责人、产出物与检查点，会议、文档与仓库三条线共同保证过程可追溯。

4.1 本次作业整体工作流程

4.1.1 团队组建与分工方案的形成

1. 启动会：对齐目标与评分点： 作业发布后，团队在教室召开线下启动会，对照作业要求逐条拆解评分点，明确体系结构、数据库设计、类图与安全、改进分析、团队绩效、开发计划六个部分的交付要求；会上确定最终交付物为《系统设计说明书》《数据库设计说明书》、答辩 PPT 与博客四件套，并按“图、文档、博客、PPT、仓库”五条产出线倒排节点。

2. 分工草案：先拆产出线，再落到人： 组长在会前按产出线整理分工草案，腾讯会议上共享屏幕逐条说明任务边界、前后依赖与截止时间。草案把两份说明书拆到章节，把图拆到单张，把博客拆到小节，把 PPT 拆到页，成员可以直接看到自己负责的具体对象，讨论时围绕具体条目展开。

3. 性格与能力匹配：把合适的人放到合适的位置： 分工讨论围绕“谁适合做什么”展开，团队结合平时课程作业中的表现，对每位成员的性格特点与能力特长做了梳理，再据此匹配任务：

• 林青妍性格外向、沟通协调能力突出，适合统筹进度、对外沟通与现场表达，承担组长、进度把控、终审与答辩主讲；
• 张伟林架构思维清晰、文档表达完整，适合搭框架、写长文，承担系统设计说明书主笔与架构图、模块层次图；
• 王一帆逻辑严谨、熟悉 UML 与权限模型，适合结构化建模，承担类图、RBAC 模型与数据流图优化；
• 郭洁颖数据库基础扎实、做事耐心细致，适合处理大量表结构与字段，承担 ER 图与 78 张表结构设计；
• 郑春天对视觉与排版敏感、表达清晰，适合呈现类工作，承担答辩 PPT、评审打分表与问答素材；
• 邱语堂细致、执行力强，适合校对与查漏补缺，承担交叉评审、格式统一与多轮校对；
• 方韵希文字组织与进度推动能力较强，适合写长文、盯节点，承担博客主笔、计划表与进度提醒；
• 杨雨薇规范意识强、熟悉仓库与文档管理，适合流程与归档，承担数据库说明书文字章节、仓库管理与 commit 核查。

4. 认领与调整：会上认领、会后留痕： 成员按“主责一项、协作一项”认领任务，会上有异议当场提出，会后 24 小时内仍可在群内申请调整；分工表经全员确认后以群公告形式固定，后续变更同样通过群公告同步。关键产出设置互审关系：架构与类图互审、ER 图与表结构互审、博客与 PPT 素材互查，单项任务延误时由互审人接续处理，整体节点保持可控。

4.1.2 六阶段工作流程

六个阶段的协作方式、参与人、产出与检查点如下表，图、文档、博客与 PPT 共用同一批素材：A、B、C 先交出图与文档初稿，E 统一校对格式与编号，F 据此撰写博客，D 再用同一批素材制作答辩 PPT，组长与 G 完成终审、归档与提交。

成员编号与姓名对应如下：A 张伟林、B 王一帆、C 郭洁颖、D 郑春天、E 邱语堂、F 方韵希、G 杨雨薇，组长为林青妍。

阶段	协作方式	参与人	主要产出	检查点
① 任务拆解与分工	线下启动会 + 腾讯会议	组长主持，全员参与	任务清单、分工表、交付节点	每项产出有唯一主责人，节点可核对
② 并行产出	群内日报 + 每两日腾讯会议	A、B、C、G	系统设计说明书初稿、UML 类图与 RBAC 模型、ER 图与表结构、数据库说明书文字章节、华为云仓库	图文初稿齐全，图表编号与字段口径初步统一
③ 交叉评审与校对	腾讯会议逐页评审 + 线下集中修改	E 主责，A/B/C 配合	格式统一、图表编号与术语核对、修改意见清单	意见逐条闭环，修订稿回传作者确认
④ 博客整合	共享素材库 + 群内确认	F 主责	博客全文、周开发计划表、组员分工表、LLM 案例素材	博客数字与说明书一致，图表引用可访问
⑤ 终审与提交	线下终审会 + 线上复核	组长、G	文档与博客终审、commit 核查、文件归档、链接校验	全员 commit 可追溯，链接与附件可打开
⑥ 答辩准备	线下预演 + 腾讯会议复盘	D 主责，组长主讲	答辩 PPT、评审打分表、问答素材、预演计时	演示流程一次走通，计时符合要求

1. 阶段一：任务拆解与分工： 组长主持线下启动会，说明作业要求与评分点，随后在腾讯会议上过一遍分工草案。会上确认每人一项主责与一项协作，明确交付节点与互审关系，会后形成任务清单与分工表发群。

2. 阶段二：并行产出： A 负责系统设计说明书与架构、模块层次图，B 负责 UML 类图、RBAC 模型与数据流图优化，C 负责 ER 图与全部表结构，G 负责数据库说明书文字章节与仓库搭建。成员在群内按日报同步进度，每两日开一次腾讯会议对齐口径，遇到跨模块问题当场确定处理人。

3. 阶段三：交叉评审与校对： E 通读两份说明书，统一格式、图表编号、图注与术语，输出修改意见清单；A、B、C 按清单逐条修订并在群内回复处理结果。评审以腾讯会议逐页过图为主，版式与图表排布问题放到线下集中修改，经过多轮迭代后定稿。

4. 阶段四：博客整合： F 收集图、表、端点数量与 LLM 案例素材，按文档结构撰写博客，同步制作周开发计划表与组员分工表；D、G 提供 PPT 素材与仓库链接；F 在群内发布进度提醒，组长审核博客内容与口径。

5. 阶段五：终审与提交： 组长与 G 召开线下终审会，检查文档版式、图表编号、术语、数字口径、链接与附件；G 核查全员 commit 覆盖情况，完成文件归档与博客链接校验；确认版本冻结后提交课程仓库与博客平台。

6. 阶段六：答辩准备： D 整合全部图表素材制作答辩 PPT，整理评审打分表与问答素材，完成排版自查；组长确定主讲思路，团队在线下按正式流程预演并计时，腾讯会议复盘问答表现，答辩现场由组长主讲。

协作机制包含三项安排：

1. 分工调整、进度同步与贡献度确认经群通知留痕，全员可查。
2. 交付流转链路为：A、B、C 产出图与文档初稿 → E 交叉评审校对 → F 收集素材并撰写博客 → 组长与 G 完成终审、归档与 commit 核查 → D 取用素材制作答辩 PPT → 组长整体把关并上台答辩。
3. 版本记录以华为云仓库为准，每位成员按负责内容 commit，评审时可按人追溯修改历史。

4.1.3 会议与沟通机制

1. 线下会议：集中处理需要当面讨论的内容： 启动会确定分工方案；阶段定稿会把架构图、ER 图铺开逐张核对；终审会集中检查文档版式、编号与附件；答辩预演在教室按正式流程走一遍并计时。线下会议安排在成员共同的空课时间，地点以教室与食堂为主。

2. 腾讯会议：日常同步与逐页评审： 腾讯会议省去往返路程，晚上与周末的线上会议成为常态，会议录屏留存也便于成员随时回看。启动阶段用腾讯会议复盘分工草案，产出阶段每两日开一次短会同步进度，评审阶段共享屏幕逐页过图与文档，答辩阶段用于问答演练与复盘。

3. 群内异步：日报、公告与文件流转： 每日晚间成员在群里按“今日完成、明日计划、需要协助”三栏同步，组长汇总后更新任务表；群公告承担分工调整、版本冻结、提交提醒三类通知；文件按“说明书 / 图 / 博客 / PPT / 素材”分类存放，命名带版本号与日期。

4. 会议规则：有议程、有结论、有回看： 会前一天发出议程与材料，成员提前阅读；会中按议题逐项推进，结论当场确认；会后由记录人整理“结论、待办、责任人、截止时间”发群，下一次会议的第一项固定回顾上次待办，形成闭环。

4.1.4 版本管理与质量保障

1. 仓库与 commit： 华为云团队仓库按交付物建立目录，README 写明目录结构与提交说明；每位成员按负责内容 commit，提交信息注明“部分 + 动作”，评审时可按人追溯修改历史；G 定期核查 commit 覆盖情况，组长在终审阶段做一次全员核查。

2. 三审机制： 第一审由作者自检，对照评分点与作业要求逐条核对；第二审由 E 组织交叉评审，输出修改意见清单并回传作者修订；第三审由组长与 F 完成终审，检查格式、编号、术语、链接与附件。三轮评审的修改意见均保留清单，便于复盘。

3. 一致性核对： 博客、说明书与 PPT 共用一批数字与图号，表数、端点数、模块数、图号在三处交叉核对；图片链接在导出 PDF 后逐张点开检查；术语表在文档开头统一，同一对象在三处使用同一叫法。

4. 风险应对： 进度风险通过日报与节点倒排提前暴露，任务延误时由互审人补位并在群内调整分工；质量风险通过交叉评审与多轮校对收敛；成员时间冲突通过任务拆分与线上会议降低影响，关键节点前安排一次线下集中冲刺。

4.2 组员分工与贡献度

4.2.1 分工原则

1. 产出线闭环： 五条产出线各有唯一主责人，从初稿到终稿由同一人跟进。主责人负责需求澄清、内容编写、评审修订与最终定稿，评审节点集中交接，后续修改仍由主责人确认，责任边界清晰。

2. 能力与任务匹配： 分工结合课程基础、工具熟练度与表达特点。建模能力强、逻辑严谨的成员承担架构、UML 与数据库设计；文字表达完整的成员承担说明书与博客长文；审美与排版见长的成员承担 PPT 与视觉呈现；沟通协调能力强的成员承担统筹、进度与答辩主讲。

3. 主责与协作并行： 每人一项主责加一项协作。主责保证投入深度，协作参与评审、提供素材并在关键节点补位；互审关系覆盖架构与类图、ER 图与表结构、博客与 PPT，单人时间冲突时由互审人接续。

4. 过程可追溯： 分工表、会议纪要、评审意见清单与 commit 记录共同构成过程证据。每个交付物可以定位作者、评审人与修改时间，贡献度核定、答辩素材取用与后续复盘使用同一套记录。

5. 负载均衡与节点控制： 任务量按文档页数、图幅数量、表结构与端点规模估算，主责任务之外预留协作与评审时间；关键节点前安排集中冲刺，任务延误在例会上调整并由互审人补位，整体进度保持稳定。

4.2.2 分工明细

分工明细按学号顺序排列，角色一栏保留分工编号与职能，工作内容一栏列出可以核查的具体产出。表格经启动会认领、会后调整与全员确认后定稿，作为评审分工、贡献度核定与答辩材料取用的共同依据。

学号姓名	分工编号与角色	工作内容	贡献度
102400104 林青妍	组长	答辩主讲；整体项目统筹；全部文档与 PPT 终审；汇总 LLM 案例；协调解决项目问题；审核博客内容	13%
102400232 张伟林	A	《系统设计说明书》主笔；系统架构、模块层次图、接口设计、安全健壮性、需求改进内容；LLM 案例 1（系统架构）	13%
102400207 王一帆	B	UML 设计类图、RBAC 权限模型；优化数据流图与泳道图；撰写对应设计文字并入系统设计文档；LLM 案例 2（UML 建模）	13%
102400301 郭洁颖	C	数据库核心建模：识别业务实体、绘制 ER 图、设计全部数据表结构，确定字段、主键外键与索引；LLM 案例 3（数据库设计）	12%
102400209 郑春天	D	答辩 PPT 制作；整合全部图表素材；制作评审打分表；整理答辩问答素材；PPT 排版自查与预演计时	12%
102400124 邱语堂	E	通读两份设计说明书；统一全文格式、图表编号、图注与术语；文档交叉评审并输出修改意见清单；多轮迭代校对；导出 PDF 检查图片链接	12%
102400102 方韵希	F	博客全文主笔；制作周开发计划表与组员分工表；跟进项目进度并在群内发布提醒；收集整理全部素材与 LLM 案例，供博客和 PPT 使用	13%
102400208 杨雨薇	G	撰写数据库说明书文字章节（引言、范式分析、数据库安全、附录）；华为云仓库搭建、目录管理、README 编写、全员 commit 核查、文件归档、博客链接校验	12%

分工说明： 文档线由 A 主笔系统设计说明书、G 撰写数据库说明书文字章节，B、C 分别提供类图与数据模型内容；图线由 A 负责架构与模块层次图、B 负责 UML 类图与 RBAC 模型、C 负责 ER 图与表结构；博客线由 F 主笔，D、G 提供素材与链接校验；PPT 线由 D 主责，组长主讲；仓库线由 G 管理，全员按负责内容 commit。五条产出线在评审节点汇总：A、B、C 的图表先经 D 统一素材，再由 E 校对图号与术语，最后由组长终审定稿；F 的博客内容取自各线产出，数据与图号在发布前与说明书逐项核对。

4.2.3 贡献度核定

1. 核定依据： 贡献度按任务技术难度、工作量与持续投入时长三项综合评估。技术难度看任务对专业能力的要求与出错后的返工成本，工作量看文档页数、图幅数量、表结构与端点规模，持续投入时长看成员从启动到提交的参与周期。核定材料包括华为云仓库的 commit 记录、各阶段产出清单、交叉评审意见条数、会议参与情况与纪要中的待办完成情况；流程上先由个人自评，再由组长汇总，最后经全员商议排序。

2. 核心产出与统筹岗位取 13%： 组长承担统筹、终审与答辩主讲，A 承担《系统设计说明书》主笔与系统架构，B 承担 UML 建模与 RBAC 权限模型，F 承担博客主笔，四人均为 13%。这些岗位对应交付物的主体内容：系统设计说明书、类图与权限模型、博客全文，并贯穿设计、评审与答辩全过程，因此取最高档。

3. 数据库建模与支撑工作取 12%： C 承担数据库核心建模，识别业务实体、绘制 ER 图并设计 78 张表结构，工作集中在数据模型阶段；D 负责答辩 PPT 制作、图表素材整合与问答素材整理，投入集中在交付前的高强度阶段；E 负责两份说明书的格式统一、图表编号、交叉评审与多轮校对，工作贯穿文档定稿全过程；G 负责数据库说明书文字章节与华为云仓库管理，覆盖仓库搭建、目录维护、commit 核查与归档。四个岗位均为交付质量与提交合规提供保障，取 12%。

4. 档位差异与分布校验： 13% 与 12% 两档相差 1 个百分点，差异对应岗位对交付物主体内容的直接责任范围：13% 岗位承担说明书正文、类图与权限模型、博客全文等主体产出，12% 岗位承担数据库建模、演示材料、校对与仓库事务。档位经过两轮讨论确定，先按任务清单初排，再结合 commit 记录与评审意见条数微调，最终形成 13% × 4 + 12% × 4 = 100% 的分布，最高与最低相差 1 个百分点。核定结果在群内公示，成员可在公示期内提出复核，确认后的版本作为课程提交与组内绩效记录的最终依据。

说明：每个人都需要在华为云仓库进行 commit 提交，记录版本。

五、开发计划安排

5.1 预期开发计划时间安排（按周，包含 11 月中下旬冲刺阶段）

开发计划以本次设计形成的体系结构、数据模型与接口清单为基线，按周排期（2026-09-29—2026-11-30），设置 P1—P6 六个里程碑。排期遵循三条原则：

1. 核心链路优先： 第 4 周交付“浏览—搜索—详情—评价—收藏”闭环，第 5 周叠加对比、导览、打卡、手账、社区与通知，第 6 周加入 AI 饮食计划、宠物与分享；每个阶段预留联调与修复时间，主流程在每个里程碑都可演示。

2. 依赖先行： 设计阶段形成的五层架构、78 张表、114 个端点与 RBAC 模型作为开发输入，接口文档、字段命名、错误码与权限要求在编码前冻结；接口变更走评审，前后端同步更新，联调阶段按契约逐项核对。

3. 节点可验收： 每个里程碑配交付物、完成标准与验收记录，节点评审由组长主持，测试与文档负责人参与；验收项逐条核对，待办项进入下一阶段并跟踪关闭，验收结果作为下一节点排期的依据。

排期同时考虑课程周次与成员课表，开发任务按模块拆分到人，联调、测试与材料整理集中在里程碑前；冲刺阶段以多端适配、验收与答辩为主，扩展功能按优先级排序，资源紧张时优先保障核心链路与已承诺的交付物。

前四段对应本学期已排定的里程碑，覆盖需求、核心点评、联调与最终版本；后两段为 11 月中下旬冲刺，用于多端适配、验收与答辩准备。

周次	时间	主要任务	里程碑与交付物	完成标准
第 1—3 周	2026-09-29—2026-10-15	梳理用户场景与需求分级，形成领域类图、界面原型与交互设计，整理功能描述与验收对照，准备答辩材料；10 月 13 日整理本次材料，10 月 15 日提交作业，10 月 16 日原型答辩	P1：需求规格说明书、界面原型、需求分析 PPT、原型答辩 PPT、课程博客	用户场景、功能、页面与验收要求逐条对应；完成组内评审，材料定稿并提交
第 4 周	2026-10-16—2026-10-22	完成分类浏览、搜索筛选、详情、多维评价、评价互动、收藏、登录认证、基础数据管理及审核举报处理	P2：核心点评版本与接口文档	游客可浏览，用户可查找并收藏对象、发布评价和参与互动；评分按场景展示，管理员可维护基础资料并处理审核举报
第 5 周	2026-10-23—2026-10-26	完成横向对比、档口导览图、内容共建、一体化打卡、日历足迹、基础手账、头衔成就、规则化推荐与画像、社区长帖和通知中心	P3：联调版本与阶段测试记录	多功能读取统一的点位与菜品数据、饮食档案；一次打卡联动日历、足迹和成就；内容提交、审核与通知衔接；个人记录权限一致
第 6 周	2026-10-27—2026-10-30	推进 AI 与规则结合的食物计划、智能饮食推荐、虚拟宠物与装扮、手账编辑、H5 预览与分享等扩展内容；结合隐私与举报机制安排饭搭子匹配；集中测试、修复并整理交付材料	P4：最终版本、验收记录、用户说明与演示材料	按需求追踪表核对已纳入交付的功能与验收项，完成主流程及异常流程检查，问题修复复测，统一代码、文档与演示材料版本
第 7—8 周（11 月冲刺）	2026-11-01—2026-11-15	移动端适配：uni-app 工程承接小程序与 App 页面迁移，复用现有 REST API、鉴权中间件与 RBAC 权限模型；补充移动端相机、定位、扫码与消息推送能力接入；开展性能优化与安全加固复查	P5：多端适配版本与适配说明	小程序与 App 核心链路可用，与 Web 端共用同一套接口与数据模型；写接口鉴权与数据范围校验保持一致
第 9—10 周（11 月冲刺）	2026-11-16—2026-11-30	全流程验收与缺陷收敛；部署演练与环境复核；答辩材料定稿、预演计时与演示数据准备	P6：交付版本、部署手册与答辩材料	演示环境稳定可复现，代码、文档与演示材料版本一致，主流程演示一次通过

4. 前四段：核心功能逐步成形： 第 1—3 周完成需求分级、领域类图与界面原型，交付 P1；第 4 周集中完成浏览、搜索、多维评价、收藏、登录认证与基础数据管理，交付可运行的核心点评版本 P2；第 5 周补齐横向对比、导览图、内容共建、一体化打卡、手账、推荐与通知，交付联调版本 P3；第 6 周推进 AI 饮食计划、虚拟宠物、手账编辑与 H5 分享，完成集中测试与修复，交付最终版本 P4。

5. 后两段：多端适配与交付验收： 第 7—8 周由 uni-app 承接小程序与 App 页面迁移，复用现有接口、鉴权中间件与 RBAC 模型，补齐相机、定位、扫码与消息推送能力，交付 P5；第 9—10 周完成全流程验收、部署演练、缺陷收敛与答辩材料定稿，形成 P6 交付版本。

6. 里程碑衔接： 上一阶段的交付物作为下一阶段的输入，P2 的接口文档冻结后 P3 按模块并行开发，P3 的联调记录作为 P4 修复依据，P4 版本冻结后进入多端适配，P5 的适配说明纳入 P6 的验收清单。

7. 计划调整机制： 每周例会核对进度与风险，里程碑出现延期时优先保障核心链路，扩展功能顺延到后续迭代；计划调整经组长确认后在群内公告，并同步更新本节计划表。

5.2 预期开发计划分工安排（到人）

本节分工面向整个项目的后续开发，与第四部分本次设计作业的阶段分工相互独立。项目按“需求与产品、后端、前端、测试与验收、文档与汇报”五类职能组织，每名成员承担一至两项职能，并在具体模块上担任负责人。开发采用迭代方式：每个迭代先确认接口与数据口径，再并行编码，迭代末统一联调、测试与演示；模块负责人对本模块的接口、页面、测试与文档负责，跨模块问题由组长协调，关键模块配置互审人。

学号姓名	角色	负责详细开发部分
102400102 方韵希	需求分析与文档、类图与数据模型、后端开发、测试与验收	需求规格说明书的领域类图与数据要求部分；后端接口开发、系统测试与验收
102400104 林青妍	项目统筹与组长、需求分析与文档、后端开发	项目整体统筹、进度把控与对外沟通，组织会议与任务拆分；后端接口设计、业务逻辑、数据库实现与维护；需求规格说明书撰写与评审
102400124 邱语堂	PPT 与博客、后端开发	博客撰写与排版、文档汇总与材料上传；部分业务接口实现、数据库表结构设计、前后端联调与问题修复
102400207 王一帆	产品设计与界面原型、后端开发、测试与验收	原型与需求文档审核、接口与数据库设计编写；业务代码编写与联调修复；系统功能测试、缺陷跟踪与回归测试、代码规范核对
102400208 杨雨薇	产品设计与界面原型、PPT 与博客	产品业务流程与界面原型思路梳理；项目选题汇报 PPT 与设计阶段汇报 PPT 的制作与迭代
102400209 郑春天	需求分析与文档、产品设计与界面原型、前端开发、测试与验收、PPT 与博客	需求分析与文档整理；产品界面原型设计；前端页面开发与样式调试、测试验收；项目汇报 PPT 制作
102400232 张伟林	后端开发、产品设计与界面原型、前端开发	后端架构与核心功能实现；原型设计与前端开发、素材处理流水线与可交互原型产出
102400301 郭洁颖	产品设计与界面原型	产品界面与交互设计，页面结构、信息层级与交互流程设计，界面原型与视觉规范输出，参与原型评审与版本迭代

1. 迭代节奏与版本管理： 项目按两周一个迭代推进，与 P2—P6 里程碑对齐。迭代开始明确范围、冻结接口与数据口径，中期安排一次联调，结束交付可运行版本并现场演示；版本在华为云仓库打标签，主干保持可运行状态，演示版本与提交版本一一对应，迭代回顾记录改进项并纳入下一轮。

2. 开发规范与代码评审： 后端按接入层、业务服务层、数据访问层分层，SQL 统一放在数据访问层；前端按页面与组件拆分，接口调用集中封装；命名、错误码与权限注解按设计文档统一。提交前完成自测，关键模块由互审人做代码评审，合并后由模块负责人执行回归。

3. 测试与缺陷管理： 单元测试覆盖评分聚合、权限判定等核心逻辑，接口测试覆盖 114 个端点的主流程与异常分支，端到端测试覆盖登录、评价、打卡、审核等链路；缺陷统一登记、分级、指派与复测，每轮迭代结束执行回归，遗留问题在评审会上确认处理计划。

4. 部署与运行保障： 按 Docker Compose 六容器部署，密钥与连接串通过环境变量注入；上线前完成健康检查、数据初始化与回滚演练，部署步骤写入手册；运行期保留日志与操作审计，定期备份 MySQL 与 MinIO 数据，容量按访问量调整。

5. 文档与知识沉淀： 接口文档、表结构说明与部署手册随版本更新；每个迭代记录设计决策、接口变更与问题清单，关键模块补充开发说明；答辩与结项时汇总为项目文档，供后续维护与交接使用。

6. 沟通与风险控制： 每周例会同步进度，迭代评审会确认交付范围；关键路径任务提前排期，人员时间冲突时由互审人接续；风险项登记后在例会跟踪到关闭，范围变更经组长确认并同步全员。

六、小结

6.1 本次设计完成情况

1. 体系结构：
本次设计形成客户端层、接入层、业务服务层、数据访问层、数据存储层五层逻辑架构，层间单向依赖，高德地图、LLM、校园身份认证与抠图服务以侧接方式接入。部署方案以 Docker Compose 编排 frontend、backend、mysql、redis、minio、matting 六个容器，按健康检查顺序启动，整体承载于 2 核 2G 轻量服务器。功能按前台用户端、管理端、公共支撑三大板块划分为 15 个模块，后端对应 114 个 API 端点，其中 /admin 子路由 44 个。

2. 数据模型：
数据库按 D1 用户与身份、D2 餐饮基础数据、D3 点评与互动、D4 打卡与成长、D5 社区与内容治理、D6 推荐与 AI 助手六个数据域组织 78 张表，含 545 个实际列、106 条物理外键、7 组核心唯一键、16 项 CHECK 约束与 12 条热点复合索引。概念层输出总览图 C-0 与分域图 C-1—C-6 共 7 张，图面合计 88 个实体、88 个联系，按名称去重后 69 种业务对象；逻辑层与物理层分别落到字段、键约束与索引设计，建表脚本与列注释收入数据库说明书附录。

3. 行为模型：
数据流图共 12 张：顶层图 P0 界定系统与 E1—E7 七个外部实体；一层图拆为身份与浏览、内容生产、个性化、社区与通知、治理与管理五张分图，覆盖 P1—P8 八个加工与 D1—D11 十一个数据存储；二层图细化登录认证、写评价、一体化打卡、AI 推荐、内容共建与举报处置六条核心链路。父图与子图按编号平衡，先发后审、隐私授权、服务降级等业务约束落在加工判定与数据流路径上。

4. 类图与安全：
设计类图覆盖领域总览与分模块视图，核心业务类、类间关系与映射表逐项说明。安全方案形成 12 张 RBAC 表，支持直接授权、角色授权、组授权三条来源并在 perm_code 上统一判定，数据范围取 SELF / GROUP / ALL 三档；接入层落实四级鉴权、限流与参数校验，敏感字段与 AI 密钥以密文入库，operation_log 与 audit_record 对成功操作和失败尝试分别留痕。

5. 过程材料与计划：
第三部分针对上次需求分析作业的评审意见完成改进分析，产品形态调整为“移动优先、多端复用”，并记录 3 个 LLM 协助设计案例的提示词、模型输出与团队修改；第四部分梳理六个阶段的工作流程与 8 名成员的贡献度；第五部分按 P1—P6 排出周开发计划与到人分工，覆盖 11 月中下旬多端适配与验收冲刺。

6. 交付物：
本次作业交付《系统设计说明书》《数据库设计说明书》、系统设计与数据库设计答辩 PPT 与本篇博客，图、文档、博客与 PPT 共用同一批素材，版本记录以华为云团队仓库为准。

6.2 现存待解决问题

1. 认证切换：
当前以模拟校园身份认证支撑演示，真实 CAS-SSO 的 302 跳转、ticket 回调与服务端校验需要在开发阶段完成联调，真实学号数据集的接入方案同步确定。

2. 外部依赖验证：
LLM、高德地图与抠图服务目前按接口契约与降级链路完成设计，真实网络环境、调用配额与故障注入下的稳定性需要在联调阶段验证。

3. AI 检索能力：
本期 AI 助手采用关键词加规则检索，满足数百级点位规模；向量语义检索与消息队列异步生成已纳入迭代评估，模型调用成本与响应时延需要在真实数据量下复核。

4. 容量与性能：
现有容量结论基于日活约 2 万、评价日增约 2000 行、一年约 73 万行的估算，压测数据与慢查询实测记录待补充，分区方案按数据增长情况再评估。

5. 多端落地：
小程序与 App 的登录态、相机、定位、扫码与消息推送适配排在 11 月冲刺阶段，微信侧资质申请与审核流程需要与开发进度并行推进。

6. 文档收尾：
博客中的华为云团队仓库地址、系统设计说明书、数据库设计说明书与答辩 PPT 的下载链接待填写；系统设计说明书图 2-10 待补入博客对应位置，全文图号、术语与页码在提交前统一核对。

6.3 后续完善计划

1. 开发推进：
按第 4—6 周依次交付核心点评版本、联调版本与最终版本，逐项对齐 P2—P4 的完成标准，评价、打卡、收藏、审核与通知等主流程连同异常流程一并测试。

2. 多端适配：
第 7—8 周由 uni-app 工程承接小程序与 App 页面迁移，复用现有 REST API、鉴权中间件与 RBAC 权限模型，新增工作集中在移动端系统能力接入与页面适配。

3. 验收与答辩：
第 9—10 周完成全流程验收、部署演练、缺陷收敛、演示数据准备与答辩预演，保证演示环境稳定可复现，代码、文档与演示材料版本一致。

4. 文档同步：
接口、表结构与图随开发变更回写两份说明书，权限模型、索引清单与端点数量在每次迭代后复核，保持文档、代码与博客三方口径一致。

5. 安全复查：
验收阶段对密钥轮换、隐私授权撤回、审计检索权限与数据范围过滤做一次专项复核，写接口的鉴权配置与限流参数逐项检查。

6.4 结语

本次概要设计与数据库设计完成了从体系结构、功能模块、数据模型、行为模型到类图与安全权限的完整设计链路，78 张表、114 个端点与四级鉴权共同构成后续开发的统一基线。设计过程中形成的图表编号、字段命名与权限编码规范，可以直接复用到编码、测试与文档维护环节。现存问题已明确责任范围与时间节点，将随 P2—P6 里程碑逐项收敛；团队按既定分工推进开发，在答辩前完成可运行版本、部署手册与演示材料的交付。