企业官网建设流程全解析

1. 血站业务到底在管什么：系统设计必须从业务流程说起

做这个项目之前，我先把血站的日常业务从头到尾捋了一遍。很多人拿到题目就开始建表写代码，结果做到一半发现业务流程对不上，返工成本极高。血站不是普通的企业进销存，它既管"人"（献血者），又管"物"（血液制品），而且血液是特殊商品，有严格的效期要求、检验要求和追溯要求，冷链存储、报废处理、紧急调配都是刚需，所以业务流程梳理是第一优先级的事情，代码是后话。

一个完整的血站信息系统，核心业务线大概可以分成这几条：献血者管理、血液采集记录、血液检验管理、库存出入库管理、医院用血申请与发血、报废管理、统计报表。下面我把每一条的具体业务内容展开说一下，因为后面所有的表结构设计、接口设计、页面设计，都是从这些业务点上推导出来的。

献血者管理的核心不是简单存一个名字和电话，而是要存身份证号、血型、体重、健康征询情况、既往献血记录、最近一次献血的日期。这里面最关键的逻辑是献血间隔期管控。全血捐献间隔期是6个月，成分献血（比如血小板）间隔期是14天，系统需要在登记的时候自动校验，距离上次献血的日期不足间隔期就直接拦截，不允许再次登记。这个校验逻辑放后端做，前端只做提示，因为接口是可以被直接调用的，不能依赖前端判断。

血液采集记录这条线，要记录的是采血袋编号、采血日期、采血量、采血护士、采血地点、献血者关联、血液状态。采血袋编号在血站叫"血袋条码"，是全国统一的采供血信息标准里的核心追溯标识，一袋血从采集、检验、入库、出库到最终去向，全部靠这个条码串联。所以血袋编号在系统里必须是唯一索引，而且生成规则要有意义，不能随便用自增ID代替，通常用"采血日期+流水号+校验位"的方式拼。

检验管理这条线更特殊。血液采集之后必须经过检验才能入库，检验项目包括ALT转氨酶、乙肝表面抗原、丙肝抗体、艾滋抗体、梅毒抗体等，而且按照国家规定，很多项目要做双检，也就是两套试剂各做一遍。检验结果有三种逻辑状态：合格、不合格、待检。不合格的血液要转入报废流程，合格的才能贴合格标签入库存放。系统设计检验模块时，不能只做一个"填结果"的页面，要留出检验批次、检验项目、检验日期、检验人员这些字段，并且要有"不合格自动联动报废流程"的业务逻辑。

然后是最核心的库存管理。血液入库之后，按血型（A、B、AB、O）、按Rh阴阳性、按成分（全血、悬浮红细胞、血浆、冷沉淀、血小板）分库存放。每一袋血都有独立的效期，红细胞类一般35天，血浆冷冻保存可以到1年，血小板只有5天左右。所以系统的库存表必须有效期字段，出库必须按照"效期优先"的先进先出原则来选单，不能想拿哪袋拿哪袋，这是血站行业的基本合规要求。另外库存要有预警机制，效期剩余天数低于阈值（比如3天）就要高亮提醒，过期血液必须自动变成报废状态，不能继续参与出库。

医院用血申请与发血这条线，是血站系统的对外出口。医院提交用血申请单，填写用血类型、血量、患者信息、预约取血时间，血站工作人员审核通过之后，匹配库存血液出库，生成发血记录。发血之后这袋血就变成"已出库"状态，同时关联到医院、患者、取血人。这里涉及的一个细节是血液追溯闭环：从献血者到血袋到检验到出库到患者，全链路要能查得通，这也是卫计部门对采供血信息系统的硬性要求。

报表这块不需要多花哨，但必须要准。常见的报表有月度采血量统计、各血型库存汇总、血液报废率分析、医院供血排行、献血者分布统计等。这些报表的数据来源多是综合多张表的查询，写SQL的时候要注意统计口径一致，比如"报废率"的分母是采集总量还是入库总量，这个要和业务方确认清楚，否则做出来的报表数据别人不敢信。

说到这里，其实你已经能感受到，这套系统的难点根本不在技术框架，而是在业务状态的流转管理。一张表做出来容易，但状态之间的流转规则、联动逻辑、约束条件，才是真正的工作量所在。我建议第一周先做业务梳理和需求文档，把所有角色、所有状态、所有操作列一个矩阵，确认了再动手建表，比边写边想靠谱得多。

