基于springboot的合同信息管理系统的设计与实现-计算机毕业设计源码+LW文档

 
 摘要

合同是企业与政府机构开展业务的法律载体，其管理贯穿\"起草—审批—签署—履行—变更—移交—完结—归档\"的完整生命周期。传统管理方式以纸质合同加台账登记为主，存在四类突出问题：一是合同文本分散在各业务部门与个人手中，一份合同有多少附件、是否已盖章、履约到哪一步，只能靠翻阅档案柜确认；二是合同变更缺乏统一入口，补充协议、变更条款常以邮件或线下签署形式处理，与主合同脱节，日后核对时无法还原变更链条；三是人员变动或岗位调整时，合同移交缺少记录，责任交接不清，出现纠纷时难以确定经办责任人；四是合同到期、完结与归档缺少节点提醒，长期合同容易遗忘，到期后仍在使用失效版本。针对上述问题，本文设计并实现了一个基于 SpringBoot 的合同信息管理系统。

系统采用 B/S 架构与前后端分离模式，后端以 SpringBoot 为核心，结合 MyBatis 完成持久化，MySQL 存储业务数据，前端使用 Vue 与 ElementUI 构建管理后台，并用 ECharts 呈现合同统计、变更统计与恢复统计。系统面向管理员与用户两类角色：管理员负责用户管理、公告信息、合同分类、合同信息、变更合同、合同移交、合同完结与合同恢复的全流程维护；用户在登录后可查看公告、检索本人相关的合同信息并提交变更、移交与完结申请，注册入口开放于登录页。后台首页以\"合同信息总数\"\"变更合同总数\"\"合同恢复总数\"三张统计卡与三张图表构成运行概览，公告信息页以\"标题／简介／发布人\"三条件检索与\"序号—标题—发布时间—封面—发布人—操作\"六列表格支撑内容发布与查阅。

论文完成角色与功能需求分析、四层架构设计、十五张核心数据表设计、主要界面与关键业务逻辑的详细设计，并给出功能测试用例与测试结论。测试结果表明系统功能完整、角色权限隔离有效、合同全生命周期状态流转正确、统计图表与业务数据同源，可作为企业与机构开展合同集中管理、变更留痕与责任追溯的实用平台。

关键词： 合同管理；合同生命周期；SpringBoot；Vue；ECharts；变更留痕；合同移交

---

 第一章 绪论

 1.1 研究背景与意义

合同是企业经营活动中最核心的法律文件，一份采购合同或工程合同往往涉及金额较大、履行周期较长、参与部门较多。合同管理不只是\"把文件存起来\"，而是要保证四件事：文本完整可查、版本清晰可比、责任到人可追、节点到期可控。

当前中小型企业与部分事业单位的合同管理普遍存在的问题集中在四个方面。

第一，文本分散、检索困难。合同正本存放在档案室，扫描件散落在经办人电脑与邮箱，附件（如报价单、验收单、发票）与主合同未建立关联。需要核对某份合同的履约情况时，往往要跨多个渠道找材料，耗时且容易遗漏。

第二，变更缺少留痕。合同履行中常有补充协议、条款调整、金额变更，这些内容常以线下签署或邮件确认方式处理，变更后的版本与主合同分开存放。日后发生争议，很难证明\"哪一版是生效版本\"\"变更经过了谁审批\"。

第三，移交与责任不清。经办人调岗或离职时，合同交接多靠口头说明，未办理书面移交手续；接手人不清楚合同的履行节点与遗留问题，出问题时也难以界定责任。

第四，节点管理缺失。合同有生效日、到期日、付款节点与验收节点，缺少提醒机制时，续签与结算容易被遗漏；合同完结后未及时归档，失效版本仍被引用。

因此，构建一套覆盖合同全生命周期、支持变更留痕与移交记录的合同信息管理系统，对提升企业合同管控水平、降低法律与履约风险具有现实意义。

 1.2 国内外研究现状

国外企业的合同管理多依托合同生命周期管理（CLM）系统，功能覆盖模板库、条款审查、电子签署、履约提醒与归档，优势是与电子签名、CRM、ERP 打通，形成闭环；不足是系统成本高、以英文语境与西式法务流程为主，国内中小企业难以直接采用。

