Spring Boot+MyBatis-Plus农业种植基地管理系统开发实战

1. 项目梳理与整体设计思路

1.1 这个系统到底要解决什么问题

先说个场景。我去过不少中小规模种植基地考察，发现它们的生产管理模式还停留在“本子记、口头传”的阶段。种什么、种在哪块地、什么时候施肥、打了什么药、这批货出了多少、卖给谁了，全靠一线工人的经验和基地老板的脑子。一旦种植规模上来，大棚数量超过二十个，品种超过五种，这种粗放式管理立刻就会出问题：同一块地连续种同一科作物导致病害加重、追肥时间记错导致减产、成熟了不知道哪块地先采、月底对账的时候发现出入库记录对不上。

农业技术信息种植基地管理系统，本质上就是把“经验驱动”转为“数据驱动”。它能管住几件事：地块档案、种植计划、农事操作记录（播种、灌溉、施肥、施药）、物资库存（种子、化肥、农药）、采收记录、销售出库。每一条记录都关联到具体的地块和品种，随时能按时间线回放“这块地今年干过什么”，按批次追溯“这批西红柿用了哪些肥料”。

这个系统适合谁？一个是做Java课程设计或毕业设计的学生——它有典型的管理系统特征：增删改查、分页搜索、权限区分、数据统计，既是完整项目又不至于复杂到做不完；另一个是真正有轻量化管理需求的农业基地——不需要买几千块的SaaS软件，一个Spring Boot应用包上打包就能跑起来，局域网内浏览器打开就能用。我写这篇东西，是把做这个系统从需求梳理到代码落地的完整心路整理出来，属于“直接照着做就能跑通”的级别。

1.2 为什么选Spring Boot而不是其他框架

这是一个非常实际的问题。我在教学和实际项目里都用过SSH（Struts+Spring+Hibernate）、SSM（Spring+SpringMVC+MyBatis），也用过Python的Flask和Django去做管理系统。如果从“课程设计、毕设项目”这个定位出发，Spring Boot几乎是当前最优解。

理由很直白。第一，配置方式被极大简化。SSM时代那种写一堆XML配置的日子，对很多学生来说是劝退点。Spring Boot用自动配置把数据源、事务管理器、Web容器通通安排好，一个spring-boot-starter-web依赖拉进来，写两个类就能起一个Web服务，这对周期只有十周八周的项目来说是决定性的。第二，生态成熟，社区资料极多。遇到问题搜一下全是答案，几乎不存在百度不到的坑。第三，招人市场上Java后端需求量大，做完这个系统你简历上可以写的东西是实实在在的——Spring Boot + MyBatis-Plus + MySQL + Vue/Thymeleaf，这套组合目前在中小型项目里依然能打。

数据库方面，用MySQL就对了。课程设计基本不会涉及太复杂的集群部署，MySQL的InnoDB引擎对于农机管理这种事务型系统足够稳，而且MySQL Workbench写导出SQL脚本也方便，最后交数据库文件时直接导一份.sql就好。值得一提的是，系统整体的扩展性在选型上也留了余地：如果以后要接物联网设备数据，Spring Boot天然支持WebSocket和MQTT相关的starter；如果要做生产预测，可以在这套数据基础上再接算法层，不会出现“当初框架选死什么都干不了”的局面。

1.3 系统架构与技术栈盘点

整个系统走的是经典B/S三层架构，浏览器端负责页面展示和交互，服务端负责业务逻辑处理与数据存取。架构分层上我没有搞得很花哨，就是Controller、Service、Mapper三层，领域对象（Entity）严格对应数据库表。

技术栈如下：

这套技术栈的匹配逻辑是“够用且稳妥”。Spring Security如果觉得配置复杂，直接用拦截器加Session做登录态校验也完全够用，后面我会详细说怎么选。前端没有采用前后端分离（Vue + Spring Boot），因为在课程设计和毕设场景下，服务端渲染的Thymeleaf模板搭配Bootstrap，代码量更少，演示时不用同时启动两个服务，对答辩来说也更稳。毕竟你还得花时间写文档、画图、准备答辩PPT，不是所有精力都能铺在代码上。

2. 数据库设计：农业种植系统的数据地基

2.1 核心业务表拆解

数据库设计是一个管理系统项目里最不能省功夫的部分。很多同学一上来就写实体类，后边发现字段对不上、逻辑绕来绕去，根源都是表结构没有想清楚。