2. 技术选型复盘：SSM+Vue这个组合为什么适合毕业设计

这个题目用的是SSM加Vue的技术栈，也就是Spring、SpringMVC、MyBatis三个后端框架，加上前端Vue框架。很多人纠结要不要用更"新的"技术，比如Spring Boot加MyBatis-Plus，或者前端用Vue 3加TS，我说一下我的看法。

先说SSM这套组合的定位。Spring负责IoC容器和AOP事务管理，SpringMVC负责请求路由和参数绑定，MyBatis负责数据库访问和SQL映射。三者分工清晰、各管一摊，对于理解Java Web开发的经典分层架构非常有帮助。Spring Boot确实简化了配置，但它是"封装好了让你少写代码"，而SSM是"配置都摆在你面前让你理解原理"。作为毕业设计，评审老师要看你是真的理解框架，还是只会套脚手架，SSM的配置过程本身就是一种能力展示。我见过太多用Spring Boot写完全程却讲不清楚自动配置原理的人，答辩时一问就露馅，而搭过一遍SSM的人，对Bean生命周期、MyBatis代理机制、DispatcherServlet工作流程都能说出个一二三，这个差异在答辩现场非常明显。

再说MyBatis。用它做数据访问有个好处，SQL写在XML映射文件里，复杂查询的可读性和可调优性都很强。血站系统恰恰是一个重SQL查询的业务系统，比如按血型汇总库存、按日期区间统计采血量、查某袋血的完整追溯链路，这些场景用MyBatis手写SQL反而比MyBatis-Plus的链式查询更直观。而且PageHelper做分页、批量插入、动态SQL，这些在MyBatis里都是成熟的生态，资料多、坑少，适合毕业设计的时间周期。

前端为什么选Vue而不是其他方案？核心原因是Vue 2加Element UI的组合在毕业设计场景里几乎是最稳妥的。Element UI的表格、表单、弹窗、日期选择器、树形控件开箱即用，后台管理系统的风格高度统一，把精力放在业务实现上，不折腾样式。Vue的响应式机制、组件化开发、生命周期钩子，也足够你在论文里写出"前端采用MVVM模式"这种有内容的话。用原生JavaScript写后台管理系统不是不行，但工作量大且代码零散，答辩展示效果也远不如组件化方案。如果你对Vue 3熟悉，用Vue 3加Element Plus也可以，但要注意Element Plus和Vue 2的组件API有些差异，网上资料数量上前者略少，踩坑时解决慢，预算时间不充裕就别折腾。

还有配套选型也要一起定。数据库用MySQL，版本选5.7或8.0都行，注意驱动和连接串的差异。构建工具用Maven，依赖管理方便，一人一机开发也不需要复杂的多模块拆分，单模块工程足够。JDK用1.8，这是SSM时代最常见、兼容性最好的版本。服务器用Tomcat 8或9，和Spring生态配合顺畅。前端工程用Vue CLI创建，开发环境下通过proxyTable把请求代理到后端Tomcat端口，省去跨域配置的麻烦。

这套技术栈我实测下来，从零搭建到前后端联调跑通，一个熟悉开发流程的人大概需要一周左右，剩下的时间全部集中在业务功能开发上，进度完全可控。不要小看"可控"这两个字，毕业设计最大的风险不是技术难点，而是时间不可控带来的焦虑。框架选得再响亮，做不完也是白搭，稳才是第一位的。

3. 数据库设计：血站系统的表结构怎么落地才不返工

数据库设计是整个项目里我最想强调的部分。血站系统的表不多，一般十来张，但表与表之间的关联关系比普通管理系统复杂，而且有很多业务约束要靠表结构来承载。我按模块把核心表设计思路拆开讲，实际动手建表可以参考这个顺序来。

第一类是用户权限表。用户表（sys_user）存用户名、密码、姓名、角色、状态、创建时间。角色可以用一个字符串字段区分（管理员、工作人员、检验人员），不用单独做角色表、权限表、用户角色关联表那种经典RBAC五表结构，因为毕业设计场景下功能权限不需要细粒度到按钮级别，只做页面访问控制就够了，查起来简单，答辩也能讲清楚。密码存储用MD5加盐或者BCrypt，论文里写一句"密码经过加密存储，避免明文泄露"就是加分项。

