做毕业设计最怕的不是代码写不出来而是题目拿到手里不知道怎么拆。前两天有个学弟问我“鲲龙装饰公司在线管理系统”这个题目怎么做又是SSM又是Vue还要做手机端适配最后还要交一篇论文光听题目就觉得头大。这种心情我太理解了当年我自己做毕设的时候也这样后来陆陆续续带过几届学生的毕设发现这类管理系统的套路其实非常固定关键是先把业务逻辑理清楚技术选型走对方向后面就是一马平川的事。这篇文章就围绕“SSM Vue 手机端”这条主线把鲲龙装饰公司在线管理系统从需求分析到开发实现、再到论文写作的完整路径捋一遍。我会把每个环节的取舍理由、踩过的坑、以及答辩时容易被问到的点都写出来。适合两种情况参考一是正在做类似管理系统的毕业生想找一份能直接落地的开发思路二是想了解装饰装修行业信息化是怎么落地的人。文章内容偏实操尽量少说虚的。1. 装饰公司在线管理系统需求拆解先理业务流程再写代码1.1 业务流程梳理系统到底在管什么很多人做管理系统第一步就栽了上来就画数据库表、写登录页面结果做到一半发现功能之间对不上。做这种业务系统第一步永远是搞清楚业务链条。装饰公司的核心业务链路是这样的客户线上或者门店咨询销售把客户信息录入系统设计师接单后去现场量房做方案设计和初步报价方案定稿后转成正式合同合同签订后创建装修项目安排项目经理和施工队长项目开工前做材料计划和采购清单材料员统一采购进场施工过程中项目经理按节点更新进度、上传工地照片竣工后做验收和结算。这条链路参与角色至少四类管理员、设计师、项目经理有些公司叫监理、客户。另外材料员这类辅助角色在毕设里可以放进员工后台一起处理。角色不同看到的菜单和操作按钮天然就不同。比如客户登录后应该直接看到“我的项目”“我的进度”“在线留言”而设计师登录后看到的是“我的客户”“待设计方案”“项目进度上报”。如果不把角色权限和业务流绑在一起想后面做权限控制的时候一定会改来改去。我见过很多半途返工的毕设原因都是业务没理清就开始建表。建表建到一半发现客户和用户两套体系对不上项目状态不知道要拆多少种材料是跟着订单走还是跟着项目走——这些问题的答案全在业务流程里。你先把业务链路画一遍哪怕用笔在纸上画个圈都行每一条连接线都对应后面的一张表、一个接口、一个前端页面。所以这一步真的别省。1.2 功能模块划分与需求裁剪基于上面这条业务流合理的模块划分是客户管理、项目管理、预算与合同管理、材料管理、施工进度管理、在线交流与留言、系统管理。客户管理负责客户信息的增删改查和跟进状态维护项目管理从合同生效开始维护项目基本信息、人员和状态流转预算与合同管理解决报价单生成、合同登记和金额统计材料管理覆盖材料信息维护、项目材料采购计划与进场确认施工进度管理是手机端的核心项目经理按节点更新进度并上传图片在线留言则是客户和公司之间的异步沟通渠道。放到毕业设计里很多同学容易犯的错误就是功能贪多。有人说“老师指定要网上预约功能”有人说“想加一个在线支付显得高级”。我特别强调一个观点毕设功能在精不在多业务闭环比花架子重要。做一个预约看房功能涉及排班规则、时段冲突判断、短信提醒全是新的复杂度而做一个材料出库确认其实只需要改一条状态字段。把有限的开发时间花在核心业务闭环上系统完整度反而更高论文的每个章节也都能落到实处不会出现某个功能写了半页就写不下去的情况。1.3 手机端范围定义不要失控题目里有“手机端”三个字这个范围必须在一开始就定义清楚否则后面容易失控。手机端不是另起一个App也不是做一套独立的H5商城最务实的做法是核心业务支持移动浏览器访问页面采用响应式布局让客户在手机上能查进度、看预算、收留言员工在手机浏览器上能操作进度更新、材料确认。这样技术方案完全基于Vue的响应式实现不需要额外维护一套移动端代码工作量可控论文里也能写“移动端适配设计”这个章节答辩时还能演示在手机上直接访问系统现场效果很好。在做范围定义的时候我建议在论文的“需求分析”一章里明确写一行字“手机端覆盖客户查询类功能和员工操作类功能管理后台仍以桌面端为主”。这句话既是给老师看的也是给自己定的边界。没有这个边界你会不断在“要不要做App”“要不要做推送”“要不要做扫码签到”这些问题上纠结纯粹消耗时间。毕设的时间就该往核心业务和稳定交付上投。2. SSMVue技术选型分析这套组合在毕设场景下的优势2.1 都2026年了为什么毕设还选SSM这是答辩时第一个可能被老师问到的问题。别人都用Spring Boot了你还在SSM是不是技术太旧你要能给出自己的理由第一SSM是Spring、SpringMVC、MyBatis三者的组合它没有Spring Boot那么多“约定优于配置”的黑盒子每一层都通过显式配置组装这天然适合在论文里逐层分析也方便你在答辩时讲清楚请求从浏览器到数据库到底走了一条什么路第二很多高校的Java课程和实验环节仍然以SSM为主要教学内容用它做毕设意味着你的课程设计和毕业设计技术栈是一致的学习成本低遇到问题也好查资料第三项目规模属于典型的中小型管理系统SSM在开发效率和运行性能上并不比Spring Boot差MyBatis的SQL可控性在报表统计这类场景下反而更有优势。回答这个问题时千万不要表现出“我也知道Spring Boot更好”这种态度。技术选型没有绝对的对错只有合适与不合适你要强调SSM的配置透明性和学习价值。加上你用了JWT做认证、Vue 3做前后端分离、响应式布局做手机端适配这套技术组合放在毕设里已经足够完整和现代了。2.2 后端三层架构与事务边界SSM最核心的写法是Controller-Service-Mapper三层。Controller只做参数接收、结果封装和路由转发不做任何业务处理Service承担所有业务逻辑包括事务管理Mapper就是数据访问层只对应数据库的增删改查。实际开发中很多同学容易把三层混在一起写在Controller里直接调Mapper这是大忌。一旦业务逻辑多起来事务控制不了代码也没法测试。Service接口和实现类分开写事务注解加在实现类上。比如合同确认这个方法内部要同时更新合同状态、创建项目、生成初始预算这三步必须在一个事务里完成哪一步失败都要整体回滚不然就会出现“合同签了但项目没建出来”的数据不一致问题。MyBatis的Mapper接口和XML文件要一一对应XML命名空间写错的话启动就报错这种错误自己排查特别浪费时间。还有一个小细节Mapper接口的方法名不能重载因为MyBatis是通过全限定名加方法名定位SQL的重载方法会冲突。2.3 Vue版本选择与脚手架搭建Vue这块有个现实问题官方生态全面转向Vue 3组合式API已经很久了但很多老教程还是Vue 2选项式API的写法图书馆里的毕设参考书也是新旧混杂。我的建议是直接选Vue 3 Vite作为脚手架原因有三个Vite冷启动速度快开发体验比webpack好太多组合式API配合script setup写业务代码更简洁2026年的答辩场景里如果还在用Vue 2老师大概率会追问“为什么不用新版本”。唯一的坑是网上很多组件库示例还是Vue 2时代的写法真遇到版本不兼容报错要看一眼官方迁移文档。脚手架创建命令现在很稳定选默认的Vue Router和状态管理选项即可后面不需要的依赖再手动移除。前端项目结构我习惯这样组织src/api放接口请求封装src/router放路由配置src/store或src/composables放全局状态src/views按模块建目录src/components放通用组件。目录清晰的好处是自己开发到后期好定位论文里贴“项目目录结构图”也好看。2.4 请求封装与状态管理的取舍前后端交互用axios最成熟统一封装一个request.js文件配置baseURL和请求拦截器。拦截器里做两件事从localStorage取JWT token放到请求头响应状态码401时清掉本地登录信息并跳回登录页。这样每个页面里不需要重复写token逻辑代码干净很多。Vue这边我反而建议不要为了“技术亮点”硬上Pinia。这个系统的跨组件共享状态没有那么多一个用户信息加一个项目列表视图状态用provide/inject或者组件props回调就能解决。真要上Pinia也请控制在用户状态和路由权限这两个store不要每个页面都挂全局状态否则调试起来反而混乱。答辩时被问到“状态管理”就直接说项目规模不大按需引入大多数场景用组件通信已经足够这反而是你对技术有判断力的体现。2.5 版本搭配参考直接给一套实践过且兼容良好的版本组合省得自己踩版本坑。JDK用1.8就够了Spring用5.3.xSpringMVC同版本MyBatis用3.5.x连接池用Druid 1.2.xMySQL 5.7或8.0都行。前端Vue 3.2.x Vue Router 4.x axios 1.x Element Plus 2.x移动端组件库用Vant 4Vant 4完全基于Vue 3手机端页面用它的Tabbar、Cell、Progress组件开发效率会高非常多。有一点提醒前面说的是“我实际用过且稳定”的组合网上很多教程给的版本比较老比如Spring 4、MyBatis 3.2这些老版本在高版本JDK下会有兼容问题。你如果完全照搬别人的pom.xml启动时报错的概率很高。比较稳妥的方法是建一个空白Maven工程从Spring官网或者权威示例里复制当前稳定版本坐标然后逐个加上Druid和MySQL驱动。3. 数据库设计装饰公司业务的数据表结构3.1 核心表结构与表关系数据库是整个系统最不能返工的部分因为前期表结构一旦定下来后端的Mapper、前端的表单全要围着它转。装饰公司系统的核心表按业务闭环来列大概是这几张用户表、客户表、项目表、预算表、材料表、项目材料关联表、进度表、留言表。用户表负责登录账号和角色字段包括主键、用户名、密码加密存储、真实姓名、角色、联系电话、头像、创建时间。客户表负责客户业务信息包括客户姓名、电话、需求描述、来源渠道、跟进状态、关联的用户id。项目表是业务的主线包含项目编号、客户id、设计师id、项目经理id、状态、开工日期、预计完工日期。预算表关联项目id存预算金额、费用明细JSON或子表、状态。材料表维护材料名称、规格、单位、供应商、单价。项目材料关联表记录每个项目用了哪些材料、数量、进场状态。进度表记录项目节点名称、完成状态、备注、更新时间。留言表记录客户与公司之间的沟通内容。这里有极其关键的细节客户和用户表要不要合一很多毕设把客户单独建表登录却用user表最后客户登录不了。我的建议是分两个表但建立外键关联user负责登录customer负责业务字段和身份。客户注册时生成一条user记录角色为ROLE_CUSTOMER同时在customer表里加一条记录用外键关联。业务查询统一通过customer的信息去拉user的登录态这样既保证登录体系统一又不让客户业务字段污染用户表。3.2 状态字段设计与枚举项目状态、材料状态、留言状态这类字段我强烈建议存整数0、1、2……不要存中文状态字符串。好处有两点前端展示时可以根据数字映射到不同标签颜色和文案比如0待量房用灰色、1设计阶段用蓝色、2施工中用黄色、3已竣工用绿色后端做统计筛选时where status 2写起来简洁索引命中率也比字符串高。还有一个容易忽略的好处以后要加状态只需要在枚举类或者前端字典里加一个数字映射不用改历史数据。前端可以把状态枚举统一放到一个constants.js文件里写一个statusMap对象页面里渲染时根据数字取文案和颜色。后端Java端也建议定义对应的枚举类或者常量类Service层判断状态流转时不要散落魔法数字统一引用常量。这样前后端的状态口径一致不会出现“前端显示已竣工后端状态还是3”这种对不上的问题。3.3 MyBatis动态SQL与统计查询装饰公司系统里一定会用到按时间段、按状态筛选的统计数据比如某个月的项目数量、进行中的项目预算总和。这种查询条件不固定最适合用MyBatis的if、where、choose动态SQL标签来拼接而不是在Java代码里拼SQL字符串。下面这个例子是统计不同状态下项目数量的典型写法select idselectProjectCountByStatus resultTypemap SELECT status AS statusValue, COUNT(*) AS totalCount FROM project where if testbeginTime ! null AND create_time gt; #{beginTime} /if if testendTime ! null AND create_time lt; #{endTime} /if /where GROUP BY status /select实际操作中我习惯把这类统计SQL单独放到Mapper的XML里每条SQL上加注释说明业务含义论文的数据库设计章节截图也用得上。另外需要注意where标签虽然会自动去掉多余的AND但如果你在里面用了SQL片段include片段里的子查询是要自行控制闭合的写错时错误提示非常隐蔽。我建议写动态SQL时先在MySQL客户端里把完整SQL跑一遍确定无误再粘回XML这样能省下大量排查时间。3.4 命名规范与索引基础这个点看似无关紧要答辩时老师其实很看重。表名用全小写加下划线比如project_material不要用驼峰表名字段名统一小写加下划线比如project_idMyBatis里开启mapUnderscoreToCamelCasetrue查询结果就能自动映射到JavaBean的驼峰属性上。为什么不直接用驼峰因为MySQL在Linux环境下的表名大小写敏感Windows不敏感开发环境一致还好一旦部署到服务器就容易出现“表名明明存在却报找不到”的诡异问题。索引方面核心表的主键索引用自带的主键业务查询常用的外键字段和状态字段建议建普通索引比如project表的customer_id、statusprogress表的project_id。毕设阶段不需要建太多索引但要体现出你有这个意识。写论文时可以在数据库设计小节里放一张索引表列出索引名、字段、用途这个细节非常加分。4. 手机端核心模块实现与响应式适配4.1 JWT登录认证与安全注意点登录是整个系统的门面也是答辩演示时的第一个交互。认证方案用JWT是非常标准的做法用户提交用户名密码后端校验通过后用用户id和角色生成token设置过期时间返回给前端前端每次请求在Authorization头里带token后端拦截器解析token并把用户身份放到ThreadLocal里供业务代码使用。JWT的好处是服务端不需要存session天然适合前后端分离项目手机端访问时也完全没问题。生成token的代码大概是这样的String token Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(username, user.getUsername()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 30 * 60 * 1000L)) .signWith(SignatureAlgorithm.HS256, secretKey) .compact();有一点要特别提醒JWT的payload默认是Base64编码不是加密的千万别往里面塞用户密码或者身份证号这类敏感信息最多放用户id、用户名、角色和过期时间。密钥用固定配置建议长度不少于32位防止被暴力猜解。前端的token存储用localStorage还是cookie各有取舍毕设场景下localStorage简单直接但要跟老师说明清楚它的XSS风险。4.2 权限拦截器配置SSM里配置拦截器是在SpringMVC配置文件中注册的拦截路径一般写成/api/**。把所有需要登录才能访问的接口统一放在/api前缀下登录接口放行静态资源比如上传的图片路径也放行然后拦截器对/api下的请求做token校验。解析成功就把用户信息设置到请求上下文中Controller层从上下文取当前用户做业务判断的时候用得到。这里有个经验接口文档工具、数据源监控页面这类调试工具如果你引入了相关依赖要把它们的路径加到排除列表否则本地调试时总会莫名其妙被拦。权限校验按角色做二次判断比如客户端的接口只允许ROLE_CUSTOMER角色访问。毕设层面用Service层判断就足够不用去引入复杂的安全框架做方法级权限管理。把权限逻辑写清楚答辩时能讲明白即可。4.3 施工进度模块的移动端展示手机端最核心的模块就是施工进度查询。客户在手机浏览器上打开系统看到的是项目进度时间线水电改造、泥瓦工、木工、油漆等每一道工序对应一个节点节点状态分为未开始、进行中、已完成配合项目经理上传的工地照片形成一条清晰的时间轴。这里的实现思路是后端提供按项目id查询进度的接口返回节点状态列表和照片地址数组前端手机页面用Vant的时间线组件渲染工序节点显示状态颜色、备注和更新时间。进度更新时项目经理在手机端上传图片和文字说明后端将图片存储到服务器指定目录数据库仅存访问路径。图片上传要特别处理限制单个文件大小在5MB以内格式只允许jpg和png文件名用UUID重新生成不要用前端传过来的原始文件名这样可以防止路径穿越和文件名冲突问题。存储目录要做按月分文件夹的习惯否则图片多起来一个文件夹几百个文件找起来和备份起来都很痛苦。4.4 响应式布局的关键细节手机上要访问得好光靠Element Plus默认的桌面布局是不够的。我在实际项目里总结三个非常关键的点基本覆盖常见问题。第一viewport设置不能少。HTML模板里必须写meta nameviewport contentwidthdevice-width, initial-scale1.0否则手机浏览器会按980px的默认宽度渲染页面字会变得特别小这是很多人第一步就忽略的问题。第二栅格布局要处理断点。Element Plus的Row和Col组件提供了xs、sm、md、lg等断点属性比如项目列表在电脑上是四列到手机端就变一列就靠这个属性控制。千万不要用固定像素宽度写死否则手机上一出现横向滚动条体验基本就崩了。第三字体和点击区域。移动端交互靠手指按钮和列表项至少要有44像素的可点区域字体建议用rem或vw适配不同屏幕。可以设置根元素的font-size随屏幕宽度变化然后在样式中用rem作为单位实测下来在不同尺寸手机上效果很稳定。写论文时这部分可以放到“移动端交互设计”小节配合两三个布局截图说明你的适配逻辑。4.5 手机端与桌面端的功能裁剪手机端页面不要试图把桌面端功能全部复制一遍。手机端应该优先做信息查询和状态操作类功能比如客户查看进度、查看预算明细、留言咨询员工更新节点状态、审批材料单。像系统管理里的用户维护、角色分配这类管理后台功能手机上就不要做了操作繁琐且容易误触。这个“端的功能裁剪”思路放到论文里就是“移动端交互设计”这一小节的加分内容。你可以在需求分析里就明确说明哪些功能是移动端优先、哪些功能是桌面端专属再配一张功能分布表。答辩老师看到你能主动做这种产品层面的取舍会觉得你不只是在写代码而是真的在思考这个系统怎么被使用。5. 毕业设计论文写作从系统到文档的转化5.1 论文结构安排很多同学代码做完了论文写不出来核心原因是把论文当成“软件开发文档”来写而不是当“研究过程记录”来写。标准的毕设论文结构是摘要、绪论、相关技术、需求分析、系统设计、系统实现、测试、总结、参考文献。先记住六个字“背景-技术-设计-实现-测试”。摘要不要最后才写反而应该最早写完一版因为摘要逼你把项目价值用三句话讲清楚讲不清楚说明你业务还没想透后面写什么都会别扭。绪论里写研究背景和意义结合装饰行业信息化管理的实际需求再写国内外发展现状这部分就是文献综述的位置。相关技术章节把SSM、Vue、JWT、响应式布局这些技术逐个介绍但不要写成长篇说明书重点是“为什么选它、它解决什么问题”。5.2 需求分析章节怎么写才能拿高分需求分析是论文里字最多但最容易被写成流水账的部分。老师只看两个点有没有用例图、有没有明确的功能需求表。用例图画的时候要按角色分开画客户一个用例图、管理员一个用例图不要把所有角色全画在一张图里。功能需求表用三列表达模块名称、功能描述、优先级比如“进度管理模块提供项目经理更新施工节点状态的功能优先级高”。这样写出来的需求分析一眼就很清晰。非功能需求也别漏了系统响应时间、并发用户数、安全性、可维护性。不用写多每类一两句话带清楚就行。比如“系统核心查询接口响应时间在正常网络环境下不超过1秒”“采用JWT保证接口访问安全性”。这些内容看起来虚但它是论文完整度的体现也是后面测试章节的数据基准。5.3 截图、数据量与测试记录准备论文里的系统截图不要临时截两张大图充数每张截图要有自己的编号和一句话说明比如“图5-3 项目经理端进度更新界面”。测试章节一定要有测试用例表列清楚用例编号、测试模块、操作步骤、预期结果、实际结果、是否通过。这个表格一定用真实的操作记录填每个功能模块至少三条用例。为了让测试数据好看开发阶段就要往数据库里造足够多的模拟数据比如三四个装修项目每个项目有七八条进度记录客户留言若干条材料信息几十条。数据量太少的系统截图会露怯也影响最终现场演示。造数据的时候要注意前后逻辑自洽比如项目状态是“施工中”那它的进度节点里就应该有已完成、进行中、未开始的工序别出现“已竣工项目还没有验收记录”这种低级矛盾。5.4 答辩高频问题准备答辩老师最喜欢问的问题集中在这几个“你的系统相比传统线下管理效率提升体现在哪里”“如果用户量变大你的系统哪些地方会成为瓶颈”“手机端数据是实时更新的还是定时刷新的”这些问题一定要在答辩前想好答案。第一个问题从信息流转速度上答比如客户无需电话追问就能在手机上看到进度项目经理一次录入全员可见数据从“人找信息”变成了“信息找人”。第二个问题从数据库索引、接口缓存、静态资源优化三个层面答哪怕你没做缓存也要能说出思路比如“后续可以考虑在查询频率高的进度接口上做Redis缓存”。第三个问题老实回答通过接口实时拉取但说明设计了页面缓存策略来减少重复请求。三个问题准备下来基本能覆盖大多数追问场景。6. 常见问题与避坑排查实录6.1 前后端联调跨域和响应格式前后端分离项目联调时第一个遇到的就是跨域问题表现形式是浏览器控制台报blocked by CORS policy。解决方式是在后端配置跨域过滤器允许指定origin、方法和请求头。配置时要小心不要把允许的origin写成*然后还启用allowCredentials(true)这两个配置在浏览器规范里是冲突的会直接导致跨域请求失败。另外联调时前后端要约定统一的响应格式比如{ code, message, data }。后端所有Controller返回格式统一由Result对象包装前端在拦截器里先判断code是200再取data否则弹message提示。没有这个约定的话前端每个接口都要单独处理错误代码量翻倍调试成本极高。接口文档在毕设阶段用简单的表格记录就行写上路径、参数、返回格式自己联调和写论文都需要。6.2 手机真机调试连不上本机服务手机端开发最常见的坑就是手机访问电脑上的项目地址时提示无法访问。一般原因是三个电脑防火墙没放行项目端口、手机和电脑不在同一个局域网、后端服务绑定在127.0.0.1而不是0.0.0.0。排查顺序是先确认手机和电脑连的是同一个WiFi再检查电脑的局域网IP地址前端页面里接口地址要写局域网IP不要写localhost最后检查防火墙并放行端口。还有一个容易忽略的细节电脑同时开的有线网和无线网时局域网IP可能有两个手机访问的要是在无线网卡对应的那个IP才行。测试时用ipconfig看一下无线网卡的IPv4地址而不是随便拿一个内网IP就用。后端启动参数里如果没有手动绑定默认监听所有网卡的0.0.0.0那个还好但如果指定了127.0.0.1手机就永远连不上。6.3 启动过程常见报错速查下面这张表是我实操中遇到的报错排查记录覆盖从环境配置到运行期间的高频问题报错现象大概率原因处理办法启动时提示找不到Mapper BeanMapper接口没加注解或扫描路径配错检查Spring配置文件中Mapper扫描路径MyBatis XML解析报错XML文件namespace与接口不匹配核对namespace全限定名与接口包路径中文乱码请求响应编码未统一为UTF-8检查CharacterEncodingFilter配置、数据库连接URL加编码参数前端npm install卡住依赖源下载慢切换国内镜像源打包后静态资源404打包路径配置与服务器映射冲突核对Vue打包base配置或后端静态资源映射路径登录后刷新掉线token只存在内存未持久化存localStorage或cookie并配置有效期JWT过期后操作无提示前端拦截器没处理401响应拦截器里做401统一跳转这些坑几乎每个人都会踩一遍遇到先看自己是不是上面表格里的情况。不要一报错就去改大段代码先看报错信息的前几行定位到具体配置项很多时候就是个路径、一个注解的问题。6.4 毕设节奏管理的一点经验做毕设最大的敌人不是技术难度而是拖延和返工。我比较推荐的节奏是第一周只做需求分析和数据库设计表结构评审通过后再写代码第二周到第五周按模块开发先做后端再做前端第六周联调、补数据、写论文。这种节奏每隔几天就有明确产出心里踏实很多。千万别想着把所有代码写完再一次性写论文到那时候你已经忘了当初为什么这么设计论文写出来质量会很差。写到这里整个项目从拆题到落地的路径基本讲清了。我个人做完这个类型系统的体会是SSMVue这套组合虽然不新奇但只要把业务闭环理清楚、把数据库设计扎实做好、把手机端体验认真适配它就是一个非常完整的毕业设计作品。答辩的时候你不用吹嘘用了多新的技术能清楚讲明白每一步为什么这么设计本身就是最好的展示。最后再分享一个小技巧把项目跑起来之后用不同角色的账号在电脑和手机上分别操作一遍完整流程比如客户从登录到查看进度项目经理从登录到更新节点状态。这个动作能帮你发现很多“逻辑上没问题但实际用起来很别扭”的场景也会让你在答辩时对整个系统如数家珍。祝各位顺利答辩。