毕业设计选考勤系统这在很多人眼里可能不够高大上。但说实话我见过太多选了高难度系统结果烂尾的同学也见过不少用考勤系统这种经典题目稳扎稳打拿到优秀评级的例子。原因很简单考勤系统的需求非常贴近真实业务功能边界清晰既能展示SpringBootVueMySQL这套主流技术栈的完整闭环又能轻松拆出足够多的论文素材。你要是正愁选题或者已经定了这个题目但不知道从哪里下手这篇文章会把公司日常考勤系统从需求分析、数据库设计、后端接口、前端页面一直聊到论文组织和部署文档怎么写全程按可落地执行的标准来。1. 为什么考勤系统是毕业设计的稳妥型选题需求边界与工作量评估1.1 需求清晰但又不至于毫无挑战考勤系统之所以被大量选作毕业设计核心原因是它的需求足够贴近日常认知。你不用花太多时间向评委解释系统是干什么用的签到、签退、请假、加班、统计任何人都能听懂。但懂不代表简单关键在于你怎么把这套看似普通的业务做深。常见的学生版本是用户能登录、能打卡、能看自己的记录管理员能看到所有人的记录完事。这种版本看起来功能齐全但论文和工作量都薄得像纸片。真正能拿高分的版本至少要纳入以下几个层次基础考勤闭环上下班打卡、补卡申请、管理员审核。请假与加班流程员工提交申请部门负责人审批审批结果反写考勤状态。考勤规则引擎迟到、早退、缺卡、旷工的判定不应写死在代码里而是由规则表驱动。统计报表月度汇总、部门维度对比、异常考勤列表、导出功能。权限体系至少分出管理员、部门主管、普通员工三种角色。这样拆下来功能量大概在10到14个模块左右。对于一个人完成的毕设来说工作量刚好不会轻松到没东西写也不会复杂到三个月做不完。1.2 一个小型团队的真实考勤场景建模在设计时我一直建议把系统想象成一家30人左右的小型公司在用的工具。公司有4到5个部门每个部门有一位主管公司设一位人事管理员。员工每天早晚各打卡一次如果忘记打卡可以在当天发起补卡申请。请假分事假和病假三天以内主管审批三天以上需要人事管理员复核。月底人事管理员导出考勤汇总表用来核算工资。把场景描述到这个颗粒度系统的每一个功能都能对上具体的业务角色和业务动作。而且这个场景本身就是论文第一章研究背景和第三章需求分析的现成素材你不用凭空编造业务故事只需要把场景翻译成功能需求即可。1.3 时间分配建议别把三个月全砸在编码上按我的经验一个人完成这套系统最合理的时间分配是前两周做需求分析和数据库设计中间五到六周做前后端编码再留两周写论文和画图表最后一周收拾部署文档和准备答辩。很多同学把时间全花在写代码上结果论文只能用两个晚上通宵赶出来这样的论文质量必然拖后腿。毕业设计的评分通常由系统演示和论文各占相当比例答辩现场半个小时只能看你两三个功能但论文评委是会拿着逐页翻的。2. 技术栈选型的底层逻辑为什么一定是SpringBootVueMySQL2.1 这套组合解决了什么问题在毕业设计层面技术选型的第一原则不是新而是稳。SpringBoot是当前企业级Java后端的事实标准Vue是前端框架里最容易被初学者上手且文档最全的MySQL是关系型数据库里在Windows和Linux上部署都毫无压力的。这三者组合起来既有完整的行业代表性又有足够多的参考代码和排错资料哪怕你卡住三天搜索到的解决方案数量也足以让你脱困。SpringBoot负责提供RESTful API内置Tomcat打包成JAR直接运行省去单独配置服务器的麻烦。Vue负责前端页面渲染和交互配合Element UI或者Element Plus组件库能快速搭建出像模像样的管理界面。MySQL负责持久化所有考勤业务数据用Navicat或MySQL Workbench都能很好地进行可视化管理。2.2 为什么不建议改用其他方案我知道有些同学会犹豫要不要用Spring Cloud要不要把前端换成React要不要引入Redis我的态度很明确除非你已经对这套技术栈非常熟练否则一律按最主流、最简洁的路线来做。Spring Cloud对于单体毕设完全是过度设计光服务注册发现和配置中心就能耗掉你一周的时间React的学习曲线比Vue陡而且针对于考勤这类管理系统Vue的双向绑定和数据响应式特性开发效率更高Redis在这个项目里只配做缓存但考勤数据本身实时性要求不高热点数据压力又小引入Redis反而让部署文档多出不少篇幅。技术的价值在于解决问题不在于看起来复杂。评委问为什么不用XX时你回答当前架构已满足业务要求引入XX会增加部署和运维成本且没有解决实际痛点这比硬撑着用一堆技术要加分得多。2.3 前后端分离的项目结构规划推荐的项目结构是标准的Maven多模块单体应用实际操作中甚至不需要拆模块一个SpringBoot工程加一个Vue工程即可attendance-system/ ├── backend/ # SpringBoot后端 │ ├── src/main/java/com/company/attendance │ │ ├── controller/ # 接口层 │ │ ├── service/ # 业务层 │ │ ├── mapper/ # MyBatis持久层 │ │ ├── entity/ # 实体类 │ │ ├── config/ # 配置类 │ │ └── common/ # 统一返回、异常处理、工具类 │ └── src/main/resources/ # application.yml, mapper XML ├── frontend/ # Vue前端 │ ├── src/ │ │ ├── api/ # axios请求封装 │ │ ├── views/ # 页面组件 │ │ ├── router/ # 路由配置 │ │ ├── store/ # 状态管理 │ │ └── components/ # 公共组件 └── database/ # SQL脚本前后端分离的好处是你在论文系统实现一章可以自然地分两节来讲每一节都能写出具体的页面截图和接口调用逻辑论文篇幅和素材量都会充足很多。3. 数据库设计从业务场景到十张核心表的结构推演3.1 数据库设计的第一性原则让表结构能直接支撑业务规则考勤系统的数据库设计最忌讳的是把所有信息塞进一张大表。比如把用户信息、部门信息、打卡记录全部放在一起后期统计会写得极其痛苦。我的建议是严格按照业务链路拆表每条链路对应一个独立的业务对象。以我自己的实践为例设计了一共十张表表名用途核心字段sys_user员工账号信息id, username, password, real_name, department_id, role_id, phone, email, hire_date, statussys_role角色表id, role_name, role_codesys_user_role用户角色关联id, user_id, role_iddepartment部门表id, dept_name, dept_code, leader_idattendance_rule考勤规则表id, rule_name, work_start_time, work_end_time, late_minutes, early_minutes, work_daysattendance_record打卡记录表id, user_id, work_date, check_in_time, check_out_time, status, source_typeleave_request请假申请表id, user_id, leave_type, start_time, end_time, reason, status, approver_id, apply_timeovertime_request加班申请表id, user_id, overtime_date, start_time, end_time, reason, statusreissue_request补卡申请表id, user_id, attendance_date, check_type, reason, status, approver_idoperation_log操作日志表id, user_id, operation, method, params, ip, create_time3.2 几张关键表的设计细节先说attendance_record表这是整个系统的核心。这里有三个容易踩坑的地方。第一不要用打卡时间直接存日期而是拆出work_date和工作时间字段。这样方便按天查询也方便索引。第二status字段不要只存一个正常我建议存一个可扩展的状态编码。比如NORMAL、LATE、EARLY_LEAVE、MISSING_CARD、ABSENT至于具体判定规则由后端根据考勤规则表动态计算而不是写死在签到接口里。第三要加source_type字段用来区分本次打卡记录是IC卡、指纹机还是Web端手动打卡。在企业管理类毕设里虽然不会真正对接硬件设备但论文里写系统为后续接入设备预留了数据源字段立刻就显得设计有前瞻性。再来说attendance_rule表。很多同学忽略这张表把上下班时间写在代码配置里。这在毕设里是大忌因为需求分析时你明明写了不同部门、不同岗位可以有不同的考勤规则结果实现的时候写死了论文前后对不上。规则表的存在让考勤判定逻辑从硬编码变成了查表计算这个设计决策在答辩时很容易被评委认可。leave_request表则要注意审批状态流转。我推荐状态字段用PENDING、APPROVED、REJECTED、CANCELLED四个值审批人字段approver_id在员工提交申请时由后端根据部门主管规则自动填充不要在前端传。如果你想增加亮点可以再加leave_type把事假、病假、年假分开统计。3.3 SQL脚本贡献一段完整的建表参考这里给出考勤核心表的建表 SQL 片段方便你直接在项目中复用。实际部署时把十张表全部建好并插入默认管理员账号和测试部门数据。CREATE TABLE attendance_record ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, user_id bigint NOT NULL COMMENT 用户ID, work_date date NOT NULL COMMENT 工作日期, check_in_time datetime DEFAULT NULL COMMENT 签到时间, check_out_time datetime DEFAULT NULL COMMENT 签退时间, status varchar(20) NOT NULL DEFAULT NORMAL COMMENT 考勤状态, source_type varchar(20) DEFAULT WEB COMMENT 打卡来源, remark varchar(255) DEFAULT NULL COMMENT 备注, create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_date (user_id, work_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT考勤打卡记录表;这里用user_id work_date建联合索引非常关键因为打卡查询和月度汇总几乎都是谁在哪一天或者谁在哪个月这种维度的查询。没有这个索引百万级数据量之后查询会明显变慢。虽然毕设数据量不大但在论文的性能分析部分你也可以借这个索引设计写上两句查询优化策略。4. 后端核心接口实现签到签退、请假审批与考勤规则计算4.1 统一定义RESTful接口风格后端接口建议全部采用/api前缀返回统一的结果包装结构ResultT。Result一般包含 code、message、data 三个字段。比如登录成功返回Result.success(token)业务异常返回Result.error(500, 请假天数不能为负数)。为什么要这么做因为前端使用 axios 拦截器时可以统一处理错误码和异常提示不需要每个页面都写一遍 try-catch对提升代码整洁度意义很大。接口清单按照业务模块划分大致如下认证模块POST /api/auth/loginPOST /api/auth/logoutGET /api/auth/info考勤打卡模块POST /api/attendance/check-inPOST /api/attendance/check-outGET /api/attendance/todayGET /api/attendance/my-records请假模块POST /api/leave/applyGET /api/leave/my-listGET /api/leave/pendingPOST /api/leave/approve补卡模块POST /api/reissue/applyGET /api/reissue/pendingPOST /api/reissue/approve考勤统计模块GET /api/attendance/summaryGET /api/attendance/department-summaryGET /api/attendance/export系统管理模块GET /api/user/listPOST /api/user/addPUT /api/user/updateDELETE /api/user/deleteGET /api/department/list4.2 签到签退接口的业务逻辑签到接口是整个系统最核心的代码复杂度不在接口本身而在判定规则。一个合格的签到接口逻辑顺序应该是从当前登录用户获取userId。查询该员工的考勤规则也就是从attendance_rule表取上下班时间。查询当前日期是否已存在打卡记录。如果 exists 且 checkInTime 为 null则更新签到时间如果 exists 且 checkInTime 非 null则更新签退时间。调用考勤状态计算逻辑根据当前时间和规则重新计算状态。这里有个细节值得注意签到和签退建议合并为一个接口通过今天的记录状态来自动判断是签到还是签退。前端页面上表现为同一个打卡按钮点击后显示上班打卡成功或者下班打卡成功用户感知是一致的但后端逻辑却节省了一个接口。而且这样处理更容易保证同一天只有一个打卡记录。考勤状态计算逻辑单独抽一个私有方法比如calculateStatus(AttendanceRecord record, AttendanceRule rule)。它的判定优先级是如果签到时间为空可能是缺卡或旷工视当天是否请假而定。如果签到时间晚于规则中的work_start_time加late_minutes判定为LATE。如果签退时间早于work_end_time减early_minutes判定为EARLY_LEAVE。如果两个时间都缺失且无请假记录判定为ABSENT。我把这段逻辑写成工具类而不是揉在Controller里便于单元测试。毕设里能够提供几个简单的JUnit单元测试也是论文测试章的加分项。4.3 请假审批流程的状态机设计请假审批我建议在LeaveRequestService中维护一个简单的状态机。员工创建请假单时状态为PENDING主管接口通过approve操作传入PASS或REJECT同时记录审批人和审批时间。这里需要特别注意三天以上的请假需要两级审批于是流程变成主管审批通过后如果请假日数大于三天则状态保持PENDING并自动流转到人事管理员如果小于等于三天状态变为APPROVED。这个逻辑听起来很简单但很多同学会把它写成硬编码的 if 嵌套。更好的做法是维护一个APPROVAL_LEVEL字段在提交请假单时根据请假时长自动计算需要几级审批。这样后续调整审批规则时不需要改代码只改配置即可。我这样说可能比较抽象举个具体的例子请假日数 3时approvalLevel设为 2每通过一级审批currentLevel加1当currentLevel approvalLevel时请假状态最终变为APPROVED。这种设计在答辩时可以向评委展示你对状态流转的理解而不是单纯地调增删改查接口。4.4 考勤统计和报表导出考勤统计是整个系统最容易在答辩时被深挖的部分因为评委大概率会问你如何计算一个员工这个月的出勤率很多人被问住就是因为在实现在时候没有认真设计统计接口。正确做法是编写一个月度汇总查询方法输入参数是userId和yearMonth输出结果包含应出勤天数、实际出勤天数、迟到次数、早退次数、旷工天数、请假天数、加班时长。查询逻辑分成两步第一步查出该员工当月所有attendance_record第二步依据考勤规则表生成应出勤的天数集合再和实际记录逐一匹配。导出的功能可以用EasyExcel或者POI实现导出内容就是这张汇总表。如果时间不够导出功能可以后置加入前两天我在做类似项目时发现导出的实现其实比想象中快基本就是定义好表头实体类一行EasyExcel.write(outputStream).sheet(考勤汇总).doWrite(dataList)就完事。但我建议把导出按钮只放在管理和人事管理员页面上普通员工不开放这样在论文的角色权限描述里又多一条可以写的细节。4.5 登录鉴权与密码加密登录鉴权方面我不建议使用复杂的Spring Security配置对于毕设项目来说手写拦截器加JWT是性价比最高的方案。JWT生成和校验用io.jsonwebtoken库登录成功后生成token返回前端前端每次请求在Header里带Authorization: Bearer token。后端编写一个AuthInterceptor使用HandlerInterceptor拦截所有/api/**请求登录接口除外解析token并存入ThreadLocal中供Service层获取当前登录用户。密码存储一定要用BCrypt加密千万别明文存。很多同学为了省事直接在数据库里存明文密码这在论文抽检或者答辩演示时一旦被追问会显得非常不专业。Spring Security里的BCryptPasswordEncoder可以单拿出来用不需要引入完整的安全框架注意加盐和比对逻辑即可。5. 前端页面与交互Vue考勤看板的关键实现5.1 前端工程的初始化与路由设计前端选用Vue 3 Vite构建UI组件库用Element Plus。项目初始化用npm create vitelatest frontend然后安装vue-router、pinia、axios和element-plus。路由根据自己的角色来控制普通员工默认跳转到考勤看板页主管额外看到审批中心管理员能看到系统管理菜单。路由设计建议按模块分组而不是堆一个平铺的列表。这样做的实际好处是你可以单独为每个路由配置meta比如meta: { roles: [admin, manager] }然后在全局路由守卫里判断当前用户的角色是否在允许列表里。这个设计在论文的系统安全设计小节里非常讨喜评委看到有路由级别的权限控制会认为你是考虑了细颗粒度权限的。5.2 考勤打卡页面的交互细节考勤看板页面是前端最重要的页面。页面主体分为三块员工信息卡片、一个大号的打卡按钮、近7天的考勤记录列表。打卡按钮的状态根据今日打卡情况分为三种未签到、已签到未签退、已完成。页面加载时调用/api/attendance/today拿到今日记录按钮文案和颜色与后端返回的状态对应。// 打卡提交逻辑 const handleCheck async () { const res await checkAttendance(); if (res.code 200) { ElMessage.success(res.data.message); todayRecord.value res.data.record; } else { ElMessage.error(res.message); } };这里我在实际开发中的一个经验是在打卡成功后不要马上刷新整页而是只更新局部的打卡时间和状态字段减少页面闪烁。同时在页面顶部用一个警告条提示今日考勤异常比如今日已迟到迟到时长12分钟让员工进入页面就能感知异常。这个交互细节能在演示时加分因为评委看到的不是一个只会跳数据列表的系统而是有业务流程体验的系统。5.3 管理端页面的布局与权限菜单管理端布局采用经典侧边栏加顶栏结构。侧边栏菜单根据角色动态渲染管理员看到全部菜单主管看到审批中心和部门考勤汇总普通员工只看到考勤看板、我的考勤、请假申请。在实现上后端登录接口返回用户信息时同时返回roleCode和一份menuList前端根据menuList渲染菜单不需要在本地硬编码角色与菜单的对应关系。这样后端可以随时调整权限配置前端的改动成本极低。其中一个页面的表格建议全部加上分页后端接口返回PageResult结构包含total、records、current、size。前端用el-pagination组件绑定current和size每次翻页重新请求接口。分页看似基础但很多毕设项目都不做等演示数据积累到一定量级时页面就会严重卡顿。在论文中你也可以把分页作为系统性能优化措施的一部分来写。5.4 前后端联调时的跨域与代理陷阱前后端分离开发时跨域是最容易碰到的坑。我建议在开发环境下Vue 项目通过 Vite 的server.proxy配置代理而不是在后端疯狂写CrossOrigin。原因是代理的方式更接近生产环境的部署状态也避免每次都把allowCredentials和allowedOrigins配置得焦头烂额。// vite.config.js 片段 server: { port: 3000, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端请求/api/auth/login开发服务器自动转发到后端地址。到了生产环境则是用 Nginx 配置同样的转发规则。开发环境用的代理和生产环境用的 Nginx 转发本质是同一套思路面试或答辩被问你懂不懂跨域时这个回答路径是比较完整的。6. 论文结构与部署文档的组织思路让评委快速看懂你的工作6.1 论文各章节的写作重点与篇幅配比论文的结构一般按学校模板来但内容分配是有策略的。我见过很多人的论文把所有篇幅都堆在功能编码上把需求分析和数据库设计写得像流水账。实际上答辩评委最关注的是你为什么这么设计以及系统是否满足了需求分析中的全部功能。一个稳妥的论文结构比例是绪论和文献综述占两成需求分析和可行性分析占两成总体设计和数据库设计占三成系统实现含核心代码和截图占两成系统测试和总结占一成。也就是说不要把核心篇幅放在抄代码上而应放在设计思路的论证上。在需求分析章节把你选定的业务场景写清楚有些什么角色、每类角色有哪些操作需求、考勤规则是怎么定义的。建议配一个功能模块图用Visio或ProcessOn画以及一张用例图。在数据库设计章节至少画出ER图以及每张表的详细字段说明。这里不要只贴建表SQL还要为每一张核心表写一段为什么这么设计的说明文字。6.2 部署文档可以当作小型运维手册来写部署文档不只是简单写运行 npm run dev和运行 java -jar。一份合格的部署文档应该包含环境准备、后端部署、前端部署、数据库初始化、常见问题排障五大部分。尤其要写清楚JDK版本推荐JDK 1.8或11、MySQL版本推荐5.7或8.0、Node版本因为版本不匹配会导致各种奇怪的报错。我在实际部署中经常遇到的是JDK版本过高导致JWT库和旧版依赖不兼容或者MySQL 8.0的时区问题导致数据库连接报错。部署文档里把这些坑提前标注能大幅减少用户提问。数据库初始化部分要写明先创建数据库再执行init.sql同时提示字符集使用utf8mb4否则中文会乱码。后端部署有两种方式方式一是直接java -jar target/attendance-backend.jar方式二是用mvn package打包后在任意服务器运行。前端部署就简单一点先npm run build生成dist目录然后将目录下的文件放到Nginx的html根目录同时配置反向代理转发/api到后端端口。6.3 答辩演示的套路准备一条主线和两条支线答辩现场的时间有限演示时建议走一条主线以人事管理员身份登录先展示员工管理功能添加一个测试员工再切换普通员工登录演示打卡和提交请假再切换主管登录演示审批请假最后回到管理员登录查看考勤统计并导出报表。这条主线能把系统80%的功能覆盖到而且故事连贯评委看得明白。准备的支线是异常处理和权限控制。当评委问到如果员工忘记打卡怎么办你就顺势演示补卡申请流程当评委问到普通员工能不能看到别人的考勤数据你就顺势聊路由守卫和接口权限。答辩最怕的是评委问到你做过的功能之外的东西所以把系统里已经实现的细节准备成回答弹药库远比临场发挥更有把握。7. 我实际踩过的坑时区、事务、日期计算与权限泄漏7.1 时区问题让打卡时间整整差了八个小时我在第一次联调时发现打卡记录里存的时间比本地时间快了8小时。排查了半天发现是MySQL连接串里的serverTimezoneAsia/Shanghai没有配置而JDBC驱动默认取了系统时区导致时间偏移。解决办法是在application.yml里显式配置数据库连接的时区参数spring: datasource: url: jdbc:mysql://localhost:3306/attendance_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse同时后端在返回打卡时间给前端时建议统一在实体类的checkInTime字段上配置JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)不然Jackson默认序列化时区也可能出问题。这种问题在答辩前很容易被忽略一旦现场演示时时间不对观感会非常尴尬。7.2 事务注解失效的典型场景请假审批和补卡审批都涉及多表更新需要加事务注解。但我踩过一个坑在同一个类内部一个方法调用另一个带有Transactional的方法时事务实际上是不生效的。因为Spring的事务是通过代理实现的内部调用走的是原始对象而不是代理对象。解决方案是把这个更新逻辑拆到独立的Service类中或者在外部调用入口方法上加事务。我在请假审批接口中需要同时更新请假单状态、写操作日志、并且可能改写考勤记录状态。这三步必须在一个事务里。如果事务失效前面两步成功、第三步失败数据就出现不一致。这个问题在答辩前不容易暴露但一旦被问到你如何保证数据一致性没有事务支撑的答案会很苍白。7.3 日期计算里藏着很多边界条件考勤系统的日期计算比想象中复杂。月度汇总时要计算应出勤天数就得把周末和法定节假日排除。这里我没法引入完整节假日库所以采用了一个折中方案在attendance_rule表中维护work_days字段默认值是1,2,3,4,5代表周一到周五上班。遇到调休或者特殊安排就在系统中配置一个holiday_config表手动标记某一天是放假还是补班。这种方案的逻辑简单但非常稳。如果你天真地以为用第三方节假日API就能搞定那在答辩演示当天如果遇到API不可用整个系统就会陷入瘫痪。毕设系统最重要的是可控宁可手动维护一份节假日配置也不要依赖外部服务。我建议在月度汇总时遍历每一天判断法定节假日的逻辑用配置文件驱动这样论文里也可以把节假日管理作为系统中的一个独立模块来写。7.4 权限泄漏的高频位置统计接口和审批列表权限问题是我最后想强调的。很多同学的考勤系统做完了角色管理但接口层的拦截并不严格。比如/api/attendance/summary这个统计接口如果只是返回所有员工的数据那么普通员工一旦知道接口地址就能看到全公司考勤情况。正确的做法是在Service层先获取当前登录用户角色如果是管理员或主管且有部门权限才允许执行统计如果是普通员工则强制将查询条件限定为userId 当前用户。审批接口也有类似的问题GET /api/leave/pending返回待办列表时必须按当前审批人的身份过滤而不是返回所有待审批记录。我见过一个项目主管登录后能看到本部门所有请假但也能看到别的部门待审批请假就是因为查询语句里没有带上审批人条件。这个坑不一定要等系统上线才会发生答辩现场评委很可能构造一个越权访问的测试用例来验证你的系统。提前把这些查询条件写好是展示你理解权限控制的重要加分项。从我个人的实践来看考勤系统这类经典的毕设题目从来都不是简单的代名词。它真正考察的是你对完整业务链路的认识需求怎么转换为设计、设计怎么转换为代码、代码怎么保证数据的正确与安全。如果你能把这里提到的每一个环节都扎扎实实做出来哪怕技术本身不是最前沿的你在答辩时的底气也远高于做一个半吊子的高复杂度系统。最后再分享一个小经验在项目交付前至少完整地跑通一次从部署到使用的全过程记录每一步的操作和可能遇到的问题这些记录最后几乎原封不动就能变成你的部署文档省下你很多写文档的时间。