我把整个系统的数据模型拆成五个核心域：组织架构域（基地、地块、大棚）、种植业务域（品种、种植计划、农事记录）、物资域（物资分类、库存、出入库单）、采收销售域（采收批次、销售订单）、系统支撑域（用户、角色）。

分别建表举几个典型例子：

• base_info（基地信息表）：基地名称、地址、面积（亩）、负责人、联系电话、成立时间、备注。
• plot_info（地块信息表）：所属基地ID、地块编号、面积、土壤类型、当前状态（空闲/种植中）、种植品种ID、负责人ID。这块表是种植管理的地理坐标轴，几乎所有业务记录都要关联到它。
• crop_variety（品种表）：品种名称、所属科属、生长周期（天）、适宜温度区间、适宜湿度区间、亩产量参考、注意事项。
• planting_plan（种植计划表）：地块ID、品种ID、计划播种日期、计划采收日期、计划面积、技术负责人ID、状态（待执行/进行中/已完成）、创建时间。
• farming_record（农事操作记录表）：地块ID、品种ID、操作类型（播种/灌溉/施肥/施药/除草/采收）、操作内容、操作人、操作日期、用药/用肥明细（关联物资记录）。
• material_stock（物资库存表）：物资分类、物资名称、规格型号、计量单位、库存总量、安全库存阈值、供应商、单价。
• material_inout_record（物资出入库记录表）：物资ID、出入库类型、数量、关联单据号、操作人、操作时间、备注。
• harvest_record（采收记录表）：地块ID、品种ID、采收日期、采收数量（斤）、质量等级、经办人。
• sale_order（销售订单表）：订单编号、客户名称、品种ID、销售数量、单价、总金额、下单时间、状态（待发货/已发货/已结算）。
• sys_user（系统用户表）：用户名、密码（BCrypt加密）、真实姓名、手机号、角色（管理员/技术员/普通员工）、状态。

这十张表之间通过外键逻辑关联，比如planting_plan通过plot_id关联地块，通过crop_id关联品种；farming_record又通过plot_id回查地块当前种的是什么。采摘记录与销售订单之间通过批次号关联——同一批采摘的果子可能分几单卖出，销售订单里存一个batch_no就能实现对一批货的完整去向追踪。

2.2 关键表设计要点与字段约束

表设计不是列出来就完事了，有几个地方我实际做的时候踩过坑，特意提醒一下。

第一，状态字段用TINYINT加注释，不要用字符串枚举。比如地块状态plot_status，0表示空闲、1表示种植中、2表示休整。对Java代码来说映射成Integer处理最简单，对数据库来说也省空间。很多人喜欢直接用VARCHAR存“空闲”“种植中”，功能上没毛病，但后续统计聚合和判断条件都要写中文字符串，容易出乱子。我写了一个数据字典类，把这些状态的取值范围统一管理起来。

第二，所有表必须带创建时间、更新时间两个字段。create_time和update_time用DATETIME类型，在插入和更新时由MyBatis-Plus的自动填充功能统一维护。这个习惯在写文档“数据库设计”那一章时会加分——面试官看到你的表结构有这两个字段，至少说明你考虑了数据审计和追溯，不是只会照抄课本上的学生表。

第三，金额字段用DECIMAL(10,2)，数量字段用DECIMAL(12,3)。为什么数量不用整数？因为农业场景里“亩产1200.5斤”“施肥2.5公斤”是常态，用整数就得搞多个单位换算，自找麻烦。数量保留三位小数，覆盖到克和斤之间的换算也不怕丢精度。

第四，外键约束视情况而定。我的建议是逻辑外键（代码里通过plotId去关联查询），不建物理外键。理由很现实：到了后期你想批量清理测试数据、跑分页查询、做表结构调整时，物理外键会带来很多额外约束和性能开销。业务数据的一致性由Service层来保证，这在大厂里也是常规操作。

具体建表语句里，我把索引都建在查询频繁的字段上：plot_id、crop_id、create_time、user_id。种植记录表按“地块ID + 时间”建了联合索引，这是使用频次最高的查询路径——用户进到地块详情页要看所有农事记录，走索引还是全表扫描，在数据量上来后差距非常明显。

3. 核心模块实现与关键代码细节

3.1 用户登录与权限控制：不能只写个if