第二类是献血者表（donor）。字段包括姓名、性别、身份证号、出生日期、手机号、血型、体重、最近献血日期、献血次数、状态。身份证号做唯一索引，这个字段在实际业务里经常用来查出历史献血记录，查询频率极高。注意前端展示时身份证号要做脱敏处理，只显示前3位和后4位，这是个人信息保护的基本要求，写进论文也是亮点。

第三类是献血记录表（donation_record）。字段包括献血者ID、血袋编号、采血日期、采血量、采血类型（全血/成分血）、采血护士、采血地点、体检结果、初筛结果、状态。血袋编号设唯一索引，和献血者表关联。这里有一个设计细节：一个献血者可以有多次献血记录，每次献血记录生成一个独立血袋编号，之后所有血液流转都以血袋编号为主线索，这个设计一定要从一开始就明确，否则后面追溯链就断了。

第四类是检验记录表（blood_test）。字段包括血袋编号、检验项目、检验结果、检验方式、检验日期、检验人员、报告单编号。实际业务中一袋血要做多个检验项目，所以这个表不能设计成一行一袋血，而是一行一个检验项目，多条记录通过血袋编号关联到同一袋血。查询某袋血是否合格，就查这个表里有没有不合格项目。

第五类是库存表（blood_bag），这是全系统最核心的一张表。字段包括血袋编号、血型、Rh因子、成分类型、容量、采集日期、失效日期、入库日期、存储位置、状态、关联的献血记录ID、检验结论。状态字段用整数或字符串表示，0待检、1在库、2已预约、3已出库、4已报废，这个状态值贯穿整个系统的所有操作逻辑。废置日期是冗余字段，但这个冗余非常有必要，因为效期预警和过期报废都要用它，如果每次现算会很麻烦。

第六类是医院用血申请与发血表。用血申请表（hospital_request）存申请单号、申请医院、患者信息、用血成分、血量、申请日期、状态；发血记录表（blood_issue）存申请单号、血袋编号、发血日期、发血人、取血人、备注。发血记录表和库存表通过血袋编号关联，发完血后库存状态同步更新。

这套表结构落下来之后，你会发现所有业务操作都能用"修改状态加插入记录"的方式来表达，比如入库就是把blood_bag的status从待检改成在库，出库就是先把status改成已出库再插入一条blood_issue记录。状态机清晰，事务边界也好控制。我在设计表的时候还有一个习惯，每张表都加上create_time和update_time两个字段，MyBatis里设置自动填充，对调试和追溯都非常有帮助。

4. 后端实现：权限拦截、效期预警、出库事务这三个点讲透了

后端开发里，CRUD接口是基础，每个人的写法都差不多，我不多废话。真正值得花心思的是三个点：认证与权限拦截怎么落地、效期预警怎么实现、出库发血的事务边界怎么划。这三个点做好了，系统就立住了。

4.1 登录认证与权限拦截的实现思路

SSM项目里做登录认证，最经典的做法是用SpringMVC的HandlerInterceptor写一个拦截器，拦截所有请求，判断Session里有没有登录用户。我在项目里是这样处理的：登录成功后把用户对象放进Session；写一个LoginInterceptor，在preHandle方法里判断Session是否为空，为空就重定向到登录页；再写一个配置类继承WebMvcConfigurer，注册拦截器，同时排除登录接口、验证码接口和静态资源路径。

角色权限控制我用的方案是在拦截器基础上加菜单权限过滤。具体做法是：登录成功后，根据用户角色从数据库查出可访问的菜单列表，用List 存起来放进Session；前端页面加载时调用一个"获取当前用户权限菜单"的接口，拿到菜单列表后动态生成侧边栏菜单并注册路由。这个方案比在拦截器里写死的角色判断灵活，后端加一种角色只需要在菜单表里配好父子关系就可以，不需要改代码。当然如果你不想做动态菜单，也可以直接在视图层写v-if="role === 'admin'"的硬编码判断，功能上没毛病，就是答辩时不够好看。

4.2 效期预警：不要只做一个"查询过期血"的接口

效期预警是血站系统的特色功能，也往往是毕设里最容易做浅的功能。很多人实现成"查一下库存表里有没有过期血"，然后列表标红，完了。但实际上预警应该分层做：第一层是过期血液自动识别，也就是查询SQL里直接处理失效日期小于当前日期的记录，这些血液自动视为报废状态，不允许出库；第二层是临近效期提醒，失效日期距当前时间小于3天的记录，在列表里高亮显示，同时在首页放一个"临期血液预警"的面板，让工作人员一登录就能看到；第三层是批量操作，对已过期血液提供一键报废功能，调用后端批量更新状态并生成报废记录。