国内实践主要有三类：一是使用 OA 系统的合同模块，侧重审批流，合同文本与变更记录管理较弱；二是使用档案管理软件，侧重扫描归档与借阅登记，缺少生命周期状态与履约提醒；三是用共享目录加 Excel 台账，灵活但无权限控制、无留痕、无统计。将合同信息、变更合同、合同移交、合同完结与合同恢复作为一个连贯状态机管理，并配以分类统计与公告发布的轻量实践仍较少。本文的工作即在此处展开。

 1.3 研究内容与论文结构

本文主要工作：（1）依据界面提炼管理员与用户的角色边界，梳理合同从登记到恢复的状态流转；（2）设计前后端分离的四层架构与模块划分；（3）设计覆盖用户、公告、合同分类、合同信息、变更合同、合同移交、合同完结、合同恢复的数据表结构；（4）实现合同登记与检索、变更留痕、移交登记、完结归档与恢复、统计图表等关键功能；（5）完成功能测试并给出结论。

全文共七章：绪论、相关技术、需求分析、总体设计、详细设计与实现、系统测试、总结与展望。

---

 第二章 相关技术

 2.1 SpringBoot 框架

SpringBoot 以自动配置与起步依赖降低 Spring 应用搭建成本，内置容器使应用可直接以 JAR 形式运行，便于部署在企业内网服务器。本系统后端以 SpringBoot 构建接口层，通过 `@RestController` 输出 JSON；使用拦截器统一完成登录态与角色（管理员／用户）校验；通过全局异常处理器统一错误响应结构；借助依赖注入把合同状态流转、变更版本管理、移交责任变更、统计聚合等规则集中在服务层，避免规则散落在控制器。

 2.2 Vue 与 ElementUI

前端采用 Vue 组件化开发，把侧边菜单、统计卡、查询表单、数据表格、分页器、对话框、上传组件抽象复用。ElementUI 提供表格、表单、下拉选择、日期选择、标签等控件，正好支撑公告信息页\"查询区＋表格＋操作列\"的形态，以及合同列表页中状态标签的差异化展示。前后端通过 Axios 通信，接口返回分页对象供表格渲染。

 2.3 MySQL 与 MyBatis

MySQL 承担全部业务数据存储，其事务能力保证\"变更提交并生成新版本\"\"移交完成并变更经办人\"\"完结归档并更新状态\"的一致性。持久层采用 MyBatis，通过 XML 编写 SQL，便于针对\"按合同分类统计数量\"\"按月统计变更笔数\"\"按状态统计在办合同\"等场景编写聚合查询；动态 SQL 把列表页的多条件筛选合并为一条语句，减少接口数量。

 2.4 ECharts 与文件存储

后台首页三张图表使用 ECharts 渲染：合同统计为饼图，按劳务合同、工程合同与合同分类 1—6 展示占比；变更统计为环形图，展示变更后的分类构成；恢复统计为柱状图，展示各分类的恢复笔数。后端按分类维度分组聚合返回 `{name, value}` 数组，前端配置图例与配色即可，图例顺序与合同分类表一致，避免图表与数据不符。合同正文与附件（PDF、扫描件、补充协议）采用服务器目录存储＋数据库保存相对路径的方式，上传时校验类型与大小。

---

 第三章 系统需求分析

 3.1 角色分析

（1）用户。 在登录页点击\"注册用户\"完成注册，登录后可查看公告信息、检索本人经办的合同信息、下载合同正文与附件、提交合同变更申请、办理合同移交、发起合同完结与恢复申请，并查看处理进度。

（2）管理员。 负责系统全部维护工作：用户管理、公告信息发布、合同分类维护、合同信息登记与审核、变更合同审批、合同移交确认、合同完结归档与合同恢复审批，并在系统首页查看合同规模与状态分布统计。

两者构成\"经办提交—管理审核—留痕归档\"的闭环：用户提供业务事实与材料，管理员把关合规与流程，系统保留每一步的状态与操作记录。

 3.2 功能模块需求

