SSM+Vue进存销系统毕业设计全流程实战指南

发布时间：2026/10/11 12:42:22

做了这么多年Java方向的毕设辅导进存销系统算是我眼里的“常青树”。它不像电商秒杀那种高并发场景那么唬人也不像图书管理那么简单到没技术含量复杂度刚好卡在“能写清楚”和“有东西可讲”之间非常适合作为毕业设计的选题。而SSM Vue这套组合又是目前多数高校Java方向的主流技术栈选它做进存销系统一是贴合课程所学二是这套组合文档多、社区问答多真到了赶论文的阶段遇到问题能快速找到参考。这篇东西我打算按“需求设计 → 数据库 → 后端 → 前端 → 论文答辩 → 排坑”这条线索把整个毕设从立项到成稿的完整路径写清楚重点会放在实操环节和那些写文档时根本找不到的细节痛点上给正在做或者准备做这个题目的同学一份可以“抄作业”的参考。1. 项目核心拆解进存销系统到底要做什么动手写代码之前先把业务本身看透。很多同学一上来就建表、写接口结果做了一半发现需求没理清返工的代价非常高尤其是论文写完后发现数据流对不上改起来非常痛苦。1.1 从“进存销”三个字看真实业务场景进存销系统管理的是“进货—库存—销售”这条核心链路。我们可以用一个小卖部的经营逻辑来理解老板进货货物入仓库库存变多顾客买东西仓库出货库存变少货卖完了要补货卖不动的要盘点。所谓进存销系统就是把这条链路搬到线上让老板可以随时知道现在仓库里有什么、有多少、价值多少、哪些东西快卖完了、一段时间内哪些商品卖得好。具体到系统功能通常会拆成六大块基础信息管理商品信息名称、编号、分类、单位、规格、供应商信息、客户信息。采购入库管理下采购单、审核、入库入库后自动增加库存。销售出库管理新建销售单、出库出库后自动扣减库存。库存管理库存查询、库存预警低库存提醒、库存盘点修正账面数量。统计报表按时间维度统计采购金额、销售金额、库存周转情况最常见的是用ECharts折线图和柱状图展示。系统管理用户登录、权限区分管理员、普通员工、菜单管理。这六大块是主体论文里的业务章节基本就是围绕这六块展开的。如果是本科毕设六块全做是标准工作量不做全反而容易被答辩老师问住你的进销存凭什么说“进、存、销”齐全了1.2 为什么选SSM Vue而不是其他组合选题时会有很多老师提“Spring Boot Vue”这个组合确实爽少了大量XML配置。但SSMSpring SpringMVC MyBatis的价值在于它是理解Java Web分层架构最好的“教材组合”Spring管对象、SpringMVC管请求分发、MyBatis管数据库访问三者的边界清晰配置过程繁琐但能逼着你搞懂底层机制。答辩的时候老师看到你用的是SSM常问的第一个问题就是“Spring、SpringMVC、MyBatis分别负责什么”这个问题只要你亲手配置过就一定能答得出来。Vue这边选择Vue 2还是Vue 3要看学校要求。如果学校教的是Vue 2毕设就用Vue 2 Element UI稳如果自己比较熟Vue 3也可以Vue 3 Element Plus Vite。从我实测的经验来看Vue 2 Element UI的社区资料最多遇到疑难杂症容易搜到答案对赶毕设来说稳定压倒一切。脚手架推荐用vue-element-admin的简化版或者自己用vue-cli搭一个带侧边栏和顶栏的基础框架没必要真的把完整后台模板都引进来反而显得项目体量不真实。前端通信方面用axios发送异步请求和后端约定统一返回结构这个后面联调时我会专门说。1.3 功能模块划分与演进路线模块划分上我的建议是“一张图先画出来”。具体来说画出系统整体用例图模块划分标注清楚每个角色的操作权限边界。以一个典型的进存销系统为例模块可分为模块功能点涉及角色登录认证登录、退出、修改密码全部商品管理商品CRUD、分页查询、条件检索管理员、操作员供应商管理供应商信息维护管理员、操作员采购管理采购单创建、审核、入库登记管理员、操作员销售管理销售单创建、出库登记管理员、操作员库存管理库存查询、预警、盘点管理员报表统计销售报表、采购报表、库存汇总管理员角色的区分在后期论文写作中是很重要的一块也是体现系统设计完整度的重要加分项。开发路线上我强烈建议“先只做核心链路再补边角功能”。核心链路就是登录 → 商品管理 → 采购入库 → 库存变化 → 销售出库 → 库存再变化。这条链路通了系统真正的主心骨就立住了后面再补统计报表、权限细化、供应商/客户管理这些枝节。很多同学一上来扎进商品管理的增删改查里写得很精细结果采购和销售业务只写了个空壳最后整个系统看起来就是“带界面的CRUD”答辩时经不起追问。2. 数据库设计先把地基打扎实进存销系统的数据库设计是整个项目成败的关键。数据表之间的关系如果理不清后期写业务逻辑时一定会陷入混乱诸如“库存扣多了”“采购单审核后库存没变”这类问题多半都是表结构设计有缺陷。2.1 核心表结构与字段设计正常情况下一套完整的进存销系统数据库里会有这些核心表user用户表id、username、password、real_name、role、create_time。goods商品表id、goods_no商品编号、name、category、specification规格、unit单位、price进货价、sale_price销售价、stock库存量、lower_limit库存预警下限、supplier_id供应商外键、create_time、update_time。supplier供应商表id、supplier_no、name、contact、phone、address、remark。customer客户表id、customer_no、name、contact、phone、address、remark。purchase_order采购订单主表id、order_no、supplier_id、total_amount、status待审核/已入库、create_user、create_time、audit_time。purchase_order_item采购订单明细表id、order_id、goods_id、quantity、price、amount。sale_order销售订单主表id、order_no、customer_id、total_amount、status已完成/已出库、create_user、create_time。sale_order_item销售订单明细表id、order_id、goods_id、quantity、sale_price、amount。warehouse_log库存流水表id、goods_id、type入库/出库/盘盈/盘亏、quantity、balance操作后结余、order_no关联单号、create_time、remark。这里需要特别注意的是“主表明细表”的设计模式。采购订单和销售订单采用一主多明细的结构而不是把商品直接塞进订单表里。为什么一个订单可能包含多种商品如果把商品字段堆在主表里数据表就没法设计成固定结构。而拆成主表和明细表之后主表存订单的公共信息供应商、总金额、状态明细表存每一件商品的数量和金额这在数据库设计中叫“一对多”关系。这样做的好处是查询一张订单的完整内容时用订单ID关联明细表即可统计报表也可以基于明细表做分组聚合非常灵活。2.2 核心业务表之间的关联关系进存销系统四张业务核心表之间的关系可以简单连线商品表与供应商表多对一关系一个供应商可以供应多种商品商品表通过supplier_id关联供应商表。采购订单表与商品表通过明细表构成多对多关联一张采购单里可以包含多个商品一个商品也可以出现在多张采购单里明细表起到中间桥梁的作用。销售订单表与商品表同样是多对多通过销售订单明细表关联。商品表与库存流水表一对多每个商品的每次库存变动都会记录一条流水。这个关联关系在“概念结构设计”章节里要用E-R图把它画出来。我的建议是手画或用Visio画实体用矩形、属性用椭圆、关系用菱形画完后截图贴在论文里这是数据库设计章节的关键配图也往往是答辩时老师最先看的那张图。2.3 建库建表实操与注意事项建表时有一个很容易踩的坑金额字段误用float或double。钱这种东西用浮点数存储会出现0.1 0.2不等于0.3的问题报表统计金额时可能出现32.130000000000005这种诡异数字答辩时被问到会非常尴尬。正确做法是金额统一用decimal(10, 2)数量和库存用int或decimal根据需要选择不要随手全是int。在建表SQL脚本里建议统一加上建库语句、外键约束、索引建表完成后用订单号、商品编号这种查询频繁的字段建索引。外键约束在毕设里建议保留虽然性能上略有一点负影响但能在删除商品时防止出现“订单明细还引用着商品商品却被删了”的脏数据这种细节在论文里写一笔“通过外键约束保障数据完整性”是非常加分的。表结构设计完成后把建表SQL保存为init.sql文件这个文件在论文的“系统实现”章节中可以作为附录列出也是程序打包交付时数据库初始化的标准脚本。我习惯在建表脚本里同时插入测试管理员账号和几个示例商品、示例供应商方便后期测试时直接有数据可用不用每次都手动敲。3. SSM后端实操要诀后端是SSM三大框架整合的主战场。框架整合的配置过程确实繁琐但每份配置都有它存在的理由把原理理解到位比单纯复制粘贴配置文件要可靠得多。3.1 配置文件与Spring整合的思路SSM项目的标准配置文件通常包含这几份pom.xmlMaven依赖管理引入spring-webmvc、mybatis、mybatis-spring、mysql-connector-java、druid或c3p0连接池、jackson-databind等依赖。jdbc.properties数据库连接信息driver、url、username、password。applicationContext.xmlSpring的根容器配置开启注解扫描、配置数据源、配置SqlSessionFactory、配置事务管理器、配置Mapper扫描。spring-mvc.xmlSpringMVC的子容器配置开启注解驱动、扫描Controller、配置视图解析器实际操作中如果是前后端分离视图解析器可以不配。web.xml配置ContextLoaderListener加载Spring根容器配置DispatcherServlet加载SpringMVC容器。理解两份容器很关键Spring父容器负责Service、Dao、数据源这些底层的BeanSpringMVC子容器负责Controller层的Bean子容器可以读取父容器的Bean反之不行。这就是为什么Service能注入到Controller里而Controller不能被Service注入这个关系在答辩时就属于经典理论题。数据库连接池我比较推荐用Druid它的监控功能能在浏览器里看SQL执行情况对验证那些“为什么库存没更新”的问题很有用。Druid配置好后访问/druid/index.html就能看到监控面板非常适合答辩演示时现场展示“连接池状态”和“慢SQL记录”算是相当加分的细节。3.2 核心业务逻辑的代码组织SSM的分层模式非常标准Controller接收请求参数 → Service处理业务逻辑 → Dao访问数据库。进存销系统的核心业务主要分布在采购入库、销售出库和库存报溢报损三块。以“采购入库”为例最简化的流程是Controller接收到采购单主表数据和明细列表数据通常是一个JSON对象包含订单基本信息和items数组。Service接收后第一步校验商品ID是否存在、数量是否为正。插入采购订单主表记录拿到自增主键ID。遍历明细列表依次插入采购订单明细表每条明细关联主表ID。每插入一条明细同步更新商品表中的库存量stock stock quantity同时插入一条库存流水记录。如果采购单有状态字段如待审核 → 已入库入库完成时更新状态。整个方法加事务注解Transactional保证“主表插入成功但明细插入失败”时全部回滚。在这一步需要强调对应数据库的操作顺序必须是“先插主表再插明细再更新库存”。如果顺序反了或者漏了库存流水造成的现象就是“下单了但库存不对”这种Bug排查起来最浪费时间。我在辅导的时候见过好多同学把库存更新写在事务之外导致中途异常时订单回滚了库存却已经改了数据就乱了。再强调一个容易出问题的环节事务注解只对RuntimeException生效如果代码里捕获了异常并吞掉事务是不会回滚的。这个坑特别隐蔽我建议大家在Service层的核心入库/出库方法里不要用try/catch吞异常要么让异常抛到上层由全局异常处理器处理要么在catch块里手动调用TransactionAspectSupport.currentTransactionStatus().setRollbackOnly()强制回滚。3.3 MyBatis层的几个细节MyBatis的Mapper接口和XML文件的对应关系是很多同学写错的地方。几个关键点namespace必须与Mapper接口的全限定名一致参数占位符#{}会用预编译${}是字符串拼接涉及排序字段或表名时只能用${}但注意SQL注入风险业务查询条件优先用#{}。结果映射尽量不用自动驼峰转换依赖配置而是直接写resultMap字段多的时候虽然麻烦一点但可读性强得多也方便做关联查询。分页查询我的建议是直接用PageHelper插件引入依赖后在查询前调用PageHelper.startPage(pageNum, pageSize)查询后返回值接PageInfo即可得到total、pages等信息。这个插件在学校项目里使用范围很广论文里也可以在技术选型部分写一句“引入PageHelper实现物理分页”答辩时老师都懂不用多解释。查询列表需求中最常见的是条件组合搜索比如商品列表按名称模糊查、按分类精确查、按价格区间查。在Mapper XML里动态SQL标签就是解决这个问题的。核心写法是使用where标签包裹if条件判断统一把查询条件封装成一个Query对象传入Mapper。这样界面勾选哪些条件就传哪些字段SQL会自动拼接对应的where条件。4. Vue前端与前后端联调前端这部分很多Java方向的同学把它当“负担”但实际上Vue写起来反而比后端更容易看到成果做好了也是毕设展示环节中特别亮眼的部分。4.1 前端工程结构与页面规划我在做进存销系统时前端页面通常按模块划分成一系列View组件大致对应后端的Controller。一个基础但是完整的前端结构如下登录页login.vue提交账号密码到后端接收token存到localStorage或Vuex。布局组件layout.vue包含侧边栏菜单和顶部导航路由切换时内容区局部刷新。商品管理页goods.vue表格展示商品列表支持分页、条件搜索、新增/编辑弹窗、删除确认。供应商管理页、客户管理页、采购订单页、销售订单页结构类似但各自的字段和操作按钮不同。库存管理页show库存列表低库存预警高亮显示提供盘点操作按钮。报表统计页用ECharts展示近7天/近30天销售额折线图、分类销售额饼图等。页面规划的核心原则是“一个页面只做一件事”。比如采购入库页面不要揉进供应商管理和商品管理新增商品的入口放在商品管理页里采购页里只能选择已有商品。这样做的好处是前后端接口职责单一联调和论文描述都轻松很多。路由的配置要注意一个细节登录拦截。在路由守卫里全局判断如果用户没有token就跳转到登录页同时根据用户角色动态生成菜单权限。管理员能看到系统管理菜单普通员工看不到这样“权限控制”就能在论文里作为一个小亮点写出来了。4.2 接口设计与请求封装前后端分离的关键是接口约定。我强烈建议一边和后端联调一边写一个接口文档字段名、状态码、返回值结构统一先定下来避免前端要求返回“code”后端却给“status”这种低级混乱。统一返回结果我习惯的做法是后端包装一个Result对象code200表示成功500表示业务失败401表示未登录等。message提示文字让前端弹提示框直接使用。data承载具体数据可能是对象、列表或分页结果。前端请求封装时统一拦截status code如果code不是200就全局弹错误提示。axios拦截器统一挂在请求头上带token响应拦截器统一处理后端返回码这样每个页面就不用重复写错误处理了。这里推荐用一个比较稳妥的做法后端Controller直接返回Result对象而不要直接返回数据裸体。这样在答辩演示时如果前端发请求报错了打开浏览器F12能清楚看到后端返回的code和message排查起来非常快。很多半吊子项目返回格式不统一联调时前端根本不知道后端哪里错了。4.3 联调阶段的关键坑与避坑经验联调踩过最多的坑就是跨域问题。后端端口通常是8080前端开发服务器是9528或8081两边端口不同浏览器会拦截跨域请求。解决方式有两种第一种后端解决。在SpringMVC里配置CorsFilter允许跨域写一个配置类注册CorsFilter允许的源写http://localhost:9528允许的请求头带token。这种方案适合毕设代码清晰论文里也好解释。第二种前端解决。在vue.config.js里配置devServer.proxy将/api前缀的请求代理到后端地址。这种方案的优点是可以假装前后端同源不用在后端开跨域但代理配置稍复杂且最终部署时需要反向代理配合难度稍高。毕设阶段我更推荐第一种。另一个极易踩的坑是时间格式化。数据库datetime类型传到前端变成长字符串“2026-04-01T15:30:00”页面直接显示很不美观。我的经验是在后端配置全局Jackson格式化或者在实体类的日期字段上加JsonFormat(pattern yyyy-MM-dd HH:mm:ss)注解统一格式化输出。5. 论文架构与答辩准备毕设的论文和代码是同样重要的两座山甚至可以说论文决定分数的上限。代码全是自己写的但论文写得乱七八糟一样要吃亏。这里分享一套比较成熟也容易被认可的文章组织方式。5.1 论文的核心章节如何组织进存销系统论文的章节框架按我辅导的经验来排优先级标准结构大约是这样的绪论背景与意义、国内外研究现状、论文主要工作与结构安排。相关技术介绍SSM框架、Vue、MySQL、前端技术栈各写一小节介绍与发展历程。系统分析可行性分析、需求分析功能需求非功能需求、用例图与用例说明。系统设计总体架构设计、功能模块设计每个模块对应文字说明时序图/协作图、数据库设计概念结构E-R图、逻辑结构表结构说明。系统实现按模块划分小节每个小节贴核心代码片段界面截图功能描述建议每页至少有一张截图。系统测试测试环境、测试用例表、功能测试结果、性能测试简述。总结与展望一言概括做了什么指出不足和后续改进方向。这里我必须提醒一件事正文中的核心代码不要大段整体粘贴。每段代码截图或小段粘贴后要紧跟一段文字解释这段代码的业务意图以及关键逻辑的实现思路。比如截取采购入库Service层的代码后马上写“本方法接收采购订单表单数据通过事务控制保证订单主表和明细表以及库存更新的数据一致性”这种描述方式远比晒几十行代码更能体现你的理解。论文里需要画的图主要包括系统功能结构图、业务流程图、体系架构图、E-R图、时序图、用例图。Visio和在线绘图工具都可以画图时保持统一风格配色简洁不要这里一张深蓝背景图、那里一张白底黑线图。5.2 答辩时的核心讲法和提问预判答辩时间通常只有十到十五分钟不要闷头展示一堆页面要讲出系统的技术深度和业务亮点。我建议按“需求背景 → 架构设计 → 核心业务流程演示 → 数据库亮点 → 测试结果”这个顺序来讲。其他答辩高频问题一般包括这几类SSM框架中Spring如何管理对象Bean生命周期、IoC/DISpringMVC的工作流程DispatcherServlet如何分发到ControllerMyBatis中#{}与${}的区别预编译与拼接事务注解怎么实现回滚Transactional底层是AOP动态代理进存销中最复杂的业务点是什么一般是入库出库时库存一致性结合事务日志讲你的系统安全性如何保障用户密码加密、登录拦截器、参数校验对于这些问题我建议在答辩前把答案写在一页笔记上对着镜子自问自答两遍。技术上不求全求深但讲出来的必须是真实的、自己亲手实现过的。如果老师问到你确实没实现的部分坦诚说“由于时间原因这部分只做了基础功能后续可以扩展”这个答案比编造硬撑要体面得多。密码安全方面也是一处容易被提问的点。如果直接把用户密码以明文存进数据库答辩时老师有可能一针见血地指出这是安全漏洞。建议用MD5加盐或BCrypt对密码做哈希处理在Service层注册时加密存储、登录时比对密文。多加这十几行代码论文里的“系统安全性设计”一节就有了素材。5.3 论文与代码的一致性这一步是很多同学忽视但实际很重要的论文里出现的功能代码里必须存在代码里实现的功能论文里也不能完全不提。最典型的翻车场景是论文系统实现里写了“库存盘点功能”但实际程序根本没有盘点入口答辩老师一打开系统就发现了场面非常尴尬。我的建议是论文初稿完成后把论文里的功能列表单独提取出来逐个对照系统的菜单页面和接口验证一遍。如果论文写了某功能而代码里没有要么补功能要么删描述选哪一个取决于距离答辩还剩多少时间。宁可做到“功能少但真实”也不做“功能多但说谎”。另外论文里的“系统测试”章节也容易被轻视。测试不要只写一句“系统运行正常”而是要按功能点列出测试用例表格包括测试项、操作步骤、预期结果、实际结果、是否通过五列每个核心模块挑两三个用例实际执行一遍并保存测试截图。这套流程本身就能让答辩老师感受到你的工程规范意识。6. 实测中踩过的坑与排查经验这部分是我最想分享的内容。SSMVue进存销系统这套组合我在辅导过程中实际遇到过不少问题很多是教材和博客里不会写清楚的。把这些坑记录下来能帮大家省下很多调试时间。6.1 依赖与版本兼容问题SSM的老搭档之间版本兼容很敏感最典型的是Spring 5.x和MyBatis-Spring 1.x不兼容启动时报循环依赖或找不到SqlSessionFactory。我的经验是直接用Spring 5.3.x MyBatis 3.5.x MyBatis-Spring 2.0.x这组组合经过实测稳定性较好Maven依赖只要锁定大版本互相匹配即可。另一个常见问题是JDK版本过高导致很多依赖出错。说实话毕设阶段JDK 8 Maven 3.8 Tomcat 8.5是这个技术栈的稳定组合老师大多也是按JDK 8讲的环境问题就少很多。不要盲目追新换JDK 17新版本在一些老依赖下会出现编译错误或反射访问报错这个时间成本不值得浪费。前端依赖方面Node版本也不宜过高Vue CLI 5和Vite都有Node版本限制。装好环境后建议先跑一遍vue --version和npm run serve验证不然装了半天才发现node_modules依赖带不下来排查起来真的很费劲。6.2 乱码问题的根源与处理乱码问题在Java Web项目里是经典中的经典尤其在Windows环境下。乱码本质上就是编码不一致Tomcat处理请求流的默认编码可能是ISO-8859-1MySQL表默认字符集如果你建表时没指定UTF-8而页面提交的是UTF-8两边一对不上就会出乱码。我的排查路径是固定的三件套页面层面HTML里指定meta charsetUTF-8axios请求头加Content-Type: application/json;charsetUTF-8。Tomcat层面修改server.xml连接器配置加URIEncodingUTF-8确保GET请求中文参数不慌乱。数据库层面建库时用CREATE DATABASE 库名 DEFAULT CHARACTER SET utf8mb4表同样指定utf8mb4。注意mysql-connector-java的url带useUnicodetruecharacterEncodingutf8参数。这里还有一个很细节的坑如果你用Druid连接池url中的characterEncoding必须放在参数第一位否则可能读不到。这类参数问题遇到的时候可能根本想不到建议直接照抄稳定配置。6.3 调试技巧与日志分析遇到Bug只会看界面报错、不会看日志是新手出问题时最大的障碍。其实绝大多数后端问题都能从控制台日志里找到答案。我建议在项目里配置log4j或logback日志mapper接口和XML包名配置成debug级别这样MyBatis执行的SQL语句和参数都会打印出来。只要看到SQL长啥样就基本能判断是参数传错还是SQL写错。另外一个实用的排查习惯是前端调用后端接口出现500错误时先看后端控制台有没有打印异常栈。如果Controller里抛出了NPE却只返回500提示“服务器错误”这个提示对排查帮助不大异常抛到控制台才能定位。还有数据库查询结果没问题但页面不显示优先怀疑JSON序列化问题。比如实体类属性名和前端字段对不上或者后端返回了空对象被前端取字段报错。这时打开F12的Network面板看响应体是什么就很容易明白是前端字段名拼错了还是后端返回少了字段。前后端分离项目的调试核心工具就是浏览器F12面板看懂Network和Console等于解决了一半问题。6.4 时间管理上的建议顺带说一句毕设时间管理很多同学从春天拖到五月才发现进度还在零然后熬夜赶工质量可想而知。按我辅导的经验一个顺利的SSMVue毕设周期大概是四周第一周完成需求分析和数据库设计第二周完成后端核心接口第三周完成前端页面和联调第四周写论文、调格式、准备答辩。把任务拆到周粒度每一步都有产出比集中突击可靠得多。我还有一个实操建议开发过程中阶段性地提交一次代码最好用Git每次提交信息写明“完成采购入库接口”或者“完成商品管理页面”。这样一方面是给自己留后路出错时可以回退另一方面答辩如果被问到“你是怎么保证项目质量的”你说“用Git做版本控制每次功能通过后提交”这是一个非常职业化的回答导师也会认可。7. 写在最后的几项检查清单临近交付时我习惯按这份清单过一遍基本上没有漏网的代码结构是否完整是否有人名、路径残留或无用测试代码。前端页面在无接口环境下是否报错接口异常是否有友好提示。数据库初始化脚本能否一键导入导入后是否有基础演示数据。核心流程登录→采购入库→库存增加→销售出库→库存减少是否完整跑通。论文里的每张截图是否清晰无水印是否和当前代码版本显示功能一致。这套检核流程帮我避过不少坑。上一次带某位同学做类似项目时我让他把初始化脚本删掉重跑一遍数据库再点开前端结果发现他漏了一条商品分类的插入语句聪明的是他写这篇内容时故意在文末留出复盘说自己把校验逻辑重排了一遍才算完整跑通。计划总赶不上变化用清单兜底比盲目自信可靠。进存销系统好的地方在于业务逻辑不复杂但也不浅薄足够把SSM、Vue、数据库设计、测试这些技术点都展示出来。把这份项目吃透你答辩时的底气绝对不一样。如果你正在做或者准备做这个题目照着这份路线图走稳扎稳打应该不会翻车。最后再分享一个小技巧核心业务模块写完一遍后专门用半天时间做一次全流程串联测试把“登录→采购→销售→查库存”当成一个连续故事过一遍你会发现很多平时没注意到的细节问题——这时候发现并修掉胜过答辩前夜崩溃。