合同管理系统源码解析：Spring Boot+Vue 3实现台账、审批流与到期预警-北京尧图网络

简介合同管理系统源码以模块化方式覆盖合同全生命周期管理面向企业信息化人员与.NET开发工程师重点解决合同创建、审核、签署、履行及续签终止环节中人工管理效率低、数据易错等问题。压缩包共654个文件约47.99MB包含92个cs核心源码、36个resx界面资源、103个dll依赖库、49个png图标及26个exe可执行程序另有sln解决方案、config配置文件与数据库文件方便直接打开工程进行调试与二次开发。系统内含合同信息管理、合同扫描电子化、设备信息管理、年度统计数据四大模块既能快速录入合同编号、签订日期、金额等关键字段并检索更新也可将纸质合同转为可搜索文档降低遗失风险。目前已有927人学习下载适合需要合规存档、设备关联管理或做合同管理定制化项目的团队参考。1. 合同管理系统源码把合同台账、审批流和到期预警拧成一套可部署的系统这份合同管理系统源码解决的问题很具体企业里合同散落在邮箱和聊天记录里谁签了、什么时候到期、金额多少全靠人工翻找审批流程靠口头传达到期了没人提醒。源码不是演示用的半成品而是一套覆盖合同起草、审批、归档、到期提醒全流程的可用工程后端 Spring Boot前端 Vue 3跑起来就是一个能日常使用的合同台账系统。适合两类人一是企业里想快速搭建内部合同管理工具的开发者二是需要一个基础版本做二次开发、往里面接电子签章或改审批流的项目组。我拆完这套代码最大的感受是它没有用复杂的工作流引擎和微服务架构而是用简单的状态机加定时任务把合同管理最常见的几个痛点处理到位了代码量不大思路清晰拿来改比自己从零写快得多。2. 技术选型与工程结构Spring Boot 3 Vue 3 的前后端分层布局2.1 后端为什么选 Spring Boot 3 MyBatis Plus后端工程基于 Spring Boot 3.x 构建数据持久层用的是 MyBatis Plus。Spring Boot 负责自动装配和起步依赖让项目不需要维护一堆繁琐的 XML 配置MyBatis Plus 则把单表 CRUD、分页查询、条件构造这些高频操作全部内置合同台账列表这种典型的分页查询接口基本不用手写 SQL。我在实际项目里也倾向这种组合启动快、依赖少、新人接手不会在配置阶段卡太久能把精力放在业务逻辑上。除了基本的 Web 和 ORM 依赖工程还引入了 Redis 承担两类职责一是合同编号的并发生成二是登录会话的缓存。Redis 在这里不是可有可无的点缀——合同台账是多人同时录入的场景合同编号必须全局唯一而且要有业务含义靠数据库自增做不到“日期前缀当日序号”这种格式用 Redis 的自增命令生成序列是常见解法。会话缓存则是配合前端路由守卫登录成功后把用户信息和角色写入 Redis前端请求带上 token后端从缓存里取身份鉴权。安全方面工程没有引入 Spring Security 全家桶而是自己写了一个拦截器实现登录校验和接口白名单。这个取舍在中小型内部系统里很合理Spring Security 的过滤器链和配置体系学习成本高内部系统的权限模型通常就管理员、法务、普通员工几种角色自行实现反而更直观、更容易按业务定制。合同管理本身就是企业内网应用不暴露到公网安全重心放在登录鉴权和数据权限上就够了。2.2 前端工程Vue 3 Element Plus 的权限与表单前端是标准的 Vue 3 单页应用构建工具用的 ViteUI 组件库选的 Element Plus。页面主要分成三块合同台账列表页、合同审批详情页、系统管理页。台账列表页是最核心的界面支持按合同名称、类型、状态、到期日期区间筛选数据表格展示合同编号、签订方、金额、到期日等关键字段审批详情页按时间线展示审批记录附件列表支持在线预览和下载系统管理页负责用户和角色的维护。权限控制做了两层路由守卫控制菜单可见性按钮级别用自定义指令控制。登录用户从后端拿到自己的角色编码路由表里每个页面配置需要的角色不匹配就重定向到无权限页。按钮权限的实现思路是注册一个 v-permission 指令指令内部判断当前用户权限列表里是否包含该按钮所需的权限标识不包含就直接移除 DOM 节点。这套做法在中小型管理系统里是主流方案不需要引入专门的权限框架改动成本低。Element Plus 用在合同表单上的体验比较顺。合同创建页面包含合同编号、合同类型、签订方、合同金额、签订日期、到期日期、附件上传等字段日期选择器、级联选择器、上传组件都是现成的。源码对表单做了统一的校验规则封装比如合同金额必须大于 0、到期日期不能早于签订日期这些业务校验放在前端先拦一层能明显减少无效请求打到后端。后端同样有对等的校验逻辑前端校验只是为了用户体验后端校验才是数据安全的关键。2.3 目录结构从 controller 到 mapper 的四层落点拿到底层源码先看目录结构再跑起来比急着启动更重要。后端工程按 com.company.contract 包名组织controller、service、mapper、entity、dto、config、common 各司其职前端 src 下是 api、router、store、views、components 五个目录。关键目录落点如下contract-admin/ ├── backend/ │ ├── src/main/java/com/company/contract/ │ │ ├── controller/ # 接口层合同、审批、提醒、用户四个模块 │ │ ├── service/ # 业务层含 impl 实现类 │ │ ├── mapper/ # MyBatis Plus 的 Mapper 接口 │ │ ├── entity/ # 数据库实体类 │ │ ├── dto/ # 请求响应对象 │ │ ├── config/ # 安全、Redis、定时任务配置 │ │ └── common/ # 统一返回结果、异常处理 │ └── src/main/resources/ │ ├── application.yml # 数据源、Redis、文件上传配置 │ └── db/contract.sql # 初始化表结构和种子数据 └── frontend/ ├── src/ │ ├── api/ # 按模块拆分的 HTTP 请求 │ ├── views/ # 合同台账、审批、统计页面 │ ├── router/ # 路由和页面守卫 │ └── store/ # Pinia 状态管理 └── package.jsonconfig 包里有三个配置类值得提前认识SecurityConfig 负责登录拦截和接口白名单RedisConfig 定义 RedisTemplate 的序列化方式ScheduleConfig 开启定时任务扫描。SecurityConfig 里配置了登录接口和静态资源不拦截其余 /api/** 请求必须携带有效 token。这个结构最大的优点是分层干净接口层不写业务逻辑业务层不碰 SQLmapper 只负责数据库交互。想调整审批条件就去 Service 层改想换一套数据库方言改 Mapper 里的注解即可。前端部分更清晰views 和 api 一一对应新增页面时复制一个模块改改路径就能出活。3. 核心模块拆解一个合同从起草到归档的完整链路3.1 合同起草编号生成与附件上传合同起草是整套流程的起点。前端表单提交后调用 /api/contract/create 接口后端 ContractController 接收请求Service 层依次完成三件事生成合同编号、保存合同基本信息、关联上传的附件。合同编号生成是整个模块最值得讲的地方核心代码很简洁Override public String generateContractNo(String contractType) { String prefix contractType DateUtil.format(new Date(), yyyyMMdd); Long seq redisTemplate.opsForValue().increment(contract:seq: prefix); return prefix String.format(%04d, seq); }逻辑说明前缀由合同类型编码加当天日期组成比如 XS 是销售合同、CG 是采购合同再通过 Redis 的 INCR 命令对「当天前缀」这个 Key 做自增得到一个从 1 开始的当日序号最后用 %04d 补足四位生成的编号形如 XS202501150012。这套编号包含三个信息合同类型、签署日期、当日顺序号业务方看一眼编号就知道合同归属。参数 contractType 是合同类型编码由前端下拉框传入sequence 从 Redis 获取天然具备并发安全多个用户同时创建合同不会撞号。附件上传走的是另一个接口请求类型是 multipart/form-data文件保存到本地配置的 upload 目录文件元数据写入合同附件表。上传这里有实现细节文件名做了 UUID 重命名防止中文文件名乱码以及同名文件互相覆盖原始文件名单独存一列用于下载时展示。我在项目里处理上传都会遵守这个约定——任何用户可控的文件名都不能直接落盘否则线上迟早会出同名文件互相覆盖的问题到时候恢复数据是个大麻烦。合同基本信息的保存逻辑也不复杂但注意 ContractDTO 里加了校验注解金额字段用的是 BigDecimal 而不是 Double。这个选择的原因很直接金额计算和存储必须精确Double 的浮点误差在金额对比和统计时会翻车。所有涉及钱的字段从 entity 到 dto 全部用 BigDecimal数据库对应 decimal(18,2)这是做管理系统的基本功。3.2 审批流一张审批记录表撑起的状态机审批是这个系统里最有含金量的模块。它没有引入 Activity 这类重量级流程引擎因为合同审批的场景相对固定用流程引擎反而增加部署和学习成本。源码用一张合同审批记录表加合同表上的状态字段手动实现了一个状态机合同状态分为草稿、审批中、已通过、已驳回、已归档每个状态允许发生的动作是固定的比如草稿可以提交审批审批中可以审批通过或驳回只有已通过的状态才能归档。状态机最怕的是并发问题。两个审批人同时打开同一条合同A 先点了通过B 后点了驳回如果后端不做任何控制最后结果就是 B 覆盖了 A——合同被驳回了但 B 其实只是基于过期页面做的操作。源码处理和这个问题相关的核心代码Override Transactional(rollbackFor Exception.class) public void approve(ApprovalRequest request) { Contract contract contractMapper.selectByIdForUpdate(request.getContractId()); if (contract null || !审批中.equals(contract.getStatus())) { throw new BizException(合同状态已变化请刷新后重试); } contract.setStatus(已通过); contractMapper.updateById(contract); ApprovalRecord record new ApprovalRecord(); record.setContractId(contract.getId()); record.setApproverId(request.getApproverId()); record.setAction(通过); record.setComment(request.getComment()); approvalRecordMapper.insert(record); }逻辑说明selectByIdForUpdate 使用数据库行级锁同一时间只有一个审批请求能读到这条合同记录从源头避免两个人同时审批导致的状态覆盖事务注解保证合同状态更新和审批记录插入要么同时成功要么一起回滚。代码里先查合同再检查状态状态不对直接抛业务异常前端会弹出提示让用户刷新页面。我第一次做审批功能时没加行锁结果两个审批人同时点击最后合同状态被后提交的人覆盖这种血泪经验现在还记得凡是涉及状态流转的更新操作一定要考虑并发。审批记录表保存完整的操作历史包含审批人、动作、意见、时间四个字段。合同详情页按时间倒序展示这条记录链对审计很有价值——企业法务查合同时能直接看到是谁在什么时间做了哪个审批动作。这套设计不依赖任何外部服务数据都在自己库里出现问题排查也方便。3.3 到期预警定时任务怎么避免重复执行合同到期提醒是用户感知最强的功能。系统每天凌晨跑一次定时任务扫描未来 30 天内到期以及已经过期的合同给合同责任人发送提醒消息。实现用的是 Spring Boot 自带的 Scheduled 注解没有引入 XXL-Job 这类分布式调度中心单机部署场景下够用且省事Scheduled(cron 0 0 2 * * ?) public void remindExpiringContracts() { String lockKey contract:remind:lock; Boolean locked redisTemplate.opsForValue().setIfAbsent(lockKey, 1, Duration.ofMinutes(30)); if (Boolean.FALSE.equals(locked)) { return; } ListContract contracts contractMapper.selectExpiringContracts(30); for (Contract contract : contracts) { messageService.sendRemind(contract); } }逻辑说明先通过 Redis 的 setIfAbsent 尝试获取一把锁获取成功才继续执行扫描获取失败说明另一个实例正在执行直接跳过。这段代码是防止以后从单机部署扩展成多实例时多个节点同时跑任务导致同一合同收到多条重复提醒。锁设了 30 分钟过期时间避免任务执行过程中抛异常导致锁永久不释放后续任务全部被卡死扫描条件封装在 selectExpiringContracts 里SQL 判断合同结束日期在当天和当前日期加 30 天之间。参数 30 是提前提醒的天数改成 15 或 60 只需调整这一处。另外提醒内容做成了消息模板包含合同名称、到期日期、剩余天数通过站内信发送给合同责任人。实际用下来这种自动预警比人工翻台账高效得多也是最容易获得业务方认可的功能。如果以后要接企业微信或钉钉推送只需要替换 messageService 的 sendRemind 实现模板和扫描逻辑都不用动。4. 本地跑通从导入 SQL 到前后端联调的环境与步骤4.1 环境准备JDK、MySQL、Redis 三个前提跑这套源码前先把基础环境确认一遍缺一个都会在中途卡住。后端需要 JDK 17 以上因为 Spring Boot 3 基于 Jakarta EEJDK 8 直接跑不起来数据库用 MySQL 5.7 或 8.0初始化脚本兼容两种版本Redis 建议 5.x 以上功能上没什么特殊要求。前端需要 Node.js 16 以上包管理器用 npm 或 pnpm 均可。MySQL 和 Redis 的安装方式按操作系统来macOS 可以用 HomebrewLinux 用包管理器Windows 下载安装包。MySQL 初始化时务必选 UTF-8 字符集否则导入中文数据后查询会乱码。数据库创建也有一个细节初始化脚本 contract.sql 里没有 CREATE DATABASE 语句需要先手动建一个契约库再导入比如通过命令行执行 mysql -uroot -p -e CREATE DATABASE contract_db DEFAULT CHARACTER SET utf8mb4; 再导入脚本接口路径和库名以脚本为准。4.2 启动后端修改配置文件的三个必填项后端启动前需要修改 application.yml 里三处配置MySQL 连接信息、Redis 连接信息、本地文件上传路径。改完这几项才能正常连接依赖服务配置修改示例spring: datasource: url: jdbc:mysql://localhost:3306/contract_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: your_database_password redis: host: localhost port: 6379 password: your_redis_password_if_any file: upload: path: /data/contract-upload参数说明url 中 serverTimezone 必须显式设置MySQL 8.x 驱动默认要求指定时区否则启动直接报错username 和 password 改成你本地的数据库账号file.upload.path 是合同附件的保存目录Windows 环境建议改成 D:/contract-upload 这种绝对路径。Redis 如果没有设置密码password 那一行可以注释掉留着空字符串反而可能触发认证错误。配置项对应关系存在几个常见误用有人把 Redis 的 host 写成 localhost 但实际 Redis 跑在 Docker 容器里导致连接失败也有人把上传目录写成相对路径服务重启后文件全部丢失。改造路径用绝对路径并确认目录有写权限可以在项目根目录放一个 .gitkeep 占位避免空目录被版本控制忽略。改完配置后在 backend 目录执行 mvn spring-boot:run 启动。看到日志输出 Started Application 就表示启动成功不要只看到 Tomcat started on port 8080 就以为万事大吉要等 Spring 上下文完全刷新。启动过程中最常见的报错就是数据库或 Redis 连不上表现为 CommunicationsException 或 Unable to connect to Redis先确认两个服务进程是否在运行、端口是否被占用再用命令行客户端手动连一下问题基本能定位。4.3 启动前端环境变量与代理配置前端启动相对省心。在 frontend 目录下先安装依赖再启动开发服务器项目内置了开发代理前端请求 /api 开头的接口会自动转发到本地的 8080 后端端口所以本地开发不需要处理跨域。标准启动命令组合cd frontend npm install npm run devnpm install 如果报错先检查 Node 版本是否过低Vue 3 和 Vite 对 Node 版本有明确要求太旧的版本装依赖会失败。npm run dev 启动后访问 http://localhost:5173 就能打开登录页。用初始化脚本里的测试账号登录账号 admin密码 admin123登录后能看到合同台账、审批中心、到期提醒三个主菜单数据列表里有初始化脚本预置的几条示例合同。如果前端登录后接口全部报 401大概率是后端没启动或者代理指向不对。打开浏览器开发者工具看 Network 面板确认请求落在了哪个地址再对照 Vite 配置文件里的 proxy 设置排查。整个联调链路通了之后顺一遍核心流程建一条合同、传一个附件、提交审批、审批通过、看到期提醒可以发现这套系统日常使用链路非常短业务人员培训成本很低。跑通之后建议做三件事验证系统完整可用第一用测试账号创建合同并走完提交、审批、归档全流程第二把合同到期日改成明天手动触发一次提醒任务确认消息发送逻辑正常第三查看审批记录表确认每一步操作都已落库。三个动作都通过说明环境没有问题后面改代码心里才有底。5. 避坑指南跑这套合同管理源码常见的七个问题5.1 合同编号重复或冲突现象创建合同时报数据库唯一索引冲突或者生成的编号和已有数据重复。原因本地开发时 Redis 只做缓存没有持久化重启后自增计数被重置新生成的编号从 1 开始很容易和已有编号撞车。解决给 Redis 开启 AOF 持久化关闭服务器时数据不丢更稳妥的做法是在系统初始化时把 Redis 里编号自增的初始值设为数据库当前最大序号这样即使 Redis 重置也能衔接上。线上环境我建议两个都做编号这种东西一旦乱了很难人工修复。5.2 审批后合同状态不是预期值现象两个审批人同时打开同一条合同A 先通过B 后驳回最后状态是驳回但 B 并没有真的想驳回。原因前端页面打开时拉取的是旧状态后端没有做并发控制后提交的请求直接覆盖了前一个结果。解决源码里用行级锁解决了这个问题但如果你在二次开发时改动了审批逻辑务必保证查询状态和更新状态在同一个事务里更新语句带上当前状态作为条件。这两个细节少任何一个并发下必然出问题。5.3 上传的附件下载时 404现象附件上传成功列表里也能看到文件名但点击下载提示文件不存在。原因文件上传路径配置的是相对路径或临时目录服务一重启文件就被清理了。解决把 file.upload.path 改成固定的绝对路径并确认该目录有读写权限。另外存储附件信息时不能只存文件名要把文件相对上传目录的完整路径存下来否则同一天上传的同名文件会互相干扰。5.4 定时提醒任务不执行现象合同到期了责任人没有收到任何提醒。原因一种情况是服务没启动另一种情况是 Redis 分布式锁的 Key 一直存在没有释放后续任务全被拦在锁外。解决先看日志里有没有任务执行的记录再检查 Redis 中 contract:remind:lock 这个 Key 是否存在。排查到锁占住不放的情况多数是任务执行中抛出异常没走释放逻辑给任务体加上 try-finally 确保锁最终能被删除。这个坑属于定时任务的经典问题多实例部署时尤其注意。5.5 前端打包部署后接口全部 404现象本地开发一切正常npm run build 后部署到 Nginx登录接口全部 404。原因开发环境的代理配置在生产环境不生效打包后的前端发出的是同源请求Nginx 没有将 /api 反向代理到后端接口。解决在 Nginx 站点配置里加一条 location /api 的反向代理规则把前端请求转发到后端服务。这个坑很常见本质上就是开发时浏览器代理帮做的事部署后要由 Nginx 来做。5.6 审批记录时间线顺序错乱现象合同详情页审批记录忽前忽后看不出真实顺序。原因查询语句没有按时间排序或者时间字段用了字符串格式排序时按字典序而非时间先后排列。解决审批记录表时间字段用 datetime 类型查询时 ORDER BY create_time ASC。所有涉及时间线展示的查询都建议数据库排序而不是内存排序数据量大了才能看出差距。5.7 合同台账搜索变慢现象合同数据达到几万条后按名称搜索明显卡顿。原因合同名称字段没有建索引搜索是全表扫描。解决给合同表的合同名称字段加一个普通索引如果按类型和状态筛选很频繁这几个字段也一并建复合索引。索引不是越多越好按实际查询频次来加避免拖慢写入性能。6. 二次开发三个最值得改的扩展点6.1 接入电子签章服务这套源码目前是内部审批闭环没有对接外部电子签章平台。改造思路在审批通过的逻辑后增加一个签章触发点合同状态变为已通过后自动调用签章服务的 API上传合同 PDF 文件并获取签署链接。推荐用 Spring 的事件机制做解耦审批通过后发布一个 SignContractEvent签章监听器收到事件后异步处理不阻塞主流程。这样改的好处是原有审批逻辑完全不动未来换签章服务商只需要新增一个监听器实现。签名密钥不要写死在代码里放到环境变量或配置中心代码一旦泄漏不至于连密钥一起泄露。6.2 审批流改成多级会签当前是单级审批合同提交后只有一个审批人处理。改成多级会签需要动两个位置合同表加一个当前审批层级字段审批记录表加一个批次号字段。提交审批时生成一个批次批次内包含多个审批人每个审批人通过后检查同一批次内是否还有人未处理全部通过才推进到下一级。关键判断逻辑public void batchApprove(String batchNo, Long approverId) { ListApprovalRecord records approvalRecordMapper.selectByBatchNo(batchNo); boolean allDone records.stream().allMatch(r - 已处理.equals(r.getStatus())); if (allDone) { Contract contract contractMapper.selectById(records.get(0).getContractId()); contract.setApproveLevel(contract.getApproveLevel() 1); contractMapper.updateById(contract); } }逻辑说明每次审批人处理完自己的记录统计同一批次下所有记录的完成状态只有全部已处理才把合同的审批层级加一进入下一级审批。参数 batchNo 是批次号创建审批流程时生成approverId 是当前处理人。这个改造也验证了源码解耦设计的价值——审批记录表独立于合同表扩展字段不会影响合同模块稳定。6.3 数据权限按部门隔离默认实现是所有登录用户能看到全部合同在一家公司里这往往不合适。改造做法是合同表增加一个部门 ID 字段用户在查询台账时只能看到本部门的数据。建议在 Mapper 层通过 MyBatis Plus 拦截器统一拼接部门条件而不是在每个业务方法里手写判断——数据权限这种东西一定要在底层拦靠业务层自觉会在某一次需求迭代中漏掉一个接口造成越权访问。我做完这类改造后有一个很深的认知查询条件的统一收敛越早做越好等接口多了再回头补权限过滤工作量翻倍。从那以后我每次接手管理系统第一件事就是先把数据权限的查询条件定义清楚再写业务。希望帮到你。本文还有配套的精品资源点击获取

合同管理系统源码解析：Spring Boot+Vue 3实现台账、审批流与到期预警

相关推荐

六类网线标准TIA/EIA-568-B.2-1深度解析

MATLAB车牌识别：从图像预处理到字符识别的完整技术链路

VOS3000操作手册精讲：费率套餐配置与话单报表避坑指南

更多资讯

程序员必备1800词汇：突破编程英语阅读障碍的实用手册

潮流计算与不对称短路分析：牛顿-拉夫逊法和对称分量法的Matlab实现

ESXi 7.0 ISO制作与裸金属部署全指南

经典ASP图片上传管理源码解析：老系统快速补图片模块

Kube-OVN：基于OVN/OVS的生产级Kubernetes SDN网络底座

3560三层交换机配置详解：VLAN、SVI、HSRP与ACL实战

今日更新

MATLAB缩进快捷键与批量格式化实战指南

用Poco实现Qt风格信号与槽的跨平台C++方案

ESXi裸机虚拟化安装指南：从硬件兼容到虚拟机部署

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？