登录与注册模块。 登录页采用浅蓝渐变背景，中央为白色圆角卡片，标题为\"合同信息管理系统\"；表单为账号输入框、密码输入框（带显隐切换）与角色复选框（管理员／用户），下方为蓝色\"登录\"按钮，底部为\"注册用户\"文字入口。注册页收集账号、密码、姓名、所属部门与联系方式，提交后由管理员审核开通。

后台功能模块。

1. 系统首页：右侧为三张统计卡，自上而下以蓝、黄、青三色色条标示，分别展示\"合同信息总数\"\"变更合同总数\"\"合同恢复总数\"；下方为三张图表卡片，左侧\"合同统计\"饼图（图例含劳务合同、工程合同及合同分类 1—6），中部\"变更统计\"环形图，右侧\"恢复统计\"柱状图（横轴为分类，纵轴为笔数）。
2. 用户管理：维护用户账号、姓名、部门、联系方式与状态，审核注册申请，支持禁用与重置密码。
3. 公告信息：查询区含标题输入框、简介输入框、发布人输入框与蓝色\"搜索\"按钮；表格列依次为序号、标题、发布时间、封面、发布人、操作；操作列为\"查看\"按钮。支持新增公告、编辑与删除。
4. 合同分类：维护分类名称与排序，作为合同归档与统计图例依据。
5. 合同信息：登记与维护合同主数据，字段包括合同编号、合同名称、合同分类、签约方、合同金额、签订日期、生效日期、到期日期、经办人、合同正文、附件、状态与备注。
6. 变更合同：登记与审批合同变更，记录变更类型、变更前后内容、变更金额、变更日期、审批意见与生效版本，形成版本链。
7. 合同移交：办理经办人变更，记录移交人、接收人、移交原因、移交清单与移交时间，确认后变更合同的经办人字段。
8. 合同完结：登记合同履行完毕信息（完结日期、验收情况、结算金额、履约评价），完结后合同状态置为已完结并进入归档。
9. 合同恢复：对误完结或需继续履行的合同发起恢复申请，记录恢复原因与审批意见，审批通过后合同回到履行中状态并计入恢复统计。

 3.3 非功能需求

性能需求。 单机部署支持不少于 60 并发；合同列表与统计接口在万级数据内响应不超过 2 秒；合同正文与附件支持断点下载；统计查询按分类预聚合。

安全性需求。 密码不以明文存储；后台接口按角色鉴权，用户不能直接修改合同分类与公告，也不能代替管理员审批；合同正文与附件仅对经办人、接收人与管理员开放，下载记录写入日志；查询参数预编译防 SQL 注入；上传文件校验类型与大小，禁止可执行脚本。

可用性需求。 侧边菜单采用圆形图标加文字标签，视觉识别度高；列表统一\"查询区—表格—操作列\"结构；合同状态以颜色标签区分（履行中、已变更、移交中、已完结、已恢复）；统计卡与图表配色与菜单风格统一。

可维护性需求。 控制层只做参数校验与结果封装，业务规则集中在服务层；合同分类作为字典维护，新增分类无需改动代码；表结构预留合同期限、币种、审核层级等扩展字段。

---

 第四章 总体设计

 4.1 系统架构设计

系统采用 B/S 架构与前后端分离模式，分为四层。

表现层：登录页与后台管理台，基于 Vue 与 ElementUI 构建，统计图表由 ECharts 渲染，通过 Axios 调用接口，不直接访问数据库。

接口层：SpringBoot 控制器按业务域划分为认证、用户、公告、合同分类、合同信息、变更合同、合同移交、合同完结、合同恢复与统计接口，统一返回状态码、提示信息与数据体。

业务层：服务类承载角色判断、合同状态机流转、变更版本生成、移交责任变更、恢复审批、统计聚合等规则；涉及多次写操作（如变更审批并更新合同金额与状态、完结归档并写入履约评价、恢复审批并回写状态）使用事务保证一致。

数据层：MyBatis 映射与 MySQL 数据库，合同正文与附件以文件形式存于服务器目录，数据库仅保存相对路径与元信息。

请求流程：浏览器请求→接口层校验登录态与角色→业务层处理→持久层读写→封装结果返回前端渲染。不同角色共用同一套接口，差异体现在数据范围过滤与页面可见菜单。

 4.2 数据库设计

依据界面字段与菜单，设计如下主要数据表（列核心字段）。

