简介这是一份面向计算机专业学生与软件开发者的农产品溯源平台毕业设计论文文档围绕微信小程序前端与Python后端展开可用于课程设计、毕业设计选题参考及食品安全溯源类项目开发学习。论文完整覆盖绪论与研究背景、系统需求分析、软件架构与数据库设计、功能实现与总结展望等章节具体涉及B/S架构、小程序平台、Django框架、MySQL环境配置等关键技术并梳理了农产品信息记录追踪、抽样检测、质量认证、企业信息展示、生产基地与农田管理、生长记录资料等核心功能模块能够帮助读者理清从需求梳理到系统落地的完整思路。资源包内含1个docx文件压缩后约1.68MB便于直接查阅与二次参考。目前已有65人学习关注适合需要搭建农产品溯源系统或撰写同类论文的开发者借鉴其功能划分与设计逻辑。1. 扫一张二维码背后农产品溯源小程序真正卡住的地方消费者在超市拿起一盒番茄扫码后小程序里跳出基地编号、农田面积、负责人、最近一次抽检结论——听起来简单落地时最难的从来不是页面而是这条数据链怎么不断、不假、可查。这份「Python 基于微信小程序的农产品溯源平台」配套资源覆盖的是从需求分析、B/S 分层设计、MySQL 物理模型到小程序端与管理员后台的完整链路技术栈以 Python Django MySQL 微信小程序为主论文里出现的 Java、SSM 属于早期版本残留描述实际代码基线按 Python 走。它适合两类人一是做课程设计、毕业设计需要一套表关系清晰、前后端能跑通的同学二是做生鲜、农村电商类项目想借鉴「溯源编号 抽样 巡检 认证」这条业务主线的工程师。下面按架构选型、数据库落地、接口链路、排错校验的顺序拆开讲。2. Django MVT 与小程序双线程溯源平台的分层怎么切2.1 B/S 模式在溯源场景里的实际含义论文里反复提到 B/S 模式落到这个项目上其实有两层意思。第一层是消费者侧不装 App、不装插件微信里打开小程序就能查这决定了整个前端必须围绕小程序的渲染与网络能力来做而不是按传统 Web 页面来做。第二层是管理员侧基地信息、农田信息、抽样记录、认证结果这些录入工作走的是浏览器访问 Django 后台或自建管理页面不需要给每个基地装客户端。这个选择直接影响了接口形态。B/S 下的管理员端可以放心用表单提交、CSRF、Session但小程序端没有 Cookie 的天然继承关系登录态得靠wx.login换 code、后端换 openid 再签发 token两条链路的鉴权方式必须分开设计混用是很常见的坑。提示把「管理员后台」和「小程序 API」拆成两组路由前缀例如/admin-api/与/wx-api/鉴权中间件各挂各的后面排查权限问题会省很多时间。2.2 Django 的 MVT 分层与 FBV、CBV 选择Django 的 MVT 里Model 管数据与业务约束View 管请求处理和响应Template 管渲染。这个项目给小程序供数时 Template 层基本用不上View 直接吐 JSON整体更接近「MVT 的骨架 REST 的皮」。所以 View 层的组织方式就成了第一个要定的事。FBV 写起来直白一个 URL 对一个函数适合登录、上传这种一次性逻辑CBV 配合 DRF 的ModelViewSet列表、详情、增删改可以一次生成适合抽样、巡检、认证这类标准 CRUD。我一般这样分# trace/urls.py from django.urls import path, include from rest_framework.routers import DefaultRouter from . import views router DefaultRouter() # 标准 CRUD 走 ViewSet一次生成 list/retrieve/create/update/destroy router.register(rshengzhang, views.ShengzhangJiluViewSet, basenameshengzhang) router.register(rchouyang, views.ChouyangViewSet, basenamechouyang) router.register(rxunjian, views.XunjianViewSet, basenamexunjian) router.register(rrenzheng, views.RenzhengViewSet, basenamerenzheng) urlpatterns [ path(api/, include(router.urls)), # 非标准逻辑单独用 FBV避免把 ViewSet 写成一锅粥 path(api/wx/login/, views.wx_login), path(api/trace/str:suyuanbianhao/, views.trace_detail), ]路由里basename必须显式给否则 ViewSet 没定义queryset属性时DefaultRouter会直接抛AssertionError这是新手第一个撞墙点。trace_detail用 FBV 是因为它要跨nongtianxinxi、shengzhangjiluziliao、chouyang三张表做聚合用 ViewSet 反而要把get_queryset写成条件分支可读性掉得厉害。2.3 小程序视图层与逻辑层的双线程通信微信小程序是双线程模型视图层跑 wxml、wxss逻辑层跑 js两层之间靠setData传数据中间还有一层 Native 做桥接。这意味着两件事一是逻辑层拿不到 DOM所有节点操作必须走选择器 API二是setData是跨线程序列化传大数据会明显卡顿。生长记录列表这种可能上百条的数据如果一次性setData({list: allData})中低端机首屏会肉眼可见地掉帧。常见做法是分页 只传增量// pages/jilu/list.js Page({ data: { list: [], page: 1, finished: false, loading: false }, onLoad() { this.loadPage(1); }, onReachBottom() { this.loadPage(this.data.page 1); }, loadPage(page) { if (this.data.loading || this.data.finished) return; this.setData({ loading: true }); wx.request({ url: ${getApp().globalData.baseUrl}/api/shengzhang/?page${page}, header: { Authorization: Bearer wx.getStorageSync(token) }, success: (res) { const rows res.data.results || []; this.setData({ // 增量拼接避免整表重设 list: page 1 ? rows : this.data.list.concat(rows), page, finished: !res.data.next }); }, complete: () this.setData({ loading: false }) }); } });onReachBottom是小程序页面级的上拉钩子只在页面配置允许滚动时触发finished由后端分页返回的next字段决定不要自己拿rows.length pageSize判断后端一旦改页大小逻辑就会错。Authorization走 header 而不是 query是因为 query 会被完整写进 Nginx 访问日志token 泄露风险高。2.4 域名、HTTPS 与基础库版本的硬约束小程序请求真实环境必须走 HTTPS且域名要提前在后台配置成 request 合法域名。很多人在开发者工具里勾了「不校验合法域名」跑得好好的一上真机就全红原因就是这里。约束项具体要求常见踩坑请求域名HTTPS已备案后台配置白名单只配了主域名图片域名没配图片全 403基础库版本与所用组件、API 对齐用了高版本 API低版本基础库直接报未定义本地调试关闭域名校验仅对工具生效真机预览不生效误判为后端挂了图片资源走 uploadFile 拿到的临时路径需转存直接把临时路径存库过期后图片全部失效基础库版本在开发者工具右上角「详情—本地设置」里看真机则是用户微信版本决定的。涉及新组件时在app.json里用requiredBackgroundModes之类能力要谨慎能不用就不用溯源类应用的兼容性比炫技重要。3. 溯源编号做主键之外MySQL 物理模型与 Django ORM 建模3.1 表清单与职责划分论文里给出的物理模型覆盖了storeup、config、shengzhangjiluziliao、chanpinleibie、nongtianxinxi、caozuorenyuan等表。实际工程里要先分清哪些是业务表哪些是框架复用表表名功能关键字段性质shengzhangjiluziliao生长记录资料suyuanbianhao、jilushijian、shengzhangjieduan核心业务表nongtianxinxi农田信息nongtianbianhao、nongtianmianji核心业务表jidixinxi基地信息jidibianhao、gongsimingcheng核心业务表chanpinleibie产品类别chanpinleibie字典表caozuorenyuan操作人员yonghuzhanghao、mima账号表storeup收藏userid、refid、tablename通用复用表config配置name、value通用复用表storeup的设计值得单独说一句它用tablename refid表达「某个用户收藏了某张表里的哪条记录」是一张多态关联表。好处是新增可收藏对象不用改表结构坏处是没法建外键删除业务数据时收藏记录会变成孤儿。我的处理方式是在业务删除接口里同步清理storeup而不是靠数据库级联。3.2 生长记录资料表 DDL 与字段语义这张表是整条溯源链的骨架字段设计直接决定查询效率CREATE TABLE shengzhangjiluziliao ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, suyuanbianhao varchar(200) NOT NULL COMMENT 溯源编号, jidibianhao varchar(200) DEFAULT NULL COMMENT 基地编号, jidimingcheng varchar(200) DEFAULT NULL COMMENT 基地名称, fuzeren varchar(200) DEFAULT NULL COMMENT 负责人, jiditupian longtext COMMENT 基地图片, gongsibianma varchar(200) DEFAULT NULL COMMENT 公司编码, gongsimingcheng varchar(200) DEFAULT NULL COMMENT 公司名称, nongtianbianhao varchar(200) DEFAULT NULL COMMENT 农田编号, nongtianmingcheng varchar(200) DEFAULT NULL COMMENT 农田名称, chanpinmingcheng varchar(200) DEFAULT NULL COMMENT 产品名称, chanpinleibie varchar(200) DEFAULT NULL COMMENT 产品类别, shengzhangjieduan varchar(200) DEFAULT NULL COMMENT 生长阶段, jilushijian datetime DEFAULT NULL COMMENT 记录时间, yonghuzhanghao varchar(200) DEFAULT NULL COMMENT 用户账号, xingming varchar(200) DEFAULT NULL COMMENT 姓名, PRIMARY KEY (id), KEY idx_suyuan (suyuanbianhao), KEY idx_suyuan_time (suyuanbianhao, jilushijian) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT生长记录资料;几个点容易忽略。第一suyuanbianhao不是主键而是业务上的链路标识同一批农产品会有多条生长记录共用同一个溯源编号所以它必须建索引但不能唯一。第二idx_suyuan_time这个联合索引是给「按溯源编号查记录、按时间排序」这个最高频查询准备的顺序不能反。第三jiditupian用longtext存的是图片路径或 Base64论文里给的4294967295长度实际上就是 longtext 的字节上限存路径的话完全是浪费但既然模型已经这么定了改类型前要先评估已有数据。第四字符集用utf8mb4因为基地名称、产品名称里出现生僻字和符号的概率不低。3.3 Django Model 与索引对齐数据库层定了索引ORM 层也要对齐否则 Django 每次迁移都会尝试重建# trace/models.py from django.db import models class ShengzhangJilu(models.Model): suyuanbianhao models.CharField(max_length200, db_indexTrue, verbose_name溯源编号) jidibianhao models.CharField(max_length200, blankTrue, nullTrue, verbose_name基地编号) jidimingcheng models.CharField(max_length200, blankTrue, nullTrue, verbose_name基地名称) jiditupian models.TextField(blankTrue, nullTrue, verbose_name基地图片) nongtianbianhao models.CharField(max_length200, blankTrue, nullTrue, verbose_name农田编号) chanpinmingcheng models.CharField(max_length200, blankTrue, nullTrue, verbose_name产品名称) chanpinleibie models.CharField(max_length200, blankTrue, nullTrue, verbose_name产品类别) shengzhangjieduan models.CharField(max_length200, blankTrue, nullTrue, verbose_name生长阶段) jilushijian models.DateTimeField(blankTrue, nullTrue, verbose_name记录时间) yonghuzhanghao models.CharField(max_length200, blankTrue, nullTrue, verbose_name用户账号) class Meta: db_table shengzhangjiluziliao indexes [ models.Index(fields[suyuanbianhao, jilushijian], nameidx_suyuan_time), ] ordering [-jilushijian]db_table必须显式写不然 Django 默认表名是trace_shengzhangjilu和已有库对不上。indexes里给的name要和数据库里已存在的索引名一致否则makemigrations会生成一条「删了再建」的迁移数据量大时这一步会锁表。注意TextField对应 longtext如果数据库里字段实际是 varchar迁移检测会持续报警告。要么改数据库要么在 Model 里改成CharField(max_length...)两边必须统一。3.4 迁移与种子数据新环境拉起时按顺序执行python manage.py makemigrations trace python manage.py migrate # 导入产品类别、基地等基础字典推荐用管理命令而不是手写 SQL python manage.py loaddata fixtures/chanpinleibie.json python manage.py createsuperuserloaddata读的是dumpdata导出的 JSON好处是字段变更后仍然能兼容导入。像产品类别这种字典表用固定 fixture 比让运维手工录更可靠也方便在测试库和生产库之间保持一致的枚举值。4. 抽样、巡检、认证三条业务链接口链路与权限实现4.1 接口清单与分页约定前端页面基本和表一一对应接口也就按业务表铺开但分页约定必须统一否则每个页面都要写一套解析逻辑。接口方法权限说明/api/wx/login/POST匿名code 换 token/api/trace/{编号}/GET匿名溯源详情聚合/api/chouyang/GET/POST登录抽样记录/api/xunjian/GET/POST登录巡检记录/api/renzheng/GET/POST管理员认证结果/api/shengzhang/GET/POST登录生长记录统一约定列表返回{count, next, previous, results}这是 DRF 默认分页器的结构小程序端只写一次解析就能复用。4.2 小程序端请求封装与登录态不要在每页里裸写wx.request封一层// utils/request.js const BASE https://your-domain.com; function request({ url, method GET, data {}, auth true }) { const header { content-type: application/json }; if (auth) { const token wx.getStorageSync(token); if (token) header.Authorization Bearer token; } return new Promise((resolve, reject) { wx.request({ url: BASE url, method, data, header, success: (res) { if (res.statusCode 401) { // 登录态过期清 token 并跳登录页避免死循环请求 wx.removeStorageSync(token); return reject(new Error(unauthorized)); } if (res.statusCode 400) return reject(new Error(res.data.detail || request failed)); resolve(res.data); }, fail: reject }); }); } export default request;登录态这一层要和 Django 侧的 token 校验对齐。Django 里用SESSION_COOKIE_AGE管后台会话小程序侧则用 DRF 的 token 或 JWT两套过期时间不要设成一样否则排查时容易判断错方向。4.3 抽样、巡检、认证的状态流转这三张业务表不是孤立的认证结果通常依赖抽样结论。业务上要限制没有抽样记录的批次不允许提交认证。这个约束放在序列化器里做# trace/serializers.py from rest_framework import serializers from .models import Renzheng, Chouyang class RenzhengSerializer(serializers.ModelSerializer): class Meta: model Renzheng fields __all__ def validate(self, attrs): bianhao attrs.get(suyuanbianhao) # 没有抽样记录直接拒避免出现无依据认证 if not Chouyang.objects.filter(suyuanbianhaobianhao).exists(): raise serializers.ValidationError(该溯源编号尚无抽样记录不能提交认证) # 抽样结论不合格时禁止认证 if Chouyang.objects.filter(suyuanbianhaobianhao, jielun不合格).exists(): raise serializers.ValidationError(存在不合格抽样记录) return attrs把校验放进validate而不是 View是为了让管理后台表单提交和 API 提交走同一套规则避免两条入口各写一遍。缺点是每次提交多两次查询对溯源这种低频写入场景完全可接受。4.4 图片上传与 longtext 字段处理基地图片、抽检照片这类内容正确做法是存相对路径文件本体落在对象存储或MEDIA_ROOT不要把 Base64 塞进longtext。小程序的wx.uploadFile返回的是临时文件路径必须转存wx.uploadFile({ url: BASE /api/upload/, filePath: tempFilePath, name: file, header: { Authorization: Bearer wx.getStorageSync(token) }, success: (res) { // 后端返回的是相对路径如 /media/jidi/2025/xxx.jpg const data JSON.parse(res.data); this.setData({ jiditupian: data.path }); } });Django 侧接request.FILES用FileSystemStorage落盘并返回 URL 前缀。存相对路径的好处是后续换域名、上 CDN 时只需改配置不用批量刷库。4.5 管理员与顾客的权限隔离用 DRF 的权限类按视图粒度控制比在函数里写if role ! admin清晰得多from rest_framework.permissions import BasePermission, IsAuthenticated class IsAdminRole(BasePermission): message 仅管理员可操作 def has_permission(self, request, view): return request.user.is_authenticated and getattr(request.user, role, ) admin class RenzhengViewSet(viewsets.ModelViewSet): queryset Renzheng.objects.all() serializer_class RenzhengSerializer def get_permissions(self): # 读放开、写收紧顾客能查认证结果但不能改 if self.action in (list, retrieve): return [IsAuthenticated()] return [IsAdminRole()]get_permissions按 action 分流是 DRF 里最省事的写法比自定义多个 ViewSet 好维护。注意message会被直接返回给小程序措辞别太技术化操作人员看得懂比什么都重要。5. 联调排错与溯源链完整性校验5.1 高频报错与定位顺序联调阶段绝大多数问题集中在四类按下面顺序查基本能覆盖现象大概率原因定位动作真机请求全部失败工具正常合法域名未配或证书问题看小程序后台域名配置再抓一次真机日志列表返回空但库里有数据权限过滤把数据全挡了或 queryset 默认过滤条件写错打印view.get_queryset().query看最终 SQL时间显示比实际早 8 小时USE_TZ与数据库时区不一致检查 settings 里的TIME_ZONE、USE_TZ与 MySQL 会话时区图片 404存了临时路径或 MEDIA 未配静态路由核对库里字段是不是以 /media/ 开头开发环境要挂 static 路由时区这条特别隐蔽MySQL 里datetime存的是裸时间Django 开了USE_TZTrue后会按 UTC 序列化。要么统一USE_TZFalse并且数据库时区设成东八区要么保持 True 让前端自己转两条路选一条走到底中途换会导致历史数据整体偏移。5.2 溯源链完整性校验上线前建议做一个校验脚本把「编号存在但没有生长记录」「有认证但无抽样」这类断链数据挖出来# trace/management/commands/check_chain.py from django.core.management.base import BaseCommand from django.db.models import Count from trace.models import ShengzhangJilu, Chouyang, Renzheng class Command(BaseCommand): help 校验溯源链完整性 def handle(self, *args, **options): broken [] # 有溯源编号但生长记录条数为 0 的认证记录 for rz in Renzheng.objects.all().iterator(): bh rz.suyuanbianhao if not ShengzhangJilu.objects.filter(suyuanbianhaobh).exists(): broken.append((bh, 缺少生长记录)) if not Chouyang.objects.filter(suyuanbianhaobh).exists(): broken.append((bh, 缺少抽样记录)) # 同一编号下重复的认证结果 dup Renzheng.objects.values(suyuanbianhao).annotate(cCount(id)).filter(c__gt1) for row in dup: broken.append((row[suyuanbianhao], 认证记录重复 %d 条 % row[c])) for bh, reason in broken: self.stdout.write(self.style.WARNING(%s - %s % (bh, reason))) self.stdout.write(共发现异常 %d 条 % len(broken))用.iterator()而不是直接遍历是为了避免把整表认证记录一次性读进内存几万条数据时差别很明显。这个命令可以直接挂到定时任务里每天跑一次输出重定向到日志文件断链数据就是最好的数据质量指标。最后一招把suyuanbianhao的生成规则固定下来——建议用「基地编号 农田编号 批次日期」拼接而不是自增 ID 或时间戳这样即便数据库整体迁移编号本身仍然能被人读懂出问题时运维不用查库就能判断是哪块地的货。本文还有配套的精品资源点击获取
Python+Django+微信小程序农产品溯源平台全链路实战
简介这是一份面向计算机专业学生与软件开发者的农产品溯源平台毕业设计论文文档围绕微信小程序前端与Python后端展开可用于课程设计、毕业设计选题参考及食品安全溯源类项目开发学习。论文完整覆盖绪论与研究背景、系统需求分析、软件架构与数据库设计、功能实现与总结展望等章节具体涉及B/S架构、小程序平台、Django框架、MySQL环境配置等关键技术并梳理了农产品信息记录追踪、抽样检测、质量认证、企业信息展示、生产基地与农田管理、生长记录资料等核心功能模块能够帮助读者理清从需求梳理到系统落地的完整思路。资源包内含1个docx文件压缩后约1.68MB便于直接查阅与二次参考。目前已有65人学习关注适合需要搭建农产品溯源系统或撰写同类论文的开发者借鉴其功能划分与设计逻辑。1. 扫一张二维码背后农产品溯源小程序真正卡住的地方消费者在超市拿起一盒番茄扫码后小程序里跳出基地编号、农田面积、负责人、最近一次抽检结论——听起来简单落地时最难的从来不是页面而是这条数据链怎么不断、不假、可查。这份「Python 基于微信小程序的农产品溯源平台」配套资源覆盖的是从需求分析、B/S 分层设计、MySQL 物理模型到小程序端与管理员后台的完整链路技术栈以 Python Django MySQL 微信小程序为主论文里出现的 Java、SSM 属于早期版本残留描述实际代码基线按 Python 走。它适合两类人一是做课程设计、毕业设计需要一套表关系清晰、前后端能跑通的同学二是做生鲜、农村电商类项目想借鉴「溯源编号 抽样 巡检 认证」这条业务主线的工程师。下面按架构选型、数据库落地、接口链路、排错校验的顺序拆开讲。2. Django MVT 与小程序双线程溯源平台的分层怎么切2.1 B/S 模式在溯源场景里的实际含义论文里反复提到 B/S 模式落到这个项目上其实有两层意思。第一层是消费者侧不装 App、不装插件微信里打开小程序就能查这决定了整个前端必须围绕小程序的渲染与网络能力来做而不是按传统 Web 页面来做。第二层是管理员侧基地信息、农田信息、抽样记录、认证结果这些录入工作走的是浏览器访问 Django 后台或自建管理页面不需要给每个基地装客户端。这个选择直接影响了接口形态。B/S 下的管理员端可以放心用表单提交、CSRF、Session但小程序端没有 Cookie 的天然继承关系登录态得靠wx.login换 code、后端换 openid 再签发 token两条链路的鉴权方式必须分开设计混用是很常见的坑。提示把「管理员后台」和「小程序 API」拆成两组路由前缀例如/admin-api/与/wx-api/鉴权中间件各挂各的后面排查权限问题会省很多时间。2.2 Django 的 MVT 分层与 FBV、CBV 选择Django 的 MVT 里Model 管数据与业务约束View 管请求处理和响应Template 管渲染。这个项目给小程序供数时 Template 层基本用不上View 直接吐 JSON整体更接近「MVT 的骨架 REST 的皮」。所以 View 层的组织方式就成了第一个要定的事。FBV 写起来直白一个 URL 对一个函数适合登录、上传这种一次性逻辑CBV 配合 DRF 的ModelViewSet列表、详情、增删改可以一次生成适合抽样、巡检、认证这类标准 CRUD。我一般这样分# trace/urls.py from django.urls import path, include from rest_framework.routers import DefaultRouter from . import views router DefaultRouter() # 标准 CRUD 走 ViewSet一次生成 list/retrieve/create/update/destroy router.register(rshengzhang, views.ShengzhangJiluViewSet, basenameshengzhang) router.register(rchouyang, views.ChouyangViewSet, basenamechouyang) router.register(rxunjian, views.XunjianViewSet, basenamexunjian) router.register(rrenzheng, views.RenzhengViewSet, basenamerenzheng) urlpatterns [ path(api/, include(router.urls)), # 非标准逻辑单独用 FBV避免把 ViewSet 写成一锅粥 path(api/wx/login/, views.wx_login), path(api/trace/str:suyuanbianhao/, views.trace_detail), ]路由里basename必须显式给否则 ViewSet 没定义queryset属性时DefaultRouter会直接抛AssertionError这是新手第一个撞墙点。trace_detail用 FBV 是因为它要跨nongtianxinxi、shengzhangjiluziliao、chouyang三张表做聚合用 ViewSet 反而要把get_queryset写成条件分支可读性掉得厉害。2.3 小程序视图层与逻辑层的双线程通信微信小程序是双线程模型视图层跑 wxml、wxss逻辑层跑 js两层之间靠setData传数据中间还有一层 Native 做桥接。这意味着两件事一是逻辑层拿不到 DOM所有节点操作必须走选择器 API二是setData是跨线程序列化传大数据会明显卡顿。生长记录列表这种可能上百条的数据如果一次性setData({list: allData})中低端机首屏会肉眼可见地掉帧。常见做法是分页 只传增量// pages/jilu/list.js Page({ data: { list: [], page: 1, finished: false, loading: false }, onLoad() { this.loadPage(1); }, onReachBottom() { this.loadPage(this.data.page 1); }, loadPage(page) { if (this.data.loading || this.data.finished) return; this.setData({ loading: true }); wx.request({ url: ${getApp().globalData.baseUrl}/api/shengzhang/?page${page}, header: { Authorization: Bearer wx.getStorageSync(token) }, success: (res) { const rows res.data.results || []; this.setData({ // 增量拼接避免整表重设 list: page 1 ? rows : this.data.list.concat(rows), page, finished: !res.data.next }); }, complete: () this.setData({ loading: false }) }); } });onReachBottom是小程序页面级的上拉钩子只在页面配置允许滚动时触发finished由后端分页返回的next字段决定不要自己拿rows.length pageSize判断后端一旦改页大小逻辑就会错。Authorization走 header 而不是 query是因为 query 会被完整写进 Nginx 访问日志token 泄露风险高。2.4 域名、HTTPS 与基础库版本的硬约束小程序请求真实环境必须走 HTTPS且域名要提前在后台配置成 request 合法域名。很多人在开发者工具里勾了「不校验合法域名」跑得好好的一上真机就全红原因就是这里。约束项具体要求常见踩坑请求域名HTTPS已备案后台配置白名单只配了主域名图片域名没配图片全 403基础库版本与所用组件、API 对齐用了高版本 API低版本基础库直接报未定义本地调试关闭域名校验仅对工具生效真机预览不生效误判为后端挂了图片资源走 uploadFile 拿到的临时路径需转存直接把临时路径存库过期后图片全部失效基础库版本在开发者工具右上角「详情—本地设置」里看真机则是用户微信版本决定的。涉及新组件时在app.json里用requiredBackgroundModes之类能力要谨慎能不用就不用溯源类应用的兼容性比炫技重要。3. 溯源编号做主键之外MySQL 物理模型与 Django ORM 建模3.1 表清单与职责划分论文里给出的物理模型覆盖了storeup、config、shengzhangjiluziliao、chanpinleibie、nongtianxinxi、caozuorenyuan等表。实际工程里要先分清哪些是业务表哪些是框架复用表表名功能关键字段性质shengzhangjiluziliao生长记录资料suyuanbianhao、jilushijian、shengzhangjieduan核心业务表nongtianxinxi农田信息nongtianbianhao、nongtianmianji核心业务表jidixinxi基地信息jidibianhao、gongsimingcheng核心业务表chanpinleibie产品类别chanpinleibie字典表caozuorenyuan操作人员yonghuzhanghao、mima账号表storeup收藏userid、refid、tablename通用复用表config配置name、value通用复用表storeup的设计值得单独说一句它用tablename refid表达「某个用户收藏了某张表里的哪条记录」是一张多态关联表。好处是新增可收藏对象不用改表结构坏处是没法建外键删除业务数据时收藏记录会变成孤儿。我的处理方式是在业务删除接口里同步清理storeup而不是靠数据库级联。3.2 生长记录资料表 DDL 与字段语义这张表是整条溯源链的骨架字段设计直接决定查询效率CREATE TABLE shengzhangjiluziliao ( id bigint NOT NULL AUTO_INCREMENT COMMENT 主键, addtime timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, suyuanbianhao varchar(200) NOT NULL COMMENT 溯源编号, jidibianhao varchar(200) DEFAULT NULL COMMENT 基地编号, jidimingcheng varchar(200) DEFAULT NULL COMMENT 基地名称, fuzeren varchar(200) DEFAULT NULL COMMENT 负责人, jiditupian longtext COMMENT 基地图片, gongsibianma varchar(200) DEFAULT NULL COMMENT 公司编码, gongsimingcheng varchar(200) DEFAULT NULL COMMENT 公司名称, nongtianbianhao varchar(200) DEFAULT NULL COMMENT 农田编号, nongtianmingcheng varchar(200) DEFAULT NULL COMMENT 农田名称, chanpinmingcheng varchar(200) DEFAULT NULL COMMENT 产品名称, chanpinleibie varchar(200) DEFAULT NULL COMMENT 产品类别, shengzhangjieduan varchar(200) DEFAULT NULL COMMENT 生长阶段, jilushijian datetime DEFAULT NULL COMMENT 记录时间, yonghuzhanghao varchar(200) DEFAULT NULL COMMENT 用户账号, xingming varchar(200) DEFAULT NULL COMMENT 姓名, PRIMARY KEY (id), KEY idx_suyuan (suyuanbianhao), KEY idx_suyuan_time (suyuanbianhao, jilushijian) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT生长记录资料;几个点容易忽略。第一suyuanbianhao不是主键而是业务上的链路标识同一批农产品会有多条生长记录共用同一个溯源编号所以它必须建索引但不能唯一。第二idx_suyuan_time这个联合索引是给「按溯源编号查记录、按时间排序」这个最高频查询准备的顺序不能反。第三jiditupian用longtext存的是图片路径或 Base64论文里给的4294967295长度实际上就是 longtext 的字节上限存路径的话完全是浪费但既然模型已经这么定了改类型前要先评估已有数据。第四字符集用utf8mb4因为基地名称、产品名称里出现生僻字和符号的概率不低。3.3 Django Model 与索引对齐数据库层定了索引ORM 层也要对齐否则 Django 每次迁移都会尝试重建# trace/models.py from django.db import models class ShengzhangJilu(models.Model): suyuanbianhao models.CharField(max_length200, db_indexTrue, verbose_name溯源编号) jidibianhao models.CharField(max_length200, blankTrue, nullTrue, verbose_name基地编号) jidimingcheng models.CharField(max_length200, blankTrue, nullTrue, verbose_name基地名称) jiditupian models.TextField(blankTrue, nullTrue, verbose_name基地图片) nongtianbianhao models.CharField(max_length200, blankTrue, nullTrue, verbose_name农田编号) chanpinmingcheng models.CharField(max_length200, blankTrue, nullTrue, verbose_name产品名称) chanpinleibie models.CharField(max_length200, blankTrue, nullTrue, verbose_name产品类别) shengzhangjieduan models.CharField(max_length200, blankTrue, nullTrue, verbose_name生长阶段) jilushijian models.DateTimeField(blankTrue, nullTrue, verbose_name记录时间) yonghuzhanghao models.CharField(max_length200, blankTrue, nullTrue, verbose_name用户账号) class Meta: db_table shengzhangjiluziliao indexes [ models.Index(fields[suyuanbianhao, jilushijian], nameidx_suyuan_time), ] ordering [-jilushijian]db_table必须显式写不然 Django 默认表名是trace_shengzhangjilu和已有库对不上。indexes里给的name要和数据库里已存在的索引名一致否则makemigrations会生成一条「删了再建」的迁移数据量大时这一步会锁表。注意TextField对应 longtext如果数据库里字段实际是 varchar迁移检测会持续报警告。要么改数据库要么在 Model 里改成CharField(max_length...)两边必须统一。3.4 迁移与种子数据新环境拉起时按顺序执行python manage.py makemigrations trace python manage.py migrate # 导入产品类别、基地等基础字典推荐用管理命令而不是手写 SQL python manage.py loaddata fixtures/chanpinleibie.json python manage.py createsuperuserloaddata读的是dumpdata导出的 JSON好处是字段变更后仍然能兼容导入。像产品类别这种字典表用固定 fixture 比让运维手工录更可靠也方便在测试库和生产库之间保持一致的枚举值。4. 抽样、巡检、认证三条业务链接口链路与权限实现4.1 接口清单与分页约定前端页面基本和表一一对应接口也就按业务表铺开但分页约定必须统一否则每个页面都要写一套解析逻辑。接口方法权限说明/api/wx/login/POST匿名code 换 token/api/trace/{编号}/GET匿名溯源详情聚合/api/chouyang/GET/POST登录抽样记录/api/xunjian/GET/POST登录巡检记录/api/renzheng/GET/POST管理员认证结果/api/shengzhang/GET/POST登录生长记录统一约定列表返回{count, next, previous, results}这是 DRF 默认分页器的结构小程序端只写一次解析就能复用。4.2 小程序端请求封装与登录态不要在每页里裸写wx.request封一层// utils/request.js const BASE https://your-domain.com; function request({ url, method GET, data {}, auth true }) { const header { content-type: application/json }; if (auth) { const token wx.getStorageSync(token); if (token) header.Authorization Bearer token; } return new Promise((resolve, reject) { wx.request({ url: BASE url, method, data, header, success: (res) { if (res.statusCode 401) { // 登录态过期清 token 并跳登录页避免死循环请求 wx.removeStorageSync(token); return reject(new Error(unauthorized)); } if (res.statusCode 400) return reject(new Error(res.data.detail || request failed)); resolve(res.data); }, fail: reject }); }); } export default request;登录态这一层要和 Django 侧的 token 校验对齐。Django 里用SESSION_COOKIE_AGE管后台会话小程序侧则用 DRF 的 token 或 JWT两套过期时间不要设成一样否则排查时容易判断错方向。4.3 抽样、巡检、认证的状态流转这三张业务表不是孤立的认证结果通常依赖抽样结论。业务上要限制没有抽样记录的批次不允许提交认证。这个约束放在序列化器里做# trace/serializers.py from rest_framework import serializers from .models import Renzheng, Chouyang class RenzhengSerializer(serializers.ModelSerializer): class Meta: model Renzheng fields __all__ def validate(self, attrs): bianhao attrs.get(suyuanbianhao) # 没有抽样记录直接拒避免出现无依据认证 if not Chouyang.objects.filter(suyuanbianhaobianhao).exists(): raise serializers.ValidationError(该溯源编号尚无抽样记录不能提交认证) # 抽样结论不合格时禁止认证 if Chouyang.objects.filter(suyuanbianhaobianhao, jielun不合格).exists(): raise serializers.ValidationError(存在不合格抽样记录) return attrs把校验放进validate而不是 View是为了让管理后台表单提交和 API 提交走同一套规则避免两条入口各写一遍。缺点是每次提交多两次查询对溯源这种低频写入场景完全可接受。4.4 图片上传与 longtext 字段处理基地图片、抽检照片这类内容正确做法是存相对路径文件本体落在对象存储或MEDIA_ROOT不要把 Base64 塞进longtext。小程序的wx.uploadFile返回的是临时文件路径必须转存wx.uploadFile({ url: BASE /api/upload/, filePath: tempFilePath, name: file, header: { Authorization: Bearer wx.getStorageSync(token) }, success: (res) { // 后端返回的是相对路径如 /media/jidi/2025/xxx.jpg const data JSON.parse(res.data); this.setData({ jiditupian: data.path }); } });Django 侧接request.FILES用FileSystemStorage落盘并返回 URL 前缀。存相对路径的好处是后续换域名、上 CDN 时只需改配置不用批量刷库。4.5 管理员与顾客的权限隔离用 DRF 的权限类按视图粒度控制比在函数里写if role ! admin清晰得多from rest_framework.permissions import BasePermission, IsAuthenticated class IsAdminRole(BasePermission): message 仅管理员可操作 def has_permission(self, request, view): return request.user.is_authenticated and getattr(request.user, role, ) admin class RenzhengViewSet(viewsets.ModelViewSet): queryset Renzheng.objects.all() serializer_class RenzhengSerializer def get_permissions(self): # 读放开、写收紧顾客能查认证结果但不能改 if self.action in (list, retrieve): return [IsAuthenticated()] return [IsAdminRole()]get_permissions按 action 分流是 DRF 里最省事的写法比自定义多个 ViewSet 好维护。注意message会被直接返回给小程序措辞别太技术化操作人员看得懂比什么都重要。5. 联调排错与溯源链完整性校验5.1 高频报错与定位顺序联调阶段绝大多数问题集中在四类按下面顺序查基本能覆盖现象大概率原因定位动作真机请求全部失败工具正常合法域名未配或证书问题看小程序后台域名配置再抓一次真机日志列表返回空但库里有数据权限过滤把数据全挡了或 queryset 默认过滤条件写错打印view.get_queryset().query看最终 SQL时间显示比实际早 8 小时USE_TZ与数据库时区不一致检查 settings 里的TIME_ZONE、USE_TZ与 MySQL 会话时区图片 404存了临时路径或 MEDIA 未配静态路由核对库里字段是不是以 /media/ 开头开发环境要挂 static 路由时区这条特别隐蔽MySQL 里datetime存的是裸时间Django 开了USE_TZTrue后会按 UTC 序列化。要么统一USE_TZFalse并且数据库时区设成东八区要么保持 True 让前端自己转两条路选一条走到底中途换会导致历史数据整体偏移。5.2 溯源链完整性校验上线前建议做一个校验脚本把「编号存在但没有生长记录」「有认证但无抽样」这类断链数据挖出来# trace/management/commands/check_chain.py from django.core.management.base import BaseCommand from django.db.models import Count from trace.models import ShengzhangJilu, Chouyang, Renzheng class Command(BaseCommand): help 校验溯源链完整性 def handle(self, *args, **options): broken [] # 有溯源编号但生长记录条数为 0 的认证记录 for rz in Renzheng.objects.all().iterator(): bh rz.suyuanbianhao if not ShengzhangJilu.objects.filter(suyuanbianhaobh).exists(): broken.append((bh, 缺少生长记录)) if not Chouyang.objects.filter(suyuanbianhaobh).exists(): broken.append((bh, 缺少抽样记录)) # 同一编号下重复的认证结果 dup Renzheng.objects.values(suyuanbianhao).annotate(cCount(id)).filter(c__gt1) for row in dup: broken.append((row[suyuanbianhao], 认证记录重复 %d 条 % row[c])) for bh, reason in broken: self.stdout.write(self.style.WARNING(%s - %s % (bh, reason))) self.stdout.write(共发现异常 %d 条 % len(broken))用.iterator()而不是直接遍历是为了避免把整表认证记录一次性读进内存几万条数据时差别很明显。这个命令可以直接挂到定时任务里每天跑一次输出重定向到日志文件断链数据就是最好的数据质量指标。最后一招把suyuanbianhao的生成规则固定下来——建议用「基地编号 农田编号 批次日期」拼接而不是自增 ID 或时间戳这样即便数据库整体迁移编号本身仍然能被人读懂出问题时运维不用查库就能判断是哪块地的货。本文还有配套的精品资源点击获取