这三层逻辑不复杂，但做出来之后功能完整度明显不一样，答辩演示的时候也更有话说。SQL方面，临期查询就是失效日期在"当前日期"和"当前日期加3天"之间，用BETWEEN就能实现，注意日期格式化要统一，否则查出来的数据边界会对不上。

4.3 出库发血的事务边界怎么划

发血出库是我在代码里最小心处理的一个操作，因为它涉及多张表联动。一次完整的发血逻辑是这样：先查申请单状态，必须为"审核通过"才允许发血；再查库存里有没有符合条件的血液，按照效期优先原则排序取最早的一袋或多袋；选好后校验血液状态必须为"在库"；然后开启事务，先更新blood_bag的状态为已出库，再插入blood_issue发血记录，最后更新blood_request状态为已发货。这三步任何一步失败都要整体回滚，否则会出现"库存发了血但发血记录没写"这种数据不一致。

事务用Spring的@Transactional注解在Service层方法上声明即可，注意事务要加到public方法上，并且要确保方法内部异常能正确抛出，不要自己用try-catch吃掉了异常还指望事务回滚——这是最常见的坑。排查事务不生效的问题时，优先看代理是否生效，也就是Service实现类的方法是否被外部调用，内部自调用会导致事务失效，我当年排查了半天才意识到是在同一个类里调了带事务的方法。

4.4 关于批量入库的合理写法

血液入库的时候通常是一批血一起入，比如一上午采集了50袋血，检验合格后批量入库。我的做法是Controller接收一个列表参数，Service层循环处理，每袋血生成记录、更新状态。数据量不大（一次几十条），循环插入完全够用，不追求极致的批量插入性能。如果要用MyBatis的foreach批量插入，注意在JDBC连接串上加rewriteBatchedStatements=true，否则MySQL的批量插入并不会真正合并执行，性能提升有限。这个细节属于隐藏加分项，写进论文实用章节非常有说服力。

5. 前端实现：Vue+Element UI的页面组织与联调经验

前端这块我的整体思路是"少写组件，多拼页面"。Element UI已经提供了足够完善的基础组件，我需要做的主要是页面的组装、状态管理和接口请求的封装。下面把前端工程结构和几个通用的实现方式说一遍，这些经验放到任何后台管理系统项目里都适用。

5.1 前端工程结构与路由配置

用Vue CLI初始化工程之后，我按功能模块组织目录：api目录统一放接口请求方法，按后端Controller模块拆分文件；views目录按页面模块划分，比如donor文件夹放献血者相关页面，blood文件夹放库存和出入库页面，report文件夹放统计报表；router目录配置路由表，登录后动态拼接权限路由；store目录用Vuex管理用户信息和菜单状态。这个结构网上各种后台管理模板大同小异，重点是要从项目一开始就定好，后面加页面就是往对应目录里放文件，不需要动框架。

路由守卫是登录验证的关键防线。我在main.js里的路由守卫中做了两层判断：第一层，判断访问路径是不是登录页，如果是就直接放行；第二层，判断store或localStorage里有没有token或用户信息，没有就去跳登录页，有就放行。同时，对于有角色权限区分的页面，在路由meta字段里配置需要的角色，守卫里进一步判断当前用户角色是否匹配，不匹配就跳403页面。这样前端虽然不能作为安全边界，但至少能保证没有权限的人看不到页面入口。

5.2 列表页和表单页的通用写法

后台管理系统80%的页面都是"列表加搜索加新增编辑删除"这种形态。我总结了一个通用套路：列表用el-table，数据从后端分页查询接口获取；搜索区用el-form的inline模式，放日期范围、关键字输入框、状态下拉框这些常用条件；新增和编辑共用一个el-dialog里的el-form，通过一个isEdit变量区分提交走新增接口还是更新接口；删除操作先弹确认框，确认后调删除接口，成功后再刷新列表。

这种写法意味着每个模块页面的代码结构高度相似，好处是开发速度快、bug概率低，但也带来一个问题：阅读代码的人会觉得重复度高，不够"漂亮"。所以我在项目里额外做了一件事：把分页组件的逻辑抽成一个PaginationBar组件，把搜索表单的提交逻辑封装成通用的queryData方法。这样代码里既有标准化的重复部分，也有自己封装的部分，论文里能写"封装通用组件提升开发效率"，答辩老师也挑不出毛病。