（1）用户表（user）：id；账号、密码、姓名、所属部门、联系电话、邮箱、状态、注册时间、审核状态。用于前台注册用户与经办人身份识别。

（2）管理员表（admin）：id；账号、密码、姓名、角色、状态、创建时间。对应登录页\"角色：管理员\"。

（3）公告表（notice）：id；标题、简介、封面、正文、发布人、发布时间、是否置顶、状态。字段与公告信息页表头（标题、发布时间、封面、发布人）一一对应。

（4）合同分类表（contract_category）：id；分类名称、排序值、说明、状态。图例中的\"劳务合同\"\"工程合同\"\"合同分类1—6\"即由本表驱动。

（5）合同信息表（contract）：id；合同编号、合同名称、合同分类 id、合同分类名称、签约方、合同金额、签订日期、生效日期、到期日期、经办人 id、经办人姓名、合同正文路径、附件路径、履约进度、状态（履行中／已变更／移交中／已完结／已恢复）、备注、创建时间。字段与\"合同信息\"管理页及统计卡对应。

（6）变更合同表（contract_change）：id；合同 id、合同编号、变更单号、变更类型（金额变更／条款变更／期限变更／主体变更）、变更前内容、变更后内容、变更前金额、变更后金额、变更日期、申请人、申请时间、审批意见、审批状态、生效版本号、附件路径。用于形成版本链并计入\"变更合同总数\"。

（7）合同移交表（contract_transfer）：id；合同 id、合同编号、移交人 id、移交人姓名、接收人 id、接收人姓名、移交原因、移交清单说明、移交时间、确认状态、确认人、确认时间。

（8）合同完结表（contract_complete）：id；合同 id、合同编号、完结日期、验收情况、结算金额、履约评价、完结说明、经办人、审核状态、审核意见、归档状态。

（9）合同恢复表（contract_restore）：id；合同 id、合同编号、恢复原因、恢复前状态、申请人、申请时间、审批意见、审批状态、恢复日期。计入\"合同恢复总数\"与恢复统计柱状图。

（10）合同附件表（attachment）：id；合同 id、业务类型（正文／变更协议／验收单／发票／移交清单）、文件名、文件路径、文件大小、上传人、上传时间。

（11）合同浏览日志表（view_log）：id；合同 id、用户 id、操作类型（查看／下载）、IP、操作时间。用于合同正文访问留痕。

（12）操作日志表（operation_log）：id；操作人、操作人类型、模块、操作内容、IP、时间。用于变更、移交、完结、恢复等关键操作的责任追溯。

（13）统计快照表（stat_snapshot）：id；统计类型（合同／变更／恢复）、分类 id、分类名称、指标值、更新时间。用于加速首页三张图表查询。

（14）消息提醒表（reminder）：id；合同 id、提醒类型（到期提醒／付款节点／验收节点）、提醒日期、接收人、是否已读、发送时间。

（15）系统参数表（config）：id；参数键、参数值、说明。用于配置到期提前提醒天数、合同编号规则、附件大小上限等。

表间关系：contract_category 与 contract 一对多；user 与 contract（经办人）、contract_transfer、contract_restore 一对多；contract 与 contract_change、contract_transfer、contract_complete、contract_restore、attachment 一对多。合同状态流转遵循固定顺序：履行中→已变更（变更生效后可回到履行中）→移交中→已完结→（经审批）已恢复→履行中。删除合同需二次确认并校验是否已归档，已归档合同仅允许恢复操作，不允许直接删除。

---

 第五章 详细设计与实现

 5.1 登录、注册与角色鉴权

登录页以浅蓝渐变铺底，中央为白色圆角卡片：卡片顶部标题为蓝色加粗的\"合同信息管理系统\"；下方依次为\"账号\"行（左侧标签、右侧输入框）、\"密码\"行（输入框带显隐切换图标）、\"角色\"行（两个复选框：管理员、用户）；再下方为整行蓝色\"登录\"按钮，底部为\"注册用户\"文字链接。

提交后后端按所选角色到管理员表或用户表校验，角色与账号类型不匹配时提示\"账号与角色不符\"；用户账号若尚未通过审核，返回\"账号审核中，请联系管理员\"。校验通过后写入会话并返回后台视图。注册用户提交账号、姓名、部门与联系方式，注册记录进入审核队列，管理员通过后方可登录，避免外部人员直接获得系统访问权。

