为什么软件工程毕设可以采用“母版 + 模块组合”？
预约、借阅或报修系统，都可能用到登录、权限、菜单和接口处理。把通用约定整理成工程底座，再接入具体业务，就是“母版 + 模块组合”的思路。
它的价值是减少重复搭建，让需求、业务规则和验证有更清楚的分工。能否用于自己的毕设，要先确认学校要求、源码许可，以及自己是否理解这套底座。
✅ 如果你想先了解项目案例，可以参考：蓝象
1. 母版、业务模块、增强模块分别做什么？
母版负责通用能力，例如识别当前用户、检查操作权限、组织菜单和处理接口返回。
业务模块负责题目本身：预约资源和时段、图书借还记录、报修派单流程。
增强模块按需加入，例如借还统计、规则推荐；它依赖业务数据，需要单独评价用途和效果。
可以这样理解：工程母版 + 业务模块 + 按需增强模块，经过集成与验证，形成项目。增强功能可以暂不加入。
2. 看一个源码里的实际例子
本文核对了毕业设计底座的 Vue 前端和 NestJS 后端，以下是公告模块的源码结构，本次未做运行测试。
公告页复用表格和权限按钮；后端接口声明notice:add等权限码，由通用权限守卫检查。公告自己的标题、正文、状态等数据保存在biz_notice表。
具体业务则在公告服务里：新增时记录当前用户，首次发布时写入发布时间，后续编辑保留已有的发布时间。
框架提供通用处理，模块补上自己的数据与规则。
3. 换成预约项目，要改哪些地方？
下面是改造设想，不是底座已有的预约功能。
登录和权限框架可以沿用；业务要重新设计预约资源、申请人、时间段和审核状态，再补页面、接口、菜单及权限配置。
同时回答：谁能审核？时间冲突怎么算？哪些状态占用资源？学生能否查看别人的申请？这些规则不能从公告模块直接照搬。
如果需要提醒或统计，再检查数据是否齐全、如何验证，按需增加。
4. 组合仍有接入成本
这套底座的模块清单只说明文件、接口和权限。新增模块仍需注册后端、配置数据库与菜单，把页面和接口对齐；放入清单不会自动安装功能。
权限框架也不会自动理解业务。例如“有审核权限”和“当前申请允许审核”是两次不同的判断；后者需要业务代码处理。
底座难以理解、依赖不匹配，都会增加接入成本。选择前先追踪一个已有功能，确认自己能修改。
5. 复用之后，自己的工作怎样说明？
保留复用来源，列清自己新增和修改的需求、数据、规则、界面及测试。论文按实际实现展开，答辩能解释一次操作怎样经过接口并改变数据。
验收时既检查正常流程，也检查无权限操作、错误状态和数据范围；菜单能打开只是其中一步。这些是建议执行的检查，本篇没有运行结果。
先把自己的方案分成“可复用能力、必须新写的业务、待评估的增强”三列，再挑一条业务验证接入路径。