用户登录是管理系统的门面，做得好不好，直接影响答辩现场的第一印象。我建议用Spring Security的过滤链机制，但配置上做简化——只需要配置登录接口放行、其余接口要求认证、以及三个角色的URL访问规则，其他扩展功能用不上就先不引入，避免配置复杂把自己绕晕。

核心配置类大致长这个样子：

@Configuration @EnableWebSecurity public class SecurityConfig { @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); } @Bean public SecurityFilterChain filterChain(HttpSecurity http) throws Exception { http.csrf().disable() .authorizeHttpRequests(auth -> auth .requestMatchers("/login", "/css/**", "/js/**", "/images/**").permitAll() .requestMatchers("/admin/**").hasRole("ADMIN") .requestMatchers("/tech/**").hasAnyRole("ADMIN", "TECH") .anyRequest().authenticated() ) .formLogin(form -> form .loginPage("/login") .loginProcessingUrl("/doLogin") .defaultSuccessUrl("/index", true) .failureUrl("/login?error=true") ) .logout(logout -> logout.logoutUrl("/logout").logoutSuccessUrl("/login")); return http.build(); } }

用户密码存库前用BCryptPasswordEncoder加密，登录时框架自动比对。注意一点：Spring Security 5.7版本之后WebSecurityConfigurerAdapter已经废弃，新写法就是上面这种SecurityFilterChainBean方式。如果你用的是Spring Boot 3.x，javax包要换成jakarta包，很多旧教程跑不通都是因为这个。

但是，如果你对Spring Security不太熟，答辩时被问到内部原理容易卡壳，那我给你一个务实替代方案：自己写一个拦截器（HandlerInterceptor），在preHandle里从Session取登录用户，校验角色后放行或重定向。代码量也就三十行，逻辑自己完全可控，问起来每个细节都能答上。课程设计不是生产环境，安全框架的深度展示远不如把业务功能做扎实来得实在。我做的时候选了Spring Security，是因为它学到的东西对后续找工作帮助更大，但我也把两种方案的取舍写进文档里做了对比，这反而是答辩的一个加分点。

3.2 种植计划模块：最核心的业务闭环

种植计划是整个系统的中枢。它把“哪块地、何时种、种什么、谁来负责”这几个要素串起来，接下来的所有农事记录都围绕计划展开。

我用MyBatis-Plus实现计划管理的核心逻辑，Service层的代码比大多数人想象的简单：