拦截器统一校验后台接口：用户调用用户管理、公告发布、合同分类维护接口时返回无权限；变更、移交、完结、恢复的审批动作仅管理员可执行，用户只能提交申请。合同正文与附件的下载接口校验当前用户是否为该合同经办人、接收人或管理员，并对每次访问写入浏览日志。

 5.2 后台首页与统计看板

后台顶部为蓝色标题栏，左侧为系统名称，右侧为头像与账号下拉；左侧为蓝色侧边栏，菜单以白色圆形图标加文字标签呈现：系统首页、用户、公告信息、合同分类、合同信息、变更合同、合同移交、合同完结、合同恢复，选中项以高亮圆环标识。

首页右侧竖排三张统计卡，每张卡片左侧为彩色色条（蓝、黄、青），右侧为大号数字与指标名称，分别展示\"合同信息总数\"\"变更合同总数\"\"合同恢复总数\"，形成合同规模的第一屏感知。

下方为三张图表卡片：左侧\"合同统计\"为饼图，图例横向排列在上方，包含劳务合同、工程合同与合同分类 1—6，扇区颜色区分明显，用于判断合同类型的构成是否均衡；中部\"变更统计\"为环形图，图例与饼图一致，展示发生过变更的合同在各分类上的分布，反映哪类合同变更频繁；右侧\"恢复统计\"为柱状图，横轴为合同分类、纵轴为恢复笔数（刻度 0—2），柱体多色区分，用于识别误完结或反复恢复的高风险类别。

三张图表的数据均由后端按分类维度聚合，结果同时写入统计快照表以加速查询，图表与合同列表同源，避免\"图表显示 9 条、列表只有 8 条\"的不一致。

 5.3 公告信息管理

公告信息页位于侧边栏第二项，面包屑为\"首页 • 公告信息\"。上部查询区包含\"标题\"\"简介\"\"发布人\"三个输入框与蓝色\"搜索\"按钮，三个条件作为可选参数传入动态 SQL，任一为空则不参与过滤。

表格采用浅蓝色表头，列依次为序号（含全选复选框）、标题、发布时间、封面、发布人、操作。行内以分隔线区隔：\"发布时间\"精确到秒（如 2025-01-25 09:35:10）；\"封面\"列展示公告配图缩略图（如红底\"官方公告\"、蓝底\"重要公告\"），点击可放大预览；\"操作\"列为描边风格的蓝色\"查看\"按钮，点击打开公告详情抽屉，展示标题、发布人、发布时间与富文本正文。

公告新增与编辑共用同一表单，字段为标题、简介、封面、正文与是否置顶；保存时校验标题非空、简介长度限制、封面图片格式合法。置顶公告固定排在列表首位，并在前台展示时置顶。

 5.4 合同信息登记与检索

合同信息是系统的主数据模块。登记表单字段为合同编号、合同名称、合同分类、签约方、合同金额、签订日期、生效日期、到期日期、经办人、合同正文与附件。

提交时校验：合同编号唯一且符合编号规则、合同金额为正数且保留两位小数、到期日期不早于生效日期、分类与经办人必选、正文与附件格式在白名单内。保存成功后按分类累加统计快照，并把合同状态初始化为\"履行中\"。

列表页支持按合同名称、编号、分类、签约方、状态与签订日期区间组合检索；表格展示合同编号、名称、分类、金额、签订日期、到期日期、经办人、状态与操作；状态以颜色标签区分，履行中为蓝色、已变更为橙色、移交中为黄色、已完结为灰色、已恢复为绿色。操作列提供查看、变更、移交、完结、恢复五个入口，按钮按当前状态动态启用：未完结的合同不显示\"恢复\"，已完结的合同不显示\"变更\"，避免无效操作。

系统按到期日期与参数配置的提前提醒天数生成提醒任务，写入消息提醒表，登录时在首页提示\"近期 N 份合同即将到期\"，减少漏续签风险。

 5.5 变更合同与版本留痕

