1. 这不是又一个“后台管理系统”而是一套能真正帮农户看懂销量的决策工具我带过几届毕业设计每年都有学生扎堆做“XX管理系统”——用户管理、商品管理、订单管理三板斧轮着来。但去年有个学生交上来一个叫“基于大数据的农产品销售数据分析可视化系统”的选题我第一反应是又一个套壳项目直到他现场演示时调出一张热力图把某县草莓在华东三省的周度动销衰减曲线和冷链运输时效叠加显示旁边还标着“建议本周优先发往南京仓损耗率可降1.8%”我才意识到这玩意儿真能用。它用的确实是Django——但不是拿Django当CRUD框架使而是把它当数据管道的调度中枢。Django Admin被彻底重构不再用来增删改查而是变成数据校验看板Django ORM没用来写复杂JOIN而是作为多源异构数据Excel导入、API对接、IoT温湿度日志的统一抽象层连URL路由都重写了/dashboard/sales/trend/ 不再返回HTML模板而是直接吐出经过Pandas预聚合的JSON前端ECharts只管渲染。关键词里没写“Pandas”“Plotly”“Celery”但它们才是真正的主角。这个系统解决的不是“有没有数据”而是“数据能不能让没学过统计学的合作社负责人一眼看出该砍哪片地的苗、该加哪天的单、该换哪个物流商”。它面向的不是IT部门而是凌晨四点蹲在批发市场等车的种植户。所以本文不讲Django怎么配settings.py只讲当真实农田数据撞上真实市场波动这套系统在哪些环节必须“反常规”设计以及为什么那些教科书式的最佳实践在田埂边会直接失效。2. 数据源头的混沌性从Excel拖拽到实时IoT为什么必须放弃“干净数据”幻想几乎所有课程设计都默认数据是结构化的、字段对齐的、无缺失值的。但现实里你拿到的第一份数据可能是某合作社手写的纸质台账拍照转成的PDFOCR识别后“单价”列混着“元/斤”“¥5.2”“五块二”三种格式某生鲜平台API返回的JSON里“发货时间”字段在7月前是ISO格式8月起突然变成Unix时间戳而9月又切回字符串但时区标识丢了还有冷链车上传的温湿度传感器数据每30秒一条但设备离线时会攒着几千条记录一次性补传时间戳全挤在同一个毫秒级时间点。我们曾试图用Django Model严格约束字段类型结果卡在第三天——上游数据方说“你们要的‘标准格式’我们系统导不出只能给这个Excel”。硬扛行。但代价是每周要人工清洗20张表校验逻辑写满3个Python文件且每次上游微调字段整个ETL链就崩。最后方案是彻底放弃“入库即校验”改为三层缓冲Raw Layer用Django FileField原样存原始文件Excel/PDF/ZIP附加MD5和采集时间戳。不做任何解析只保证“原始可追溯”。Staging Layer独立Celery任务定时扫描Raw目录用openpyxlpandas.read_excel(engineopenpyxl)加载自动检测空行、合并单元格、表头偏移。关键创新点在于不强行标准化字段名而是用模糊匹配如fuzz.ratio(单 价, col_name) 85动态映射到内部字段price_per_unit。匹配失败的列存入staging_unmapped_columnsJSONField供人工审核。Clean Layer仅当Staging数据通过规则引擎自定义Django管理命令校验后才触发clean_data()方法。规则非SQL式约束而是业务逻辑# 规则示例草莓单价不能低于成本价的60%否则标记为异常 if row[product] strawberry and row[price_per_unit] row[cost_price] * 0.6: row[anomaly_flag] price_too_low row[anomaly_reason] 可能为清仓或录入错误提示别迷信Django Model的nullFalse。真实农业数据中“某批次未测农残”和“农残检测为0”是完全不同的业务含义前者应存NULL后者存0。我们在CropBatch模型里为所有检测字段设nullTrue, blankTrue并额外加detection_status枚举字段not_tested/tested_pass/tested_fail这才是农民真正需要的语义。实操心得第一次部署时我们按教科书用django-import-export做Excel导入结果遇到合并单元格直接报错。后来发现openpyxl的worksheet.merged_cells属性能获取所有合并区域再用worksheet.unmerge_cells()暴力拆分但会丢失样式。最终妥协方案是保留合并单元格用worksheet.cell(row, col).value读取左上角单元格值其他位置设为None——因为农民填表时合并单元格本就是“同一信息重复填写”的习惯值本身没丢。3. 销量分析的核心陷阱时间维度不是日历而是“农事周期”教科书里的时间序列分析永远以“日/周/月”为单位。但农产品销量根本不受日历支配。草莓旺季在3-5月但具体到某县采摘高峰取决于倒春寒结束时间大白菜销量在霜降后激增但若当年暖冬峰值会推迟三周甚至同一天早市批发价和晚市电商价能差30%。用固定时间窗口聚合等于把脉时故意蒙眼。我们重构了整个时间维度建模物理时间Physical Time服务器UTC时间仅用于记录数据采集时刻不参与分析。农事时间Agri-Time自定义Django ModelAgriSeason字段包括season_name: 草莓春茬、大白菜秋播start_date: 实际播种日由IoT土壤墒情传感器人工填报双校验end_date: 预计采收结束日动态更新根据每日生长指数调整phase: 育苗期/生长期/采收期/休耕期市场时间Market Time基于AgriSeason派生核心是SalesWindow模型class SalesWindow(models.Model): season models.ForeignKey(AgriSeason, on_deletemodels.CASCADE) window_type models.CharField(choices[(peak, 销售高峰), (shoulder, 平销期), (off, 淡季)]) start_offset_days models.IntegerField() # 相对于season.start_date的偏移 end_offset_days models.IntegerField() # 示例草莓春茬peak期为start_date25天 到 start_date55天分析销量时所有聚合操作必须绑定SalesWindow。比如计算“同比”不是比2023年4月 vs 2024年4月而是比“2023年草莓春茬高峰期内销量” vs “2024年草莓春茬高峰期内销量”。这要求前端图表组件支持动态时间范围选择器——我们弃用ECharts内置时间轴改用input typedate联动后端API请求时携带season_id和window_type后端用SalesWindow.objects.get(season_idxxx, window_typepeak)算出真实日期范围再查库。注意千万别在数据库里存“农事周期”为字符串我们曾用CharField存strawberry_spring_2024结果第二年要手动改所有SQL。正确做法是AgriSeason主键自增ID所有关联表用外键引用周期变更只需更新AgriSeason记录下游自动生效。最棘手的是跨周期对比。比如想看“今年草莓高峰销量 vs 去年同期大棚草莓销量”但去年大棚数据在另一张表。解决方案是建立CrossSeasonMapping模型人工维护映射关系如2023_strawberry_greenhouse→2024_strawberry_openfield分析时先查映射表再拼接查询条件。这听起来笨重但比算法自动匹配可靠——农民知道什么和什么能比AI不知道。4. 可视化不是炫技而是降低决策门槛从ECharts配置到“一句话结论”毕业设计常犯的错是把ECharts官网示例复制粘贴做出3D饼图、粒子动画答辩时老师点头但农户看了直摇头“这图啥意思我要知道明天该摘多少斤” 可视化在这里不是展示技术而是翻译业务语言。我们定了三条铁律所有图表必须带“行动指引”标签折线图顶部不只显示“销量12,345kg”而是“较上周↑12.3%建议明日增加采摘人手2名按当前损耗率推算”禁用任何需要专业知识解读的图表删除箱线图农民不懂四分位数删除相关系数矩阵“价格与天气相关性0.73”毫无意义用“热力图箭头”替代散点图横轴“发货城市”纵轴“发货日期”格子颜色深浅销量右下角小箭头表示趋势↑销量增↓销量降核心指标必须“口语化”技术术语农户语言计算逻辑Inventory Turnover Ratio“这批货几天能卖完”当前库存(kg) / 近7日平均日销量(kg)Forecast MAPE“预测准不准误差大概几斤”mean_absolute_percentage_error(实际销量, 预测销量)Geographic Concentration Index“货都卖到哪儿去了有没有新市场”max(各城市销量占比) * 100值越低越分散实现上后端不返回原始数据而是返回带结论的JSON{ chart_type: bar, data: [{city: 南京, sales_kg: 2345}, {city: 杭州, sales_kg: 1890}], conclusion: 南京销量最高占总量38%但较上周降5%建议核查当地批发市场档口变动, action: 已生成《南京市场核查清单》点击下载 }前端ECharts只负责渲染dataconclusion和action用独立DOM元素展示。这样即使图表加载失败农户也能看到文字结论。实操踩坑最初用django-plotly-dash想搞交互式仪表盘。结果发现合作社电脑普遍是Win7IE11Dash依赖的React版本不兼容。紧急降级方案用纯HTMLCSS少量jQuery图表用ECharts 4.x兼容IE11结论文字用details标签折叠避免信息过载。牺牲了“高大上”换来了“真能用”。5. Django的非常规用法当Web框架变成数据工作流引擎很多人以为Django只是造网站的其实它的中间件、信号、管理命令机制天生适合做数据流水线。我们把Django当成了轻量级Airflow用。5.1 中间件驱动的实时预警Django Middleware本用于处理HTTP请求但我们改造为“数据事件监听器”。在process_request里不碰request而是检查Redis队列# middleware.py class SalesAlertMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): # 检查是否有新销量数据入库通过信号触发写入redis if cache.get(new_sales_alert): # 调用预警逻辑如单日销量突降超40% if self.check_sales_drop(): send_sms_to_farmers(【预警】您负责的草莓今日销量仅120kg较昨日降45%) cache.delete(new_sales_alert) return self.get_response(request)好处是零额外进程预警延迟1秒且复用Django的配置体系短信网关密钥存在settings.py。5.2 管理命令即ETL脚本python manage.py import_sales_data --source excel --file_path /tmp/20240415.xlsx这个命令背后是完整的数据清洗流水线import_sales_data调用StagingDataImporter类类内按顺序执行detect_format()→normalize_headers()→validate_rules()→load_to_staging()每步失败都记录ImportLog模型含错误行号、原始值、建议修复方式农民不用懂代码运维只要记住这条命令就能跑通整条链路。5.3 信号Signal解耦业务动作当CleanSalesData模型保存时不直接发短信而是发Django信号# models.py from django.db.models.signals import post_save from django.dispatch import receiver receiver(post_save, senderCleanSalesData) def trigger_analytics(sender, instance, created, **kwargs): if created: # 异步触发分析任务 analyze_sales_trend.delay(instance.season_id) # 同步更新缓存 update_dashboard_cache(instance.season_id)这样未来要加“邮件通知”或“微信推送”只需新增一个receiver函数不用改CleanSalesData.save()方法——符合开闭原则也方便测试。关键经验Django的transaction.on_commit()是救命稻草。比如销量入库后要更新库存但库存更新失败不能导致销量入库回滚农民已装车。我们用def save_sales_data(): sales CleanSalesData.objects.create(...) transaction.on_commit(lambda: update_inventory(sales))确保库存更新在事务提交后执行失败不影响主流程。6. 源码交付的隐藏重点不是功能完整而是“可维护性”设计毕业设计答辩常被问“如果换个人接手多久能改出新功能” 我们在源码里埋了三重保障6.1 配置即文档Config-as-Documentation所有业务规则不写死在代码里而是放在config/目录的YAML文件# config/sales_rules.yml strawberry: peak_season: start_offset: 25 end_offset: 55 price_alert_threshold: 0.3 # 价格波动超30%触发预警 sms_template: 草莓{city}销量{trend}建议{action}management/commands/load_config.py启动时加载模型里用settings.STRAWBERRY_RULES[peak_season][start_offset]调用。农民反馈规则要调运维改YAML重启服务即可不用动Python代码。6.2 测试用例即业务说明书每个TestCase不只是验证代码更是业务逻辑快照class StrawberryPeakSeasonTest(TestCase): def test_peak_season_dates(self): 验证草莓春茬高峰期为播种后25-55天 season AgriSeason.objects.create( season_namestrawberry_spring_2024, start_datedate(2024, 2, 10) ) window SalesWindow.objects.get(seasonseason, window_typepeak) self.assertEqual(window.start_date, date(2024, 3, 6)) # 2月10日25天 self.assertEqual(window.end_date, date(2024, 4, 5)) # 2月10日55天答辩时打开这个测试文件比讲PPT更直观说明“系统怎么理解农事周期”。6.3 部署脚本即交接清单deploy/目录下有setup_server.sh一键安装Python3.9、PostgreSQL、Nginx含版本锁死apt install postgresql-1414.12-1.pgdg22.041migrate_data.sh从旧系统MySQL导数据含字段映射表old_table.field_name - new_model.field_namecheck_health.py运行python manage.py check_health输出[OK] 数据库连接正常 [OK] Redis队列监控正常 [WARN] 农事周期配置缺失请运行 python manage.py load_agri_seasons [ERROR] 短信网关密钥未配置请设置 SMS_API_KEY 环境变量最后交付的不是.zip包而是一个README.md开头就写“给接手的开发者先跑./deploy/check_health.py解决所有[ERROR]再跑python manage.py load_config加载业务规则最后python manage.py runserver访问http://localhost:8000/dashboard 查看是否显示‘今日销量’卡片—— 卡在这一步看logs/import_errors.log90%问题在此。”这才是毕业设计该有的样子不炫技不堆砌让技术真正沉到泥土里长出能被看见的果实。 
长河君 · 2026/11/6 5:55:07 · 阅读 1.2k 农业数据可视化系统：Django作为数据工作流引擎的实战设计
1. 这不是又一个“后台管理系统”而是一套能真正帮农户看懂销量的决策工具我带过几届毕业设计每年都有学生扎堆做“XX管理系统”——用户管理、商品管理、订单管理三板斧轮着来。但去年有个学生交上来一个叫“基于大数据的农产品销售数据分析可视化系统”的选题我第一反应是又一个套壳项目直到他现场演示时调出一张热力图把某县草莓在华东三省的周度动销衰减曲线和冷链运输时效叠加显示旁边还标着“建议本周优先发往南京仓损耗率可降1.8%”我才意识到这玩意儿真能用。它用的确实是Django——但不是拿Django当CRUD框架使而是把它当数据管道的调度中枢。Django Admin被彻底重构不再用来增删改查而是变成数据校验看板Django ORM没用来写复杂JOIN而是作为多源异构数据Excel导入、API对接、IoT温湿度日志的统一抽象层连URL路由都重写了/dashboard/sales/trend/ 不再返回HTML模板而是直接吐出经过Pandas预聚合的JSON前端ECharts只管渲染。关键词里没写“Pandas”“Plotly”“Celery”但它们才是真正的主角。这个系统解决的不是“有没有数据”而是“数据能不能让没学过统计学的合作社负责人一眼看出该砍哪片地的苗、该加哪天的单、该换哪个物流商”。它面向的不是IT部门而是凌晨四点蹲在批发市场等车的种植户。所以本文不讲Django怎么配settings.py只讲当真实农田数据撞上真实市场波动这套系统在哪些环节必须“反常规”设计以及为什么那些教科书式的最佳实践在田埂边会直接失效。2. 数据源头的混沌性从Excel拖拽到实时IoT为什么必须放弃“干净数据”幻想几乎所有课程设计都默认数据是结构化的、字段对齐的、无缺失值的。但现实里你拿到的第一份数据可能是某合作社手写的纸质台账拍照转成的PDFOCR识别后“单价”列混着“元/斤”“¥5.2”“五块二”三种格式某生鲜平台API返回的JSON里“发货时间”字段在7月前是ISO格式8月起突然变成Unix时间戳而9月又切回字符串但时区标识丢了还有冷链车上传的温湿度传感器数据每30秒一条但设备离线时会攒着几千条记录一次性补传时间戳全挤在同一个毫秒级时间点。我们曾试图用Django Model严格约束字段类型结果卡在第三天——上游数据方说“你们要的‘标准格式’我们系统导不出只能给这个Excel”。硬扛行。但代价是每周要人工清洗20张表校验逻辑写满3个Python文件且每次上游微调字段整个ETL链就崩。最后方案是彻底放弃“入库即校验”改为三层缓冲Raw Layer用Django FileField原样存原始文件Excel/PDF/ZIP附加MD5和采集时间戳。不做任何解析只保证“原始可追溯”。Staging Layer独立Celery任务定时扫描Raw目录用openpyxlpandas.read_excel(engineopenpyxl)加载自动检测空行、合并单元格、表头偏移。关键创新点在于不强行标准化字段名而是用模糊匹配如fuzz.ratio(单 价, col_name) 85动态映射到内部字段price_per_unit。匹配失败的列存入staging_unmapped_columnsJSONField供人工审核。Clean Layer仅当Staging数据通过规则引擎自定义Django管理命令校验后才触发clean_data()方法。规则非SQL式约束而是业务逻辑# 规则示例草莓单价不能低于成本价的60%否则标记为异常 if row[product] strawberry and row[price_per_unit] row[cost_price] * 0.6: row[anomaly_flag] price_too_low row[anomaly_reason] 可能为清仓或录入错误提示别迷信Django Model的nullFalse。真实农业数据中“某批次未测农残”和“农残检测为0”是完全不同的业务含义前者应存NULL后者存0。我们在CropBatch模型里为所有检测字段设nullTrue, blankTrue并额外加detection_status枚举字段not_tested/tested_pass/tested_fail这才是农民真正需要的语义。实操心得第一次部署时我们按教科书用django-import-export做Excel导入结果遇到合并单元格直接报错。后来发现openpyxl的worksheet.merged_cells属性能获取所有合并区域再用worksheet.unmerge_cells()暴力拆分但会丢失样式。最终妥协方案是保留合并单元格用worksheet.cell(row, col).value读取左上角单元格值其他位置设为None——因为农民填表时合并单元格本就是“同一信息重复填写”的习惯值本身没丢。3. 销量分析的核心陷阱时间维度不是日历而是“农事周期”教科书里的时间序列分析永远以“日/周/月”为单位。但农产品销量根本不受日历支配。草莓旺季在3-5月但具体到某县采摘高峰取决于倒春寒结束时间大白菜销量在霜降后激增但若当年暖冬峰值会推迟三周甚至同一天早市批发价和晚市电商价能差30%。用固定时间窗口聚合等于把脉时故意蒙眼。我们重构了整个时间维度建模物理时间Physical Time服务器UTC时间仅用于记录数据采集时刻不参与分析。农事时间Agri-Time自定义Django ModelAgriSeason字段包括season_name: 草莓春茬、大白菜秋播start_date: 实际播种日由IoT土壤墒情传感器人工填报双校验end_date: 预计采收结束日动态更新根据每日生长指数调整phase: 育苗期/生长期/采收期/休耕期市场时间Market Time基于AgriSeason派生核心是SalesWindow模型class SalesWindow(models.Model): season models.ForeignKey(AgriSeason, on_deletemodels.CASCADE) window_type models.CharField(choices[(peak, 销售高峰), (shoulder, 平销期), (off, 淡季)]) start_offset_days models.IntegerField() # 相对于season.start_date的偏移 end_offset_days models.IntegerField() # 示例草莓春茬peak期为start_date25天 到 start_date55天分析销量时所有聚合操作必须绑定SalesWindow。比如计算“同比”不是比2023年4月 vs 2024年4月而是比“2023年草莓春茬高峰期内销量” vs “2024年草莓春茬高峰期内销量”。这要求前端图表组件支持动态时间范围选择器——我们弃用ECharts内置时间轴改用input typedate联动后端API请求时携带season_id和window_type后端用SalesWindow.objects.get(season_idxxx, window_typepeak)算出真实日期范围再查库。注意千万别在数据库里存“农事周期”为字符串我们曾用CharField存strawberry_spring_2024结果第二年要手动改所有SQL。正确做法是AgriSeason主键自增ID所有关联表用外键引用周期变更只需更新AgriSeason记录下游自动生效。最棘手的是跨周期对比。比如想看“今年草莓高峰销量 vs 去年同期大棚草莓销量”但去年大棚数据在另一张表。解决方案是建立CrossSeasonMapping模型人工维护映射关系如2023_strawberry_greenhouse→2024_strawberry_openfield分析时先查映射表再拼接查询条件。这听起来笨重但比算法自动匹配可靠——农民知道什么和什么能比AI不知道。4. 可视化不是炫技而是降低决策门槛从ECharts配置到“一句话结论”毕业设计常犯的错是把ECharts官网示例复制粘贴做出3D饼图、粒子动画答辩时老师点头但农户看了直摇头“这图啥意思我要知道明天该摘多少斤” 可视化在这里不是展示技术而是翻译业务语言。我们定了三条铁律所有图表必须带“行动指引”标签折线图顶部不只显示“销量12,345kg”而是“较上周↑12.3%建议明日增加采摘人手2名按当前损耗率推算”禁用任何需要专业知识解读的图表删除箱线图农民不懂四分位数删除相关系数矩阵“价格与天气相关性0.73”毫无意义用“热力图箭头”替代散点图横轴“发货城市”纵轴“发货日期”格子颜色深浅销量右下角小箭头表示趋势↑销量增↓销量降核心指标必须“口语化”技术术语农户语言计算逻辑Inventory Turnover Ratio“这批货几天能卖完”当前库存(kg) / 近7日平均日销量(kg)Forecast MAPE“预测准不准误差大概几斤”mean_absolute_percentage_error(实际销量, 预测销量)Geographic Concentration Index“货都卖到哪儿去了有没有新市场”max(各城市销量占比) * 100值越低越分散实现上后端不返回原始数据而是返回带结论的JSON{ chart_type: bar, data: [{city: 南京, sales_kg: 2345}, {city: 杭州, sales_kg: 1890}], conclusion: 南京销量最高占总量38%但较上周降5%建议核查当地批发市场档口变动, action: 已生成《南京市场核查清单》点击下载 }前端ECharts只负责渲染dataconclusion和action用独立DOM元素展示。这样即使图表加载失败农户也能看到文字结论。实操踩坑最初用django-plotly-dash想搞交互式仪表盘。结果发现合作社电脑普遍是Win7IE11Dash依赖的React版本不兼容。紧急降级方案用纯HTMLCSS少量jQuery图表用ECharts 4.x兼容IE11结论文字用details标签折叠避免信息过载。牺牲了“高大上”换来了“真能用”。5. Django的非常规用法当Web框架变成数据工作流引擎很多人以为Django只是造网站的其实它的中间件、信号、管理命令机制天生适合做数据流水线。我们把Django当成了轻量级Airflow用。5.1 中间件驱动的实时预警Django Middleware本用于处理HTTP请求但我们改造为“数据事件监听器”。在process_request里不碰request而是检查Redis队列# middleware.py class SalesAlertMiddleware: def __init__(self, get_response): self.get_response get_response def __call__(self, request): # 检查是否有新销量数据入库通过信号触发写入redis if cache.get(new_sales_alert): # 调用预警逻辑如单日销量突降超40% if self.check_sales_drop(): send_sms_to_farmers(【预警】您负责的草莓今日销量仅120kg较昨日降45%) cache.delete(new_sales_alert) return self.get_response(request)好处是零额外进程预警延迟1秒且复用Django的配置体系短信网关密钥存在settings.py。5.2 管理命令即ETL脚本python manage.py import_sales_data --source excel --file_path /tmp/20240415.xlsx这个命令背后是完整的数据清洗流水线import_sales_data调用StagingDataImporter类类内按顺序执行detect_format()→normalize_headers()→validate_rules()→load_to_staging()每步失败都记录ImportLog模型含错误行号、原始值、建议修复方式农民不用懂代码运维只要记住这条命令就能跑通整条链路。5.3 信号Signal解耦业务动作当CleanSalesData模型保存时不直接发短信而是发Django信号# models.py from django.db.models.signals import post_save from django.dispatch import receiver receiver(post_save, senderCleanSalesData) def trigger_analytics(sender, instance, created, **kwargs): if created: # 异步触发分析任务 analyze_sales_trend.delay(instance.season_id) # 同步更新缓存 update_dashboard_cache(instance.season_id)这样未来要加“邮件通知”或“微信推送”只需新增一个receiver函数不用改CleanSalesData.save()方法——符合开闭原则也方便测试。关键经验Django的transaction.on_commit()是救命稻草。比如销量入库后要更新库存但库存更新失败不能导致销量入库回滚农民已装车。我们用def save_sales_data(): sales CleanSalesData.objects.create(...) transaction.on_commit(lambda: update_inventory(sales))确保库存更新在事务提交后执行失败不影响主流程。6. 源码交付的隐藏重点不是功能完整而是“可维护性”设计毕业设计答辩常被问“如果换个人接手多久能改出新功能” 我们在源码里埋了三重保障6.1 配置即文档Config-as-Documentation所有业务规则不写死在代码里而是放在config/目录的YAML文件# config/sales_rules.yml strawberry: peak_season: start_offset: 25 end_offset: 55 price_alert_threshold: 0.3 # 价格波动超30%触发预警 sms_template: 草莓{city}销量{trend}建议{action}management/commands/load_config.py启动时加载模型里用settings.STRAWBERRY_RULES[peak_season][start_offset]调用。农民反馈规则要调运维改YAML重启服务即可不用动Python代码。6.2 测试用例即业务说明书每个TestCase不只是验证代码更是业务逻辑快照class StrawberryPeakSeasonTest(TestCase): def test_peak_season_dates(self): 验证草莓春茬高峰期为播种后25-55天 season AgriSeason.objects.create( season_namestrawberry_spring_2024, start_datedate(2024, 2, 10) ) window SalesWindow.objects.get(seasonseason, window_typepeak) self.assertEqual(window.start_date, date(2024, 3, 6)) # 2月10日25天 self.assertEqual(window.end_date, date(2024, 4, 5)) # 2月10日55天答辩时打开这个测试文件比讲PPT更直观说明“系统怎么理解农事周期”。6.3 部署脚本即交接清单deploy/目录下有setup_server.sh一键安装Python3.9、PostgreSQL、Nginx含版本锁死apt install postgresql-1414.12-1.pgdg22.041migrate_data.sh从旧系统MySQL导数据含字段映射表old_table.field_name - new_model.field_namecheck_health.py运行python manage.py check_health输出[OK] 数据库连接正常 [OK] Redis队列监控正常 [WARN] 农事周期配置缺失请运行 python manage.py load_agri_seasons [ERROR] 短信网关密钥未配置请设置 SMS_API_KEY 环境变量最后交付的不是.zip包而是一个README.md开头就写“给接手的开发者先跑./deploy/check_health.py解决所有[ERROR]再跑python manage.py load_config加载业务规则最后python manage.py runserver访问http://localhost:8000/dashboard 查看是否显示‘今日销量’卡片—— 卡在这一步看logs/import_errors.log90%问题在此。”这才是毕业设计该有的样子不炫技不堆砌让技术真正沉到泥土里长出能被看见的果实。