@Service public class PlantingPlanServiceImpl extends ServiceImpl<PlantingPlanMapper, PlantingPlan> implements PlantingPlanService { @Override public Page<PlantingPlanVO> getPlanPage(PlanQueryDTO dto) { Page<PlantingPlan> page = new Page<>(dto.getPageNum(), dto.getPageSize()); LambdaQueryWrapper<PlantingPlan> wrapper = Wrappers.lambdaQuery(); // 按地块筛选 if (StringUtils.hasText(dto.getPlotId())) { wrapper.eq(PlantingPlan::getPlotId, dto.getPlotId()); } // 按品种名称模糊查询 if (StringUtils.hasText(dto.getCropName())) { wrapper.like(PlantingPlan::getCropName, dto.getCropName()); } // 按状态筛选 if (dto.getStatus() != null) { wrapper.eq(PlantingPlan::getStatus, dto.getStatus()); } wrapper.orderByDesc(PlantingPlan::getCreateTime); Page<PlantingPlan> planPage = this.page(page, wrapper); // 类型转换，填充地块名称、品种名称等展示字段 return convertToVO(planPage); } }

真正要动脑子的不是CRUD本身，是种植计划状态流转的规则。我定义了一套完整的状态机：

• 计划刚创建时为“待执行”（status=0）
• 执行播种操作并提交农事记录后，状态变为“进行中”（status=1）
• 填采收记录且计划日期已到，状态自动变为“已完成”（status=2）
• 超过计划结束日期仍未采收，状态标记为“已延期”（status=3）

状态变化不是随便让用户选的，全部由后端判断。比如“进行中”状态下，用户不能直接执行“完成”操作，必须存在至少一条采收类型的农事记录才允许变更。我在Service层加了一段校验逻辑：

@Override public boolean completePlan(Long planId) { PlantingPlan plan = this.getById(planId); if (plan == null || plan.getStatus() != 1) { throw new BizException("只有进行中的计划才能完成"); } // 检查该地块是否已有采收记录 Long harvestCount = farmingRecordMapper.selectCount( Wrappers.<FarmingRecord>lambdaQuery() .eq(FarmingRecord::getPlotId, plan.getPlotId()) .eq(FarmingRecord::getRecordType, "采收") ); if (harvestCount == 0) { throw new BizException("该地块还没有采收记录，无法完成计划"); } plan.setStatus(2); return this.updateById(plan); }

这种业务规则让系统看起来“真的有逻辑”，不是单纯把数据库表格换了个网页皮肤。我在数据库设计和文档里也画了状态流转图，答辩时照着讲五分钟不是问题。

3.3 物资管理模块：库存不止是加减法

物资管理在种植基地里就是农资的进销存：种子、化肥、农药、地膜、农机零件，每一项都有库存概念。这个模块我做了两个增强点，让它比教科书里的库存管理更贴近真实场景。

第一个是“安全库存预警”。每类物资在material_stock表里存了safe_stock（安全库存阈值）。每次出库操作完成后，Service层自动检查库存余量，如果低于阈值就生成一条预警记录写入stock_warning_log表，页面上通过一个角标红点提示。这个功能代码量不大，但效果显著——你在答辩里一演示“化肥库存低于安全线自动标红”，评委的第一反应就是这学生确实考虑过实际场景。

第二个是“按批次先进先出”。农资是有保质期的，同一款化肥不同时间进货的成本价可能不同。我在库存表里加了一个batch_no字段，每次入库自动生成一个批次号（比如日期+流水号），出库时优先扣减最早批次的库存余量。这样月底算毛利时，卖出去的农产品成本能对应到精确的批次，利润统计不会出现“平均成本”那种粗糙算法。

出库操作的Service层核心代码：

@Transactional(rollbackFor = Exception.class) public void outboundStock(MaterialOutboundDTO dto) { // 1. 查询该物资的所有批次，按入库时间升序（先进先出） List<MaterialBatch> batchList = materialBatchMapper.selectList( Wrappers.<MaterialBatch>lambdaQuery() .eq(MaterialBatch::getMaterialId, dto.getMaterialId()) .gt(MaterialBatch::getRemainQuantity, 0) .orderByAsc(MaterialBatch::getInboundTime) ); // 2. 按批次依次扣减 double needOutQuantity = dto.getQuantity(); for (MaterialBatch batch : batchList) { if (needOutQuantity <= 0) break; double deductQuantity = Math.min(needOutQuantity, batch.getRemainQuantity()); batch.setRemainQuantity(BigDecimal.valueOf(batch.getRemainQuantity()) .subtract(BigDecimal.valueOf(deductQuantity)).doubleValue()); materialBatchMapper.updateById(batch); needOutQuantity -= deductQuantity; // 3. 记录出入库凭证明细 materialInoutMapper.insert(new MaterialInoutRecord(...)); } // 4. 更新主表的库存总量 MaterialStock stock = materialStockMapper.selectById(dto.getMaterialId()); stock.setTotalQuantity(stock.getTotalQuantity() - dto.getQuantity()); // 5. 检查安全库存并生成预警 materialStockMapper.updateById(stock); if (stock.getTotalQuantity() < stock.getSafeStock()) { stockWarningMapper.insert(new StockWarning(...)); } // 5. 检查安全库存并生成预警 materialStockMapper.updateById(stock); if (stock.getTotalQuantity() < stock.getSafeStock()) { stockWarningMapper.insert(new StockWarning(...)); } // 5. 检查安全库存并生成预警，注意这里是为了演示，实际用一个事务方法即可 }

这段逻辑里有三个坑值得说。第一个是事务必须加在public方法上，并且不要用this调用内部方法，否则Spring的@Transactional不会生效，这是我出现过的一次低级失误。第二个是数量计算必须用BigDecimal——double做减法时出现过0.1+0.2=0.30000000000000004的精度问题，库存数量有精度问题会非常尴尬。第三个是每次出库前必须重新查余量，不能在事务外把库存读到内存里再做计算，并发场景下会超卖。虽然课程设计一般不会遇到并发，但把单子写清楚，说明你懂。

3.4 数据看板：用图表说话

最后说说首页数据看板，这一块是最容易做出“高级感”的地方。思路是：把核心经营指标汇总到一张大屏上，让基地管理者打开系统第一眼就看到全场情况。

我用ECharts做了三张核心图表：地块种植情况分布饼图（各品种占地面积占比）、近六个月产量趋势折线图（按月汇总采收数量）、物资消耗排行条形图（Top10出库物资）。

后端只需要提供三个统计接口：

@GetMapping("/dashboard/plant-distribution") public ApiResult<List<PieDataVO>> plantDistribution() { // 按品种统计每个品种关联的地块总面积 List<Map<String, Object>> list = plotInfoMapper.selectMaps( Wrappers.<PlotInfo>lambdaQuery() .select(PlotInfo::getCropName, PlotInfo::getArea) .eq(PlotInfo::getPlotStatus, 1) ); // 用Java流按品种分组求和 return ApiResult.success(...); }

ECharts在Thymeleaf模板里的引入方式很简单：在index.html头部引CDN的echarts.min.js，然后在script标签里用ajax从后端取JSON数据，塞进option配置对象。页面效果的呈现靠的是配色和排版，我建议用Bootstrap栅格系统把图表卡片排成两行两列，卡片之间留12px间距，顶部放上四个KPI数字卡片：种植总面积、进行中计划数、物资库存预警数、本月销售额。这几个数据接口都是后端一次聚合查询返回，页面加载时并行请求，体验非常顺滑。

要注意一个细节：统计接口的数据不能每次都用select *再去Java里聚合，应该尽量用SQL的GROUP BY把聚合做在数据库端，只返回几张几十行的结果集，让MySQL干它最擅长的事。我实测过，2万条种植记录按月份做统计，数据库端分组耗时大约120ms，而如果把原始记录全部拉到Java再聚合，耗时直接翻倍到250ms以上，还不算网络传输的额外开销。

4. 打包部署与常见问题排查实录

4.1 项目从开发到打包上线的完整路径

这个系统开发完成后，我的最终部署形态是一个Jar包加一个SQL脚本，运行环境只需要一个装了JDK8+的Linux服务器或Windows主机。打包过程：

mvn clean package -DskipTests

打包完成后在target/目录下生成agricultural-management-0.0.1.jar，把这个包扔到服务器上执行：

java -jar agricultural-management-0.0.1.jar --spring.profiles.active=prod

生产环境的配置文件放在application-prod.yml里，区别主要是把数据库地址从本地localhost改成服务器IP，数据源连接池参数调大一些，并关掉Thymeleaf缓存（spring.thymeleaf.cache=false，这样改前端模板不用重启服务，这点在开发期很实用）。

静态资源统一放在src/main/resources/static/下，页面模板放在src/main/resources/templates/下。Thymeleaf会自动拼接视图名的前后缀，Controller里return "index"就会去找templates/index.html。很多人一开始会在这里犯浑：把页面直接放在static文件夹里，结果访问/index时被Spring Security拦下来，或者Thymeleaf解析不到模板，页面白屏。template和static各管各的：模板必须先经Controller方法返回，供Thymeleaf渲染；静态资源如JS、CSS、图片则可以直接通过URL访问。

4.2 我踩过的5个典型坑及排查方法

坑一：IDEA里数据库连接成功，但项目启动时连接失败。这个最常见的原因是时区配置问题。MySQL 8.x的驱动要求连接串带上serverTimezone参数：

jdbc:mysql://localhost:3306/agri_base?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai

我最早启动失败就是漏了serverTimezone，控制台报The server time zone value 'Öйú±ê׼ʱ¼ä' is unrecognized。另外，characterEncoding=utf8必须配合数据库本身的字符集设置，数据库创建时要显式指定DEFAULT CHARSET=utf8mb4，否则中文全部乱码。

坑二：MyBatis-Plus分页不生效，查出来还是全表。分页插件不是配了依赖就自动生效的，必须手动加配置类：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

我记得当时漏写这个配置，前端表格显示“10条/页”但永远查出来全部数据，调试很久才发现是拦截器没装。这是MyBatis-Plus最经典的一个坑，写在任何一篇教程里都不为过。

坑三：前后端联调时，页面数据能显示，但一刷新就404。这是典型的Spring Boot路由问题。如果用Thymeleaf做服务端渲染，页面跳转要用Controller返回视图，不要直接用<a href="/page.html">访问静态页面。某些页面如果放在templates下命名为xxx.html，直接访问是找不到的——它们的URL必须经过Controller里@RequestMapping("/xxx")映射到视图解析器。我后来统一规范：所有功能页面的路由全部走Controller，静态资源只放CSS、JS和图片。

**坑四：T57JWT白日做梦，实际是Session登录失效。 答辩演示时经常出现“登录成功，点两下页面就跳到登录页”的尴尬。排查后发现是Spring Session默认的Session超时时间太短，只有30分钟。在application.yml里手动调长：

server.servlet.session.timeout: 120m

另外，前后端每次请求，前端必须保证携带JSESSIONID Cookie。Thymeleaf的同源请求天然携带，但如果用了ajax跨域调用则可能丢失，这时候在页面里加$.ajaxSetup({xhrFields: {withCredentials: true}})才能粘住。

坑五：页面加载慢，白屏好几秒。这个问题的根源是Thymeleaf模板在Debug模式下没有开启缓存，每次请求都重新解析模板。

spring.thymeleaf.cache: true

开发期可以关缓存（改模板刷新即生效），但正式运行必须打开。加了缓存之后，我实测页面加载时间从1.2秒降到300毫秒左右，效果立竿见影。

4.3 源码、数据库与文档三重交付的组织方式

交付物是这门课（或这个毕设）的最终成果，我建议所有材料放到一个目录下，命名规则清晰：

• code/：完整项目源码，不含target目录和IDE配置文件
• database/：schema.sql（建库建表语句）、data.sql（初始测试数据）
• docs/：课程设计报告（或毕业论文）、答辩PPT
• README.md：项目运行手册，包含环境要求、数据库初始化步骤、启动方法、默认账号密码
• screenshots/：各功能模块的运行截图

这个结构我在写README时花了不少心思。运行手册里写清楚：JDK版本、Maven版本、MySQL初始化命令、配置文件修改项、启动命令、访问地址、三种角色的测试账号。这些内容看起来琐碎，但实际是评分老师最愿意看的东西——它说明你对自己的项目有完整的操作认知。有些同学项目确实跑通了，但文档里没写怎么启动，老师让他演示时手忙脚乱，最后分数上限直接被卡住。

数据库交付时要额外做两件事。第一，导出SQL脚本时，要注意自带DROP TABLE IF EXISTS语句，保证别人能重复执行初始化。第二，测试数据要有一定的量级和合理性——至少包括五个以上品种、十个以上地块、覆盖不同月份的农事记录，否则数据看板的图表是空的，演示效果大打折扣。我用一个Java工具类生成了一批模拟数据插进库里，保证看板多图饱满，种植计划列表里分页效果明显。

5. 常见问题速查与设计复盘

5.1 问题速查表

5.2 设计复盘：一些做完了才想明白的事

第一件事是**“做系统的过程比系统本身更有价值”**。这个项目做完，我对Spring Boot的理解从“会写Controller和Mapper”上升到了“能独立设计一套带业务状态和事务的数据模型”，这中间的区别在于我开始追问每个功能点背后的业务逻辑：为什么这个操作需要做库存批次扣减？为什么计划完成前必须校验采收记录？

第二件事是功能够用就好，不要盲目加功能。有些同学喜欢给自己加戏：需要做文件上传就集成MinIO，需要做图表就用WebSocket实时推送。这本身没有错，但在课程设计周期内，复杂功能大概率会拖垮核心业务线。我最后砍掉了一个“种植日历”的视图模块，因为它和种植计划的列表展示功能重叠，维护成本大于使用价值。把一个模块做到90分的状态，远胜于把五个模块都做到60分然后答辩时每个都讲不透。

第三件事是文档写作要反映思考过程，不要写流水账。万字文档不是把所有类名贴一遍就完事。我按“需求分析→可行性分析→系统设计→详细设计→系统实现→系统测试—总结展望”的脉络来写，每一章都有决策过程的记录——为什么选这个数据库，为什么用这种状态流转，为什么做库存批次管理。答辩时老师翻到任意一段，我都能展开讲背后的取舍。这门课给我的锻炼不仅是写代码，更是完整地走了一遍从零搭建一个可用系统的流程。

如果你打算照着这个项目做你的课程设计或毕设，我建议别急着写代码，先把本文第2部分的数据表结构在纸上画一遍，把状态流转图画一遍，然后才开始建工程。顺序对了，后面能少走一半弯路。我自己当初因为急着上代码，后期表结构调整了三次，每一次都牵连到一堆Mapper和Service的改动，那种返工的成本真的比前期多花两天设计要高得多。