1. 项目整体设计思路与需求拆解
1.1 校园食堂供应链业务的核心痛点
大学校园食堂和后厨供应链，看似只是“买菜、做饭、卖饭”三个环节，实际跑过一遍流程的人都知道，这里面藏着大量琐碎且容易出错的细节。我刚接触到这个“校园食堂供应链管理系统”的模拟项目X时，第一反应并不是急着去看代码，而是先把食堂日常的业务链条捋了一遍。
食堂日常经营活动会涉及几个角色：负责后勤管理的后勤管理员、专职采购员、仓库库管员、外部供应商，以及前端档口的经营人员。传统模式下，各角色的沟通方式基本靠纸质单据和微信群消息，采购申请用一张Excel表传来传去，供应商资质靠手里一沓复印资料，库存盘点全凭库管员的记忆和纸笔记录。这种模式最典型的三个问题：一是采购计划与库存实际消耗脱节，造成某些食材积压过期，另一些食材临开餐前才发现断货；二是对供应商的评估没有量化数据，只能凭感觉选择，价格、到货准时率、质量合格率全部是模糊状态；三是月末对账时，食堂经理面对一堆纸质单据和零散电子表格，需要加班逐笔核对，效率极低。
这个系统要解决的核心问题，就是把这些散落在各个角色手里的信息流整合到一条线上：从供应商管理、采购计划、订单审批、到货验收、入库登记、库存预警、领用出库，到报损处理和经营报表，全链路数字化。系统最终的价值不是“把纸质表格搬到网页上”，而是让每一个环节都有据可查、有数可依，让食堂管理者能够在数据基础上做决策，而不是凭经验拍脑袋。
1.2 系统功能边界与模块划分
从标题“校园食堂供应链管理系统”可以看出，这个系统的关键词有两个：一个是“校园食堂”，意味着业务规模和操作习惯要符合高校场景——多个食堂、多个档口、寒暑假暂停营业等特殊情况；另一个是“供应链”，说明系统的核心不是前端点餐，而是后端的采购、库存、供应商全链路管理。
梳理需求后，我最终把系统划分为六个核心模块：供应商管理模块负责供应商档案、资质证照、供货品类与历史评价；采购管理模块负责采购计划的编制、审批流、订单生成与到货登记；库存管理模块负责入库、出库、库存查询、报损登记和盘点；预警管理模块负责库存上下限检测、保质期提醒；报表管理模块负责采购统计、供应商评估、库存周转分析；系统管理模块负责用户、角色、权限和日志。这六个模块相互关联，又保持相对独立，便于后续扩展和二次开发。
在开发这个项目之前，我专门做了两件事：第一件是绘制核心业务流程图，把供应商供货、采购验收、库存出入库的主流程完整走一遍，确认每个环节的前置条件和后续操作；第二件是梳理“异常场景”——临时加急采购怎么处理、到货数量与订单不一致时如何记录、食品临期时系统怎么提醒。这些场景如果不在设计阶段考虑清楚，开发到后期再补逻辑，往往要返工。
2. 技术选型与工程结构解析
2.1 为什么选 Spring Boot + MyBatis-Plus
技术选型是开发的第一步，也是很多新手最容易纠结的一步。这个项目我最终确定的技术栈是：Spring Boot 2.7.x 作为后端基础框架、MyBatis-Plus 作为持久层框架、MySQL 5.7 + Redis 作为数据存储、Vue 2 + Element UI 作为前端、JWT 实现无状态登录、ECharts 实现报表可视化。
选择 Spring Boot 的理由很直接：它提供了自动配置能力，大大减少了 XML 配置量，内嵌 Tomcat 后，一个命令就能启动整个后端服务。对于这种典型的业务管理系统，Spring Boot 的生态足够成熟，网上资料多，遇到问题也好排查。
持久层选 MyBatis-Plus，而不是原生 MyBatis 或 JPA，是因为它兼顾了开发效率和灵活度。业务系统中大量操作是单表 CRUD，MyBatis-Plus 的 BaseMapper 直接提供了 insert、deleteById、selectPage 等通用方法，我几乎不需要为每个实体手写 XML 映射文件；而一旦遇到多表关联的复杂查询，比如“按供应商统计月度采购金额”，我又可以自己写 SQL，使用 @Select 注解或 XML 文件实现精准控制。对比 JPA 的学习成本和 SQL 可控性，MyBatis-Plus 对国内团队更友好，也是当前招聘市场上最主流的技能要求之一。
关于前端，我没有选择前后端不分离的模板渲染方案，而是拆成独立的前端工程。这样做的好处非常明显：前端专注于页面交互和展示，后端专注于接口和数据逻辑，团队协作时可以并行开发。同时，独立部署的前端工程将来如果要接入小程序或移动端，后端接口可以无缝复用，不需要重写。
2.2 工程目录结构与分包规范
工程结构决定了代码的可维护性。我在这个项目中采用了经典的分层分包结构，按照“控制层-服务层-数据层”的职责边界进行划分。后端工程内部大致如下：
com.school.canteen ├── controller // 控制层，接收前端请求，返回统一结果 ├── service // 服务层，业务逻辑处理 │ └── impl // 服务层实现类 ├── mapper // 数据访问层，继承 BaseMapper ├── entity // 数据库实体对象 ├── dto // 前端传入参数对象 ├── vo // 返回给前端的视图对象 ├── config // 配置类，如跨域、拦截器、MyBatis-Plus配置 ├── common // 通用类，如统一返回结果、异常处理、常量 └── utils // 工具类，如JWT工具、日期工具这种分包方式的核心原则是“每一层只做自己的事”。控制层不写业务逻辑，只做参数接收和结果封装；服务层处理具体业务规则，比如新增采购单时自动校验供应商状态和库存情况；数据层只负责数据库交互。这样做的直接收益是，当采购模块的需求发生变化时，我只需要修改 service 层的实现类，而不会牵连到其他模块。
前端工程则采用 Vue CLI 创建的标准目录结构，按页面维度组织视图组件，按 API 模块拆分请求文件。比如src/api/purchase.js专门封装采购相关的全部接口请求，src/views/supplier目录下放供应商管理相关页面。这种做法的好处是，每个页面对应一个模块的请求逻辑集中在一起，后期维护时定位问题很快。
2.3 权限模型与安全设计
校园食堂供应链系统涉及多个角色，权限控制绝不能做成“所有用户登录后看到一样的东西”。我采用了基于 RBAC（基于角色的访问控制）的权限模型，设计了五张核心表：用户表、角色表、菜单表、用户-角色关联表、角色-菜单关联表。系统内置了后勤管理员、采购员、库管员、供应商、食堂经理五个角色，每个角色配置不同的可见菜单和操作按钮。
安全这块我踩过一个坑，所以特别强调一下：纯粹的前端路由拦截是不够的。如果你只在前端根据角色判断“显示哪个按钮”，一旦有人直接用 Postman 调用后端接口，就能绕过页面限制操作数据。因此后端必须在接口层面做权限校验。我采用的方案是自定义注解@RequiresPermission，在控制层方法上标注所需权限编码，通过拦截器读取当前登录用户的角色和权限集合，对不匹配的请求直接返回 403 状态码，从接口层面杜绝越权访问。
JWT 的设计上也有讲究。用户登录成功后，后端生成一个包含用户ID、角色信息、过期时间的 Token，返回给前端存储。之后每次请求，前端在请求头中携带 Token，后端通过拦截器解析并校验签名。一定要给 Token 设置合理的过期时间——太短会频繁要求用户重新登录，太长则存在安全隐患。本项目中我设置为 8 小时，并在每次有效请求时自动续期，兼顾了易用性和安全性。
3. 数据库建模与核心表设计
3.1 核心表结构梳理
数据库设计是整个项目的地基，表结构设计不合理，后面写代码就是戴着脚镣跳舞。我梳理出来一张核心业务表清单，包括了：供应商表、供应商资质表、采购计划表、采购订单表、采购到货明细表、菜品表、原材料表、库存表、出入库记录表、报损表、盘点表、预警规则表、用户表、角色表等二十多张表。
下面重点说几个关键表的设计思路。供应商表我除了存基础的联系方式、地址、开户行信息外，还增加了“供应商状态”字段（启用/停用）和“供应商等级”字段（A/B/C），等级数据来自系统对历史合作情况的自动评估，会反过来影响采购计划制定时的推荐排序。
库存表我采用的是“实时库存快照 + 出入库流水”的组合设计。实时库存表保存当前每一种原材料在库数量、占用数量、可用数量、库存上限、库存下限、保质期截止日期；出入库流水表则记录每一次数量变动的明细，包括单据类型、关联单号、操作人、变动前后数量。这种组合设计的优势很明显：实时库存表保证查询速度快、业务判断简单；流水表则完整保留历史轨迹，一旦数据异常可以逐单追溯，责任到人。
采购订单表是最核心的一张表，我设计了订单状态字段，用一组整型常量表示：草稿、待审批、已审批、部分到货、已完成、已取消。采购员创建订单后状态为草稿，提交审批后变为待审批，后勤管理员审批通过后变为已审批，供应商开始备货发货。库管员在到货登记时逐条录入实际到货数量，系统自动将订单状态更新为“部分到货”或“已完成”。这样任何时刻打开订单列表，都能一眼看出每个订单当前处在什么环节。
3.2 表设计中的关键约束与索引
数据库设计不能只看字段，约束和索引同样重要。实践中有几个具体的做法值得参考。
首先是唯一性约束。同一个供应商的名称必须唯一，同一批采购订单的单号必须唯一，同一个用户在同一个角色下不能存在多条记录。这些约束在数据库层面加上，比在代码里做查询校验要可靠得多。
其次是索引设计。在核心业务表中，查询条件往往集中在几个固定的字段组合上。我在库存表创建了食材ID和仓库ID的联合索引，在出入库流水表创建了食材ID和单据类型的联合索引，在采购订单表创建了采购员ID和订单状态联合索引。这些索引建立的依据不是凭空猜测，而是先跑了一遍各模块核心 SQL 的 WHERE 条件，再针对高频查询路径进行优化，效果立竿见影。
最后是外键处理。很多初学者喜欢在每张表上都加物理外键，但实际开发中我全部采用了逻辑外键，也就是只在业务层面维护关联关系，不在数据库层面强制加约束。原因很简单：物理外键在插入和更新时会有额外开销，并且会限制一些灵活操作，比如删除供应商时需要先判断是否有历史订单，如果存在则只能做逻辑停用而不是物理删除。这个规则放到服务层处理，比数据库兜底更灵活。
建表语句中一个典型的库存表示意如下：
CREATE TABLE `stock_info` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `material_id` bigint(20) NOT NULL COMMENT '原材料ID', `warehouse_id` bigint(20) NOT NULL COMMENT '仓库ID', `total_quantity` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '总数量', `locked_quantity` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '锁定数量', `available_quantity` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '可用数量', `low_limit` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '库存下限', `high_limit` decimal(10,2) NOT NULL DEFAULT '0.00' COMMENT '库存上限', `expire_date` datetime DEFAULT NULL COMMENT '保质期截止', `update_time` datetime DEFAULT NULL COMMENT '更新时间', PRIMARY KEY (`id`), KEY `idx_material_warehouse` (`material_id`,`warehouse_id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='实时库存表';4. 后端核心模块实现要点
4.1 登录认证与拦截器
整个系统的开发我并不是从首页开始的，而是先做了登录认证模块。因为所有业务接口都需要校验身份，这个模块不稳固，后面的开发联调都会受影响。
登录接口的流程是：接收用户名和密码，先用 BCrypt 算法对密码进行校验，而不是直接明文比对。校验通过后，从数据库查出该用户的角色信息，再查出角色对应的菜单权限集合，将这些信息封装进 JWT Token 返回给前端。前端拿到 Token 后，还要再调一次“获取用户信息”的接口，拿到当前用户的菜单树和按钮权限列表，用来动态渲染左侧菜单和操作按钮。
拦截器的实现有几个细节值得说一说。第一，拦截器里要配置放行白名单，包括登录接口、刷新验证码接口、静态资源路径，以及 Swagger 文档相关路径，否则开发调试时会发现调用文档页面的请求全被拦截。第二，拦截器解析 Token 后，需要把当前登录用户的信息存入 ThreadLocal，这样后续业务代码可以随时获取操作人，自动填入创建人、修改人等审计字段。第三，要在拦截器中统一处理 Token 过期，返回 401 状态码和明确提示信息，前端拿到后自动跳转登录页，而不是弹出模糊的“系统错误”。
4.2 采购模块的状态机流转
采购模块是整个系统业务逻辑最复杂的部分，也是我花费时间最多的地方。采购计划的审批和订单状态变更，本质上是一个状态机问题，我建议大家在实现时把状态流转规则画清楚，再开始写代码。
采购流程的核心路径是：采购员根据低库存预警数据或档口上报需求，编制采购计划单，添加计划明细（食材、数量、期望到货日期）；提交审批后，后勤管理员审批；审批通过后，系统根据采购计划生成采购订单，并自动匹配供应商；供应商确认订单后发货；库管员到货验收，录入实际到货数量和质量情况；验收合格则关联生成入库单，不合格则记录异常并退回。
为了不让状态逻辑散落在一堆 if-else 中，我实现了一个状态检查方法，核心思路是：每个业务操作对应一个当前状态到目标状态的有效迁移，如果请求中的当前状态不在允许迁移集合里，直接抛出业务异常。
public void checkOrderStatusTransition(Integer currentStatus, Integer targetStatus) { Map<Integer, List<Integer>> transitionMap = new HashMap<>(); transitionMap.put(OrderStatusEnum.DRAFT.getCode(), Arrays.asList(OrderStatusEnum.PENDING_APPROVAL.getCode(), OrderStatusEnum.CANCELLED.getCode())); transitionMap.put(OrderStatusEnum.PENDING_APPROVAL.getCode(), Arrays.asList(OrderStatusEnum.APPROVED.getCode(), OrderStatusEnum.REJECTED.getCode())); transitionMap.put(OrderStatusEnum.APPROVED.getCode(), Arrays.asList(OrderStatusEnum.PARTIALLY_RECEIVED.getCode(), OrderStatusEnum.COMPLETED.getCode())); List<Integer> allowedTargets = transitionMap.get(currentStatus); if (allowedTargets == null || !allowedTargets.contains(targetStatus)) { throw new BusinessException("当前订单状态不允许执行该操作"); } }这套思路不仅适用于采购订单，报损单、盘点单等只要存在状态变化的模块都可以复用。状态机的好处是，让所有流程分支在代码层面一目了然，同时有效避免了脏数据、异常流转出现的可能性。
4.3 库存预警与保质期计算
库存预警功能是食堂管理者的刚需。食材断货会影响食堂正常供餐，食材积压会造成过期浪费。我在设计预警模块时，不是简单地做“库存数量小于下限就报警”，而是做了分级预警。
分级预警分三个维度：第一是数量预警，当可用库存低于下限值时触发“补货预警”，提示采购员需要发起采购计划；当库存高于上限值时触发“积压预警”，提示食堂经理需要调整采购策略。第二是保质期预警，对于保质期较短的食材（比如豆腐、鲜肉、绿叶菜），设置提前预警天数，临期食材进入列表，库管员需要优先安排出库消耗。第三是周转预警，我通过计算近30天的日均出库量和当前库存量，估算现有库存的可消耗天数，如果可消耗天数超过预设阈值，提示管理者关注库存积压。
预警数据如何产生？我在项目中采用了两种方式结合：定时任务负责定期扫描库存和保质期数据并生成预警记录；同时，在出入库操作完成的瞬间同步触发规则判断，实现实时预警。两种方式互补，定时任务作为兜底，实时判断保证操作后立刻反馈，这样既不依赖高频率的任务调度，也不会出现肉眼可见的数据延迟。
保质期计算这块有一个细节容易踩坑：不同食材的保质期单位不一样，有的是天，有的是小时，有的是月。我在原材料基础数据中统一维护了“保质期时长”和“保质期单位”两个字段，预警模块内部统一换算为小时进行计算，避免出现“保质期30是什么意思”这种歧义。
5. 前端页面与交互设计
5.1 页面架构与菜单设计
前端工程我使用了 Vue 2 全家桶：Vue Router 做路由管理，Vuex 做全局状态管理，Axios 做 HTTP 请求封装，Element UI 做 UI 组件库。
页面架构整体采用经典的“左侧菜单+右侧内容”的布局结构。左侧菜单根据登录用户的权限动态生成——用户登录后，前端拿到菜单树数据，递归渲染到侧边栏。菜单分为两级：一级菜单按业务域划分，如“采购管理”“库存管理”“供应商管理”“报表中心”；二级菜单对应具体的功能页面，如“采购计划”“采购订单”“到货验收”。
这里有一个必须注意的细节：动态菜单加载时，刷新页面会导致 Vuex 中保存的菜单数据丢失。处理方法是把菜单数据持久化到本地存储或 SessionStorage，同时在路由全局守卫中增加逻辑：如果本地存储有菜单数据但当前路由不在路由表中，说明标记为动态添加的路由尚未注册，此时先动态添加路由，再放行页面访问。
5.2 表格、表单与大表单的数据处理
这个系统中有大量数据管理页面，靠的就是表格和表单两种核心交互模式。表格我的统一方案是“ECharts 报表 + el-table 数据列表 + 顶部查询条件 + 分页”，查询区域放在表格上方，支持条件组合查询和数据导出 Excel。
采购订单表单有点特殊，它是一个“一主多从”的大表单：主表是订单基本信息（供应商、采购日期、期望到货日期、备注），从表是可增删的订单明细列表（食材、数量、单价、小计）。这个交互在 Element UI 中实现并不复杂：主表信息直接绑定表单对象，明细部分动态渲染多行表单组件，每一行设置规则校验。但在提交时要注意——前端校验的颗粒度是整单，绝不能用单行明细的校验状态覆盖整个订单的校验结果。我的做法是：先分别校验主表和每一行明细，全部通过后统一提交保存。
前端与后端交互显示的金额计算也颇为讲究。比如采购订单中，单个食材有“参考单价”和“实际成交单价”，这两者可能不同，而在前端展示时又需要先展示参考价，等供应商确认后再更新为实际价。如果后端不在写入时做校验，很容易出现单价为负数、数量为小数却表示“份数”这类脏数据。正确做法是，后端在保存接口中统一校验数值边界和精度，把好最后一道关。
5.3 报表可视化的实现思路
报表模块是给食堂经理看的部分，要直观展示经营和供应情况。这个模块我用了 ECharts 作为图表库，因为它是国内使用最广泛的可视化库，文档全、社区活跃，遇到图形定制问题很容易找到参考方案。
我做了四个核心报表页面：第一个是采购金额月度趋势，用折线图展示每月采购总额，对比不同月份采购量变化；第二个是供应商评估对比，用雷达图展示供应商在价格、质量、准时率、服务四个维度的得分；第三个是库存周转分析，用柱状图展示不同食材类别的周转天数，周转天数越长说明积压越严重；第四个是食材分类占比，用饼图展示粮油、肉禽蛋、蔬菜、调料等不同品类在总采购额中的占比，帮助管理者判断饮食结构是否均衡。
所有这些报表图表的背后，都是后端接口返回的聚合数据。这里分享我的一个经验：聚合数据的查询尽量在后端完成，前端只负责渲染。比如“采购金额月度趋势”接口，后端用一条带 GROUP BY 的 SQL 按月汇总，直接返回[{month: "2025-01", totalAmount: 126000}, ...]这样的结构；如果让前端拿到明细数据再来聚合，不仅前端代码复杂，网络传输的数据量也会成倍增加，对性能和体验都不友好。
6. 部署运行与常见问题排查实录
6.1 环境准备与初始化
项目虽然包含源码，但要让整个系统在自己电脑上跑起来，还是有一些环境准备工作需要做好。我建议按以下顺序操作，可以减少很多不必要的折腾。
第一步是确认 JDK 版本。项目用的是 Spring Boot 2.7.x，建议安装 JDK 8 或 JDK 11，JDK 17 虽然也能运行，但可能会遇到一些框架兼容性问题，新手先用稳定的组合更省心。
第二步是安装 MySQL 和 Redis。如果你用的是 Windows，通常建议直接安装提供的安装包，注意 MySQL 编码集必须设置为 utf8mb4，不然后续插入中文字符会出现乱码。Redis 在 Windows 上可以直接解压绿色版本或使用子系统安装，启动后能看到默认的 6379 端口即可。
第三步是初始化数据库。项目源码中一般会附带数据库脚本文件，使用数据库客户端工具执行该脚本即可创建数据库和全部数据表。执行过程中要注意脚本里是否包含测试数据，如果有数据，建议保留——因为很多页面在没有测试数据的情况下查询结果是空的，不利于初学者理解系统功能。
第四步是修改后端配置文件中的数据库连接信息、Redis 连接信息。最重要的一项是把密码改成你自己本地环境的密码。很多读者拿到源码后直接启动报错，绝大部分原因就是配置文件里的账号密码和环境对不上。
第五步是启动前端开发服务器，访问项目首页。如果页面正常显示并能登录，整个环境就通了。
前端启动命令通常如下：
npm install npm run serve后端启动测试用如下命令：
mvn spring-boot:run6.2 高频启动报错与解决方案
在帮好几个朋友排查这个项目后，我把最常见的报错整理成一个快速排查表，方便大家对照处理。
第一个常见问题是“端口被占用”。Spring Boot 默认使用 8080 端口，如果本机的 8080 被其他服务占用，启动会直接报Port already in use。解决办法有三个：找到占用进程将其结束，或者在配置文件中修改server.port为其他可用端口，比如 8081，再或者在启动命令中指定端口参数。
第二个常见问题是“数据库连接失败”。报错信息通常是Access denied for user 'root'@'localhost'或Communications link failure。前者说明密码不对或账号权限不够，后者说明 MySQL 服务没有启动，或者配置文件里的 IP、端口填写错误。排查方向依次是：确认 MySQL 服务已启动、确认账号密码正确、确认配置文件中的 url 完整无误。
第三个常见问题是“Redis 连接超时”。本项目使用 Redis 做缓存和 Token 管理，Redis 服务没有启动时，系统可能在启动阶段就报Unable to connect to Redis。你要做的是单独启动 Redis 服务，确认端口为默认的 6379，并且没有额外的密码拦截。
第四个问题是“Mapper 扫描不到”。如果你是自己从零搭建的工程，而不是直接运行已有源码，那么要留意启动类上是否加了@MapperScan注解，并且注解的包路径是否和 Mapper 接口所在包一致。如果漏了这一步，运行时会报类似Invalid bound statement (not found)的错误，当时我排查了很久才发现是包路径写错了。
第五个问题是“跨域请求被拒绝”。前后端分离的情况下，前端访问后端的接口必须配置跨域支持。在后端配置类中增加跨域映射，允许前端地址的请求访问，并允许携带凭证。如果使用代理模式，也可以在前端配置文件里设置代理，将/api前缀的请求转发到后端地址。
6.3 数据安全与备份机制
这套系统上线运行一段时间后，真正要紧的问题不是功能好不好用，而是数据安全。库存和采购数据属于学校的资产，一旦丢失会直接影响食堂运营。
我在项目中做了几个层面的备份机制。第一层是 MySQL 的定时自动备份，可以使用系统自带的任务计划程序，定期执行数据库导出命令，生成 SQL 备份文件并存储到指定目录。第二层是核心业务操作的操作日志记录，配置拦截器自动记录每次写操作，包括操作人、操作时间、操作内容、请求参数和响应状态，一旦数据出现异常，可以快速定位是谁在什么时候做了什么。第三层是文件存储的隔离，供应商资质照片、采购验收图片等文件统一存储到本地文件服务或云存储服务，数据库里只存路径地址，避免大字段占用数据库空间，拖慢查询速度。
这里我遇到过一个实际教训：有一次同事误操作，在供应商列表点击了删除，结果该供应商名下全部历史采购订单数据被物理删除了。后来我在代码中修改为逻辑删除，使用deleted字段标记记录是否有效，所有列表查询默认过滤已删除数据。从此之后，哪怕是误删，也能通过特殊接口恢复数据，不再造成永久性丢失。像供应商、食材这类基础数据表，建议一律采用逻辑删除。
7. 从开发到交付的个人经验与扩展思路
7.1 开发节奏与自测方法
这个项目开发期间，我总结出一个适合自己的节奏：模块开发采用“基础功能先行、报表后置”的顺序，先把供应商管理、采购、库存这几个核心业务流程跑通，让整个系统先形成一个可用的闭环，再回头去完善报表和可视化功能。这样做有一个好处：核心流程打通之后，就算报表没做完，系统也能先提交给业务方试用，获得反馈后集中调整。
自测方法的优先级，我建议依次是功能链路自测、权限边界自测、异常场景自测和数据一致性自测。功能链路是正常走完“创建采购计划-审批-下单-入库-库存查询”这条主链路；权限边界是切换不同角色账号，确认越权访问被拦截；异常场景是测试库存不足、订单重复提交、到货数量超量这些情况；数据一致性是核对库存表数量与出入库流水累计数是否一致。
7.2 后续可以扩展的方向
系统做完核心功能后，如果继续深化，有几个方向值得尝试。
方向一是对接财务系统。供应链系统和财务系统打通后，采购订单验收完成后可以自动生成应付账款凭证，供应商结算时可直接查对账单，减少人工核对工作量。方向二是增加档口报货的移动端入口。目前食堂档口的日常需求由采购员统一汇总，如果做成一个简易的移动端页面，档口经营者可以在手机上报需求，采购员在后台汇总生成采购计划，需求响应速度会明显提升。方向三是引入更智能的需求预测。基于历史采购数据和就餐人数数据，建立简单的消耗预测模型，自动生成下期采购计划的建议数量，减少人工估算的误差。方向四是接入食品追溯体系。供应链数据中已经包含批次和保质期信息，在此基础上为每个食品批次记录供应商、入库时间、出库去向等信息，可以做到从原材料到餐品的全程可追溯。
我个人在实际开发中体会最深的一点是：校园食堂供应链系统的难点不在于单个功能有多难写，而在于如何把多个环节的数据逻辑串联成一条完整、闭环且可追溯的链路。只要能保证每一步数据变动都有来源、有去向、有记录，这个系统就已经能发挥出实实在在的管理价值。最后再分享一个小技巧——开发过程中不要怕推倒重来，但推倒之前一定要先记录原来的问题。很多设计优化，都是踩过了坑之后重构才得出的。现在你手上有完整源码，把它跑通、读透、再改造成自己的版本，这个过程本身就能让你收获很多。