5.3 前后端联调最容易踩的几个坑

联调阶段我踩了几个比较典型的坑，列出来给后来者提个醒。第一个是跨域问题。开发环境我在vue.config.js里配置了devServer的proxy，把/api前缀的请求代理到后端Tomcat地址，所以开发时不需要后端额外处理跨域。但如果后端在某些接口上配置了CORS响应头，和proxy混用就可能出现重复跨域头，表现为浏览器控制台报错，解决方式是一边只保留一种方案。第二个是日期格式传输问题。Java后端返回的Date类型默认序列化成时间戳或者"yyyy-MM-dd HH:mm:ss"这种字符串，前端小端接收之后显示格式可能不对，正确做法是后端在实体类的日期字段上统一加@JsonFormat注解指定格式，前端这边除非有特殊需求，不要再二次格式化，否则格式会乱。第三个是数据字典不下发。比如血型、成分类型、血液状态这些字段，前端展示时需要对应的中文名称，如果后端直接返回的是A、B、AB、O这种code，前端就要自己维护一个字典映射，我的做法是后端提供一个数据字典接口，前端在全局加载一次放进Vuex，所有下拉框和表格列都用这个字典渲染，保证数据源统一。

6. 实测踩坑：从"能跑"到"好用"需要修正的细节

这个项目做完之后，我一个人对着演示流程反复跑了很多遍，发现了很多"功能上没错但体验上别扭"的细节。这些坑不致命，但如果不改，答辩演示的时候就会漏怯。我挑几个典型的分享一下。

第一个是搜索条件的日期范围翻页丢失。这是最容易出现的低级bug：页面上的搜索条件明明选了日期，翻页之后日期条件没了，查询结果变成全部数据。根本原因是分页组件翻页时只带了页码参数，没有带上搜索表单的完整条件。解决方式是在分页change方法里把searchForm整体作为参数传给queryData方法，翻页时重新按完整条件查询，同时注意清空筛选条件时要把页码重置为1，否则会存在"当前页超出总页数"导致列表空白。

第二个是血液状态的颜色标识。库存列表里状态字段直接显示"1""2"这种数字，测试的人看一眼是看不到风险的。我在前端做了一层状态渲染映射，在库显示绿色标签，临期显示橙色标签，过期显示红色标签，已出库显示灰色标签。这个改动很小，但是视觉上信息传递的效率提升非常明显，演示时用户能一眼看出系统有预警能力，比口头解释"这里有预警功能"有说服力得多。

第三个是重复点击提交按钮导致的数据重复。在献血者新增表单，用户连点两次确定，后端的插入接口被调用两次，身份证号有唯一索引还好，如果是新增一条没有唯一约束的记录，就会产生重复数据。我的处理方式是前端在提交方法里加一个submitting标志，提交中置为true，按钮禁用，请求结束后再复位；同时后端在关键插入方法上做防重校验，比如献血者按身份证号先查再插，双保险。这个问题在很多项目里都存在，答辩老师也经常问"你怎么防止重复提交"，提前处理好了就能答得从容。

第四个是演示数据要用真实感强的假数据。我开发测试用的是"张三""李四"这种名字，但答辩演示的时候显得很不专业。后来我生成了一批格式规范的假数据：姓名是两个字的真实感名字，身份证号按18位标准格式生成，血型分布符合真实人群比例（O型最多、AB型最少），采血日期分布在最近三五个月内，失效日期根据各成分的实际保存期限自动计算。演示时页面一打开，数据就自然、可信，评委第一印象完全不同。这个小细节强烈建议每个人都花时间去准备，数据质量不行，系统功能再全也白搭。

第五个是操作日志。一开始我觉得有操作日志功能更好，但因为时间紧就放下了，后来发现没有日志有个很尴尬的场景——演示的时候如果误操作了一张数据，没有痕迹可查，只能手动改库。加一个简单的操作日志表，在Service层记录关键操作（操作人、操作类型、操作对象、操作时间、操作详情），成本很低，但对系统的完整性描述帮助很大，论文里"系统安全性设计"一节也能多写几段。

7. 论文写作与答辩准备：LW文档怎么写出含金量