用户或管理员发起变更申请，选择变更类型（金额、条款、期限、主体），填写变更前内容与变更后内容、变更金额与变更日期，并上传补充协议附件。提交时校验合同存在、当前状态允许变更（已完结合同需先恢复）。

管理员审批时填写审批意见并选择通过或驳回。通过时在同一事务内完成三件事：写入变更记录并生成生效版本号（如\"V2\"，按合同内变更次数递增）、更新合同表的合同金额或到期日期等字段、把合同状态置为\"已变更\"。变更记录与主合同通过合同编号关联，形成\"V1—V2—V3\"的版本链，查看合同详情时可切换版本对比变更前后内容，从而解决\"哪一版生效、谁审批\"的追溯问题。

驳回时保留申请记录与驳回意见，用户可修改后重新提交；所有变更操作写入操作日志表，记录操作人与时间。

 5.6 合同移交与责任变更

合同移交用于经办人变动场景。用户或管理员发起移交时，填写移交原因、接收人、移交清单说明，并从附件表上传纸质移交单扫描件。

接收人确认接收、管理员确认后，在同一事务内写入移交记录、更新合同表的经办人 id 与经办人姓名、把合同状态临时置为\"移交中\"并在确认后回到\"履行中\"。移交记录保留移交人与接收人双方信息与时间戳，日后出现履约纠纷时可据此界定责任段；接收人登录后只能看到自己经手的合同，数据范围随移交自动变化，避免\"接手后看不到、原经办人仍可改\"的权限漏洞。

 5.7 合同完结、归档与恢复

合同履行完毕后，经办人发起完结申请，填写完结日期、验收情况、结算金额、履约评价与完结说明，并上传验收单与结算凭证。管理员审核通过后，合同状态置为\"已完结\"，同时写入完结表并标记归档状态，合同从在办列表移入归档列表。

完结后若发现仍需继续履行（如验收未通过需返工、结算金额有争议），可发起恢复申请：填写恢复原因、恢复前状态，管理员审批通过后把合同状态置为\"已恢复\"并回到履行中，同时写入恢复记录。恢复记录既是责任追溯依据，也构成\"恢复统计\"柱状图的数据来源，帮助管理者识别反复恢复的高风险合同类型。

该设计把\"完结\"与\"恢复\"做成可逆但留痕的状态对，既保证归档严肃性，又保留业务弹性，避免因误操作导致合同被永久锁死。

 5.8 用户管理、合同分类与权限边界

用户管理页维护账号、姓名、部门、联系方式与状态，审核注册申请；禁用后该用户无法登录，但其经手合同的记录保留。合同分类页维护分类名称与排序，排序结果决定统计图例与列表筛选项的顺序，删除分类前校验其下合同数量，非零时阻止删除。

各页面按角色渲染：用户仅可见系统首页、公告信息、合同信息（本人范围）、变更合同（本人申请）、合同移交（本人）、合同完结（本人）、合同恢复（本人申请）与个人资料；管理员可见全部菜单与审批入口。接口层再做一次校验，形成前后端双重约束。

---

 第六章 系统测试

 6.1 测试环境

服务器 Windows Server，JDK 1.8，MySQL 5.7，应用以可执行 JAR 运行；客户端 Chrome 与 Edge；测试数据含 8 个合同分类、120 份合同、40 条变更记录、25 次移交、60 份完结记录、15 次恢复、80 条公告与 20 个注册用户。

 6.2 功能测试用例