毕业设计除了系统代码，还要交论文，也就是标题里的"LW文档"。很多人的系统做得挺好，论文却写得像流水账，答辩的时候讲不清楚设计思路，很可惜。我根据自己的经验，把论文的写作逻辑和答辩的准备要点梳理一下。

论文的结构每家学校要求大同小异，核心章节一般是：绪论（选题背景与研究意义、国内外研究现状）、需求分析（可行性分析、功能需求、非功能需求）、系统设计（总体架构、功能模块设计、数据库设计）、系统实现（核心功能模块的实现细节）、系统测试（测试用例与测试结果）、总结与展望。写的时候要注意，不要写成"代码说明书"。太多人把系统实现一章写成贴代码加一行注释，比如"这段代码调用了一个方法实现添加功能"，这种写法不仅没有信息量，答辩还容易被追问到底层原理，一问就慌。正确的写法是：先讲清楚这个模块的业务规则，再讲设计思路（为什么这么设计），最后用关键代码片段佐证设计，而且代码只贴核心片段，用文字解释关键逻辑，而不是整段贴上去凑字数。

数据库设计章节是最好拿分的部分。我的做法是：先用E-R图画出实体关系，再对每张核心表做表结构说明，字段名、字段类型、约束、说明列清楚。重点讲清楚表之间的关联关系和关键索引的作用，比如血袋编号的唯一索引、身份证号的唯一索引、库存表的失效日期索引（用来做效期预警查询）。这些内容体现的是你真正设计了数据库而不是随手建表，评委很看重这一点。

测试章节不能只写"系统运行正常"。要设计具体测试用例，包括正常场景和异常场景。比如献血间隔不足时新增献血记录，系统应该返回提示还是接受数据？过期血液执行出库操作，系统是否拦截？这些用例表格列出来，每一条写明前置条件、操作步骤、预期结果、实际结果、是否通过。测试数据要用前文说的真实感假数据，并且记录测试过程中发现的问题和修复情况，这部分写好了，论文的完整度和真实度都上一个台阶。

答辩准备我有几个实战建议。第一，准备一个5到8分钟的演示脚本，按照"登录-首页数据概览-核心业务操作为主线-报表展示"的顺序走，确保每一步点击都顺畅，不要在现场临时想点哪里。第二，准备几个高频追问的答案：为什么选SSM加Vue、数据库为什么用MySQL、表之间的关联关系是什么、出库事务怎么保证一致性、效期预警怎么实现的。这类问题都是围绕你的设计决策来的，只要你不是照抄代码，都能答出来。第三，对自己的代码要熟悉到能指到哪说到哪，答辩老师随机打开一个文件让你讲，你不能懵，平时多整理一下自己每个功能模块的核心代码位置。

还有一个很实用的技巧：论文的"总结与展望"不要写空话。不要写"随着信息技术的发展，本系统将会更加完善"这种废话。要写具体的不足和后续改进方向，比如"当前系统未实现血袋全流程条码扫码追溯，后续可以接入扫码设备实现RFID管理""库存预警目前只支持按天粒度，后续可以接入实时冷链监控温度数据"。既诚实又有专业深度，比任何套话都加分。

8. 最后想说的几点实在话

做这类管理信息系统项目，最重要的教训就是：先理解业务，再动手写代码。血站系统看起来是一个常规的管理系统，但真正接触下来你会发现它的业务规则有一堆讲究，比如效期优先、间隔期校验、追溯闭环、双检管理，任何一个环节做漏了，系统表面上照样能运行，但行业里真正使用的人一眼就能看出问题。毕业设计的评分差距，很大程度上就体现在这些"业务深度"的细节上。

另外一点是时间管理。我给自己的节奏是：第一周梳理业务和建库，第二周完成后端基础框架和用户权限模块，第三周做完核心业务模块（献血者、采集、检验、库存），第四周做出库和报表，第五周写前端页面并联调，第六周整理论文和演示数据，最后留一周缓冲处理意外。实际执行下来发现出库和报表比预想的耗时，因为涉及多表联查，SQL要反复调，建议大家给这两个模块多预留一点时间。

如果你也正在做类似的系统，希望这篇总结能帮你少走一些弯路。系统本身的技术难度不高，真正的门槛是对业务流程的理解程度和执行过程的细心程度。把基础功能做得扎实，把业务规则落实到位，把测试数据准备充分，这套毕业设计就能稳稳拿下。