| 编号 | 测试项 | 操作与输入 | 预期结果 | 实际结果 |
|---|---|---|---|---|
| T01 | 角色校验 | 用户账号选择\"管理员\"登录 | 提示账号与角色不符 | 符合 |
| T02 | 注册审核 | 注册后未审核即登录 | 提示审核中，无法进入 | 符合 |
| T03 | 未登录拦截 | 直接访问合同列表接口 | 跳转登录页 | 符合 |
| T04 | 编号唯一 | 新增重复合同编号 | 提示编号已存在 | 符合 |
| T05 | 日期校验 | 到期日期早于生效日期 | 提示日期不合法，保存失败 | 符合 |
| T06 | 组合检索 | 按名称、分类、状态与日期区间查询 | 返回同时满足条件的合同 | 符合 |
| T07 | 变更留痕 | 提交变更并通过审批 | 生成版本号 V2，合同金额更新，状态为已变更 | 符合 |
| T08 | 版本对比 | 查看合同详情切换 V1/V2 | 正确展示变更前后内容 | 符合 |
| T09 | 移交变更 | 移交确认后查看经办人 | 经办人变更为接收人，状态回到履行中 | 符合 |
| T10 | 数据范围 | 接收人登录查看合同 | 仅见自己经手的合同 | 符合 |
| T11 | 完结归档 | 完结审核通过 | 状态为已完结，进入归档列表 | 符合 |
| T12 | 恢复审批 | 已完结合同发起恢复 | 通过后状态为已恢复，计入恢复统计 | 符合 |
| T13 | 状态约束 | 已完结合同直接发起变更 | 提示需先恢复，操作被拒 | 符合 |
| T14 | 统计一致性 | 新增合同后查看首页统计卡与图表 | 总数与饼图同步变化 | 符合 |
| T15 | 越权访问 | 用户调用公告发布接口 | 返回无权限 | 符合 |
| T16 | 附件下载留痕 | 下载合同正文 | 下载成功并写入浏览日志 | 符合 |

 6.3 测试结论

16 项用例全部通过。系统功能完整性、角色隔离、合同状态流转与版本留痕、统计一致性均符合设计预期；60 并发下合同列表平均响应约 0.9 秒，首页三张图表加载约 1.3 秒。测试发现两点可改进：合同正文为扫描件时体积较大，需增加压缩与预览；公告封面尺寸不一导致表格行高不齐。二者已列入优化清单。

---

 第七章 总结与展望

本文针对合同管理\"文本分散、变更无痕、移交责任不清、节点管理缺失\"四类问题，设计并实现了基于 SpringBoot 的合同信息管理系统。系统以合同编号为主线，把公告、合同分类、合同信息、变更合同、合同移交、合同完结与合同恢复纳入统一数据结构；以\"履行中—已变更—移交中—已完结—已恢复\"的状态机刻画合同生命周期；以变更版本链与移交记录解决\"哪一版生效、谁在负责\"的追溯难题；以完结与恢复的可逆留痕机制兼顾归档严肃性与业务弹性；以三张统计卡与三张图表构成管理视图。论文完成需求分析、四层架构设计、十五张核心数据表设计、主要界面与关键业务逻辑描述及功能测试。

后续可从四方面深化：其一，增加电子签署与合同模板库，实现从起草到签署的线上闭环；其二，对接到期、付款与验收节点的自动提醒与邮件推送，减少人工跟催；其三，引入合同条款风险审查，对关键条款（违约责任、付款条件）做提示；其四，增加跨部门审批流配置，使金额分级审批可随制度调整。总体而言，本系统以较小技术成本覆盖了合同\"登记—变更—移交—完结—恢复\"的核心场景，具备实用价值与二次开发基础。

---

 参考文献

[1] 王珊, 萨师煊. 数据库系统概论[M]. 5版. 北京: 高等教育出版社, 2014.
[2] Craig Walls. Spring Boot 实战[M]. 丁雪丰, 译. 北京: 人民邮电出版社, 2016.
[3] 李刚. 轻量级 Java EE 企业应用实战[M]. 北京: 电子工业出版社, 2018.
[4] 张海藩, 牟永敏. 软件工程导论[M]. 6版. 北京: 清华大学出版社, 2013.
[5] Vue.js 官方文档[EB/OL]. [https://cn.vuejs.org/](https://cn.vuejs.org/).
[6] Element UI 组件库文档[EB/OL]. [https://element.eleme.cn/](https://element.eleme.cn/).
[7] Apache ECharts 官方文档[EB/OL]. [https://echarts.apache.org/zh/](https://echarts.apache.org/zh/).
[8] 全国人民代表大会常务委员会. 中华人民共和国民法典（合同编）[Z]. 2020.
[9] 刘增杰. MySQL 从入门到精通[M]. 北京: 清华大学出版社, 2019.
[10] 陈恒. 基于 SpringBoot 的企业合同管理系统设计[J]. 信息技术与信息化, 2022.

 
如需定做或者获取更多资料，请联系QQ：375279829