凌晨两点半，蔬菜批发市场的大棚下已经灯火通明。交易高峰只有短短几个小时，商户手写的记账单挤在一起，过磅员扯着嗓子报价，采购商推着电动三轮车在摊位间来回穿梭。这是黄瓜批发市场最真实的日常，也是我当初做这套基于Python+Django的黄瓜批发市场管理系统时，脑子里反复回放的场景。
这套系统解决的是农产品批发环节最朴素的问题：商户台账混乱、库存批次不清、价格随行就市难以追溯、一天下来对账全凭手写单据。它不是一个贴着“管理系统”标签的玩具项目，而是一套完整覆盖商户入驻、批次入库、称重计价、销售结算、价格行情记录、库存损耗追踪的后台管理工具，附带源码、论文（lw）、部署文档和讲解视频，适合正在学Django想做一个完整实战项目的开发者，也适合给中小型农产品批发市场做信息化改造的同学参考。
我当时接手这个项目的时候，第一反应是“批发市场的管理系统能有多复杂”，真正把业务捋清楚之后才发现，黄瓜这种保鲜期短、价格波动大、交易时段集中的农产品，对系统的要求其实一点都不比电商系统低。这篇文章我会把整个项目的设计思路、核心模块实现、常见的坑以及部署流程完整拆开讲，里面的代码和配置都是从实际项目中截出来的，你可以直接照着改。
1. 重复造轮子之前，先把黄瓜批发市场的业务流程搞清楚
1.1 批发市场的真实交易场景
很多人一听“批发市场管理系统”，下意识会拿超市进销存那套逻辑去套，实际上两者差别非常大。黄瓜批发市场的交易有明显的时段集中性，凌晨三四点是成交高峰，商户和采购商都是熟客交易，价格不是标价扫码那种模式，而是“看货定价”，也就是当天行情决定基础价，再根据黄瓜的品相、新鲜度上下浮动。
系统如果照搬零售逻辑，做成POS收银那套东西，商户根本用不惯。批发商户的习惯是：货到了先记一笔入库，卖的时候过磅、口头谈价、开单、拉走，晚上或者次日早上再统一对账。所以系统的核心入口不应该放在“收银台”上，而应该放在“入库登记”和“过磅开单”这两个高频动作上。
1.2 系统需要覆盖的核心业务环节
把批发市场的业务流程拆开，可以分成这么几个环节：
- 商户入驻与摊位管理：市场管理方需要维护商户档案、摊位号、联系方式。
- 黄瓜品类维护：黄瓜不是单一商品，常见的有密刺黄瓜、水果黄瓜、旱黄瓜、荷兰黄瓜等，不同品类价格不一样。
- 批次入库登记：商户进货回来后，按批次登记来源、数量、进价。这是后续库存和损耗管理的基础。
- 过磅与销售开单：采购商选货后，按实际称重重量和双方谈定的单价，生成销售单。
- 库存与损耗登记：黄瓜含水量高、皮薄，运输和存放过程容易损耗，需要单独记录损耗量。
- 价格行情记录：每天记录各品类的最低成交价、最高成交价、均价，作为行情日报的基础数据。
- 结算对账：按商户维度汇总一天的销售额、进货额、损耗，生成对账单。
这套系统的App划分也是围绕这几个环节来的，我建了merchant、product、inventory、sale、price这五个业务App，加上一个accounts做用户和权限管理。这样拆的好处是每个App的模型和视图职责单一，后续要扩展功能，比如加一个“摊位费收取”模块，直接新建一个App或者往merchant里加视图就行，不会把代码搅成一团。
1.3 哪些人适合拿这个项目做参考
如果你是Django初学者，跟着教程做过博客、做过投票系统，想找一个带真实业务场景的项目练手，这很适合。这个系统的复杂程度刚好卡在一个很舒服的位置：比CRUDdemo复杂，因为它有多表关联、批次扣减、状态流转这些逻辑；但又没复杂到需要微服务、消息队列那种程度，一个人完全能hold住。
如果你是在做毕业设计，这个项目的好处是业务场景明确、技术栈主流，论文方面也好展开。市场需求分析可以写批发市场数字化程度低、传统管理方式效率低下；技术设计可以写Django MTV架构、ORM数据建模、模板渲染；系统测试可以写功能测试和部署验证。整个逻辑链条是完整的，不是东拼西凑的“假项目”。
2. 技术选型不是拍脑袋，Python+Django在这类项目里的真实优势
2.1 为什么不用Java或者PHP
聊选型之前得先说清楚一个前提：这不是一个高并发系统。黄瓜批发市场的业务峰值也就是凌晨那两三个小时，同时在线操作的人员数量撑死几十个，这点流量对任何主流后端框架来说都是小意思。与其纠结性能，不如纠结开发效率和维护成本。
Java的Spring Boot在这个场景里属于“杀鸡用牛刀”，项目初始化成本高，写一个简单的增删改查要配置一堆东西。PHP的Laravel做这类系统也很快，但国内中小型项目的部署环境里，Python的生态和资料丰富程度对新手更友好。选Python+Django，核心原因有两个：一是Django自带的Admin后台，能直接省掉一整套后台管理页面的开发量；二是ORM和数据迁移机制，对表结构经常调整的开发阶段来说太舒服了。
2.2 MTV架构的请求处理流程
Django的MTV模式，说穿了就是浏览器发起请求之后，URL路由把请求交给对应的视图函数，视图函数操作模型层（Model）读写数据库，把数据塞给模板（Template）渲染成HTML页面，最后返回给浏览器。
这个项目里我自己定义了几个视图函数和类视图，核心业务逻辑放在视图里，模型层只负责数据定义和简单的业务约束。比如销售开单这个操作，视图层要做的动作是：接收前端传来的商户ID、品类ID、重量、单价，先开启一个数据库事务，创建销售订单记录，再扣减对应批次的库存量，最后更新当日价格行情。这一个流程涉及三张表的写入，如果不用事务包裹，中间任何一步出错都会造成库存和订单对不上，所以我在视图函数里显式使用了transaction.atomic()。
2.3 项目结构和App划分
实际项目的目录结构大概是这样的：
cucumber_market/ ├── manage.py ├── cucumber_market/ # 项目主配置 │ ├── settings.py │ ├── urls.py │ ├── wsgi.py │ └── asgi.py ├── accounts/ # 用户与权限 ├── merchant/ # 商户与摊位 ├── product/ # 品类管理 ├── inventory/ # 批次库存与损耗 ├── sale/ # 销售订单 ├── price/ # 价格行情 ├── static/ # 静态文件 ├── templates/ # 共用模板 └── media/ # 上传文件创建App的命令很简单：
python manage.py startapp merchant python manage.py startapp product每新建一个App，记得去settings.py的INSTALLED_APPS里注册。这个步骤很容易漏，漏了之后makemigrations不会报错，只是不认这个App的模型，排查起来很费时间。
3. 数据库模型设计：先建模再写代码，能少走一半弯路
3.1 实体关系和关键模型
数据库设计是这个项目最关键的部分，表结构如果有问题，后面写业务逻辑会越写越别扭。我梳理出来的核心实体有这么几个：商户（Merchant）、黄瓜品类（CucumberCategory）、进货批次（StockBatch）、销售订单（SaleOrder）、销售明细（SaleOrderItem）、价格记录（PriceRecord）。
商户模型我设计成和Django自带的User一对一关联，这样登录认证直接复用Django的auth模块，商户档案里存摊位号、电话、等级这些额外信息：
from django.db import models from django.contrib.auth.models import User class Merchant(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, verbose_name='关联账号') name = models.CharField('商户名称', max_length=100) stall_no = models.CharField('摊位号', max_length=20, unique=True) phone = models.CharField('联系电话', max_length=20) level = models.IntegerField('评级', default=0, help_text='0-5星') class Meta: verbose_name = '商户' verbose_name_plural = verbose_name def __str__(self): return f'{self.stall_no} - {self.name}'黄瓜品类模型比较轻量，就是名称、单位、备注。但要注意，类比超市的商品编码要简单得多，批发市场通常不会用条形码管理，品类粒度也没那么细，同一个商户进的同一批密刺黄瓜，就是一个品类一条记录。
3.2 库存为什么要拆批次而不是只记总量
这是整个数据库设计里我认为最重要的一点。很多新手做进销存，习惯只在一张表里记个“当前库存数量”，销售了就减一下。这个设计对黄瓜批发市场来说有两个致命问题。
第一，黄瓜不同批次的进价不同，如果混在一起记总量，你没办法核算每一批货的毛利。第二，黄瓜有保鲜期，批次需要按时间先后出库，先到的先卖，否则旧货压在库底烂掉，损耗算谁的说不清楚。
所以我把库存设计成了批次制，每个StockBatch记录一批货的入库数量、已售数量、当前剩余、进价、状态：
class StockBatch(models.Model): STATUS_CHOICES = [ ('IN', '在库'), ('SOLD_OUT', '售罄'), ('LOSS', '损耗'), ] merchant = models.ForeignKey(Merchant, on_delete=models.PROTECT, verbose_name='商户') category = models.ForeignKey(CucumberCategory, on_delete=models.PROTECT, verbose_name='品类') batch_no = models.CharField('批次号', max_length=32, unique=True) origin_quantity = models.DecimalField('入库数量(公斤)', max_digits=10, decimal_places=2) remaining_quantity = models.DecimalField('剩余数量(公斤)', max_digits=10, decimal_places=2) unit_price = models.DecimalField('进价(元/公斤)', max_digits=8, decimal_places=2) source = models.CharField('货源地', max_length=100) status = models.CharField('状态', max_length=10, choices=STATUS_CHOICES, default='IN') put_in_time = models.DateTimeField('入库时间', auto_now_add=True) class Meta: ordering = ['put_in_time'] verbose_name = '进货批次' verbose_name_plural = verbose_name批次号我推荐用时间戳加随机数的组合，比如B202506120001，这样不会和别的批次冲突，做表格筛选也方便。销售扣减库存的时候，按put_in_time升序找到第一个有剩余量的批次进行扣减，也就是“先进先出”。
3.3 DecimalField与FloatField的选择
关于金额、重量、价格这类字段，我强烈建议用DecimalField而不是FloatField。浮点数在计算机里是二进制近似表示的，0.1 + 0.2 会等于 0.30000000000000004，这在涉及钱的计算里是绝对不能忍的。
DecimalField需要指定max_digits和decimal_places。金额字段我用的max_digits=10, decimal_places=2，重量字段用max_digits=10, decimal_places=2，也就是精确到0.01公斤，精度足够批发称重了。
销售订单和销售明细我拆成了两张表，订单表记录一笔交易的整体信息，明细表记录这场交易里包含的每个品类。这样设计是为了应对一次采购商在同一摊位买了密刺黄瓜又买了水果黄瓜的情况：
class SaleOrder(models.Model): order_no = models.CharField('订单号', max_length=32, unique=True) merchant = models.ForeignKey(Merchant, on_delete=models.PROTECT, verbose_name='商户') buyer_name = models.CharField('采购商', max_length=50) total_amount = models.DecimalField('总金额', max_digits=10, decimal_places=2) created_at = models.DateTimeField('成交时间', auto_now_add=True) class SaleOrderItem(models.Model): order = models.ForeignKey(SaleOrder, related_name='items', on_delete=models.CASCADE) category = models.ForeignKey(CucumberCategory, on_delete=models.PROTECT) quantity = models.DecimalField('数量(公斤)', max_digits=10, decimal_places=2) unit_price = models.DecimalField('成交单价(元/公斤)', max_digits=8, decimal_places=2) amount = models.DecimalField('小计金额', max_digits=10, decimal_places=2)4. 核心业务功能的实现细节与踩坑记录
4.1 权限体系：让不同角色看到不同内容
系统里有三种角色：系统管理员、市场管理方、商户。Django自带了一套基于用户、分组、权限的机制，不需要完全自定义。最省事的方式是给每个用户设置is_staff和is_superuser，再给业务分组分配add_*、change_*、delete_*权限。
商户登录后只能操作自己的库存和销售单，这个控制建议在视图层做。我写了一个工具函数，在视图里取当前登录用户关联的商户对象，然后所有查询都加上merchant=self_merchant这个过滤条件。
def get_merchant_for_user(user): """根据当前登录用户获取对应的商户档案""" if user.is_superuser: return None try: return Merchant.objects.get(user=user) except Merchant.DoesNotExist: return None有了这个函数之后，所有涉及数据隔离的视图都会先判断当前用户是不是管理员，如果是管理员可以看全部数据，如果是普通商户就只看自己的数据。
4.2 称重计价与销售开单的完整流程
销售开单是使用频率最高的功能。它的流程是：选择商户（管理员操作时）或自动带出当前商户、选择黄瓜品类、输入称重数量、输入成交单价、系统自动计算小计金额。
这里有一个细节：批发市场的成交单价不是系统设定的，而是双方谈出来的。所以在开单页面，单价字段必须是可编辑的输入框，不能是自动带出的固定价格。一开始我把单价设计成从价格行情表里自动带出均价，被一个市场管理员一句话点醒了：“今天的黄瓜早上一个价，中午一个价，行情表里的均价是事后算的，你让我开单的时候用均价卖，我这生意没法做。”这个反馈很宝贵，系统设计一定要贴合真实操作习惯。
视图函数里创建订单和扣库存这两个动作，必须放在同一个事务里：
from django.db import transaction from django.utils import timezone from .models import SaleOrder, SaleOrderItem, StockBatch @transaction.atomic def create_sale_order(request, merchant, category, quantity, unit_price): order_no = timezone.now().strftime('%Y%m%d%H%M%S') + str(random.randint(1000, 9999)) order = SaleOrder.objects.create( order_no=order_no, merchant=merchant, buyer_name='现场采购商', total_amount=round(float(quantity) * float(unit_price), 2) ) SaleOrderItem.objects.create( order=order, category=category, quantity=quantity, unit_price=unit_price, amount=order.total_amount ) # 扣减库存（先进先出） remaining = quantity batches = StockBatch.objects.filter( merchant=merchant, category=category, status='IN' ).order_by('put_in_time') for batch in batches: if remaining <= 0: break if batch.remaining_quantity >= remaining: batch.remaining_quantity -= remaining remaining = 0 else: remaining -= batch.remaining_quantity batch.remaining_quantity = 0 if batch.remaining_quantity == 0: batch.status = 'SOLD_OUT' batch.save() if remaining > 0: raise ValueError('库存不足') return order这段代码里最容易被忽略的是最后那个if remaining > 0。如果库里剩余量不足，事务会抛异常回滚，订单不会保存，库存也不会被扣。如果不加这个判断，会出现库存扣成负数、订单依然创建的脏数据。
4.3 损耗处理：黄瓜最绕不开的痛点
黄瓜从产地装车到摆上摊位，中间要经过装卸、分拣、存放，磕碰伤和失水都会造成损耗。系统不能假装损耗不存在，否则库存数据会越来越虚，最后账面有货实际没货。
损耗处理我单独设计了一个损耗登记模块，商户每天收摊前对剩余库存做一次盘点，有损耗就登记一笔，记录损耗数量、原因（磕碰、腐烂、失水）、备注。库存扣减时优先扣减损耗量，然后再按先进先出扣减正常销售量。
class LossRecord(models.Model): REASON_CHOICES = [ ('BRUISE', '磕碰'), ('ROT', '腐烂'), ('DEHYDRATE', '失水'), ('OTHER', '其他'), ] merchant = models.ForeignKey(Merchant, on_delete=models.PROTECT) batch = models.ForeignKey(StockBatch, on_delete=models.PROTECT) quantity = models.DecimalField('损耗数量(公斤)', max_digits=8, decimal_places=2) reason = models.CharField('损耗原因', max_length=20, choices=REASON_CHOICES) note = models.CharField('备注', max_length=200, blank=True) created_at = models.DateTimeField('登记时间', auto_now_add=True)损耗登记页面我加了二次确认弹窗，因为损耗量一旦登记错了，库存就平白少了一截，而且损耗不像销售单有金额收入，查起来很麻烦。这里建议增加一个“损耗审批”功能，只有市场管理方的账号才能审核通过损耗单，商户只能提交申请。这是我在项目中后期才意识到的问题，一开始商户自己登记自己确认，月底对账的时候发现损耗数据明显偏大，有些把卖掉的货也记成损耗了。
4.4 价格行情：让历史数据产生价值
批发市场的信息化价值，很大程度上体现在价格行情的积累上。每天的开盘价、最高价、最低价、收盘价，如果只留在商户脑子里，市场管理方就永远没有数据做分析和展示。
价格行情记录模块的逻辑是：每天凌晨新增一组空的价格记录，当天的实时成交价会不断更新最低价和最高价，收盘后计算均价。这个功能用Django的update_or_create很容易实现：
PriceRecord.objects.update_or_create( category=category, record_date=timezone.now().date(), defaults={ 'low_price': min(current_low, new_price), 'high_price': max(current_high, new_price), } )行情数据展示这块，我用了一个比较朴素但实用的方案：列表页展示最近30天的价格走势表格，配合一个简单的趋势图。趋势图如果没有前端基础，不建议自己去手写图表库，用一个叫Chart.js的库，后端渲染数据为JSON，前端直接用折线图展示，效果很能打。
5. Django Admin后台：为什么说它是这个项目的隐形功臣
5.1 默认Admin能用，但离好用还有距离
Django自带的Admin后台，注册了模型之后就能直接对数据进行增删改查，这对系统前期开发帮助巨大。但直接拿默认后台给市场管理员用，体验还是差一些。主要是列表页显示太简陋、搜索不友好、操作按钮不够直观。
我的建议是，前期开发阶段全部用默认Admin，快速验证数据模型和业务逻辑；系统快上线的时候，再花两天时间做Admin的定制优化。
5.2 自定义Admin类的基础配置
在对应的admin.py里注册模型时，通过继承admin.ModelAdmin来自定义列表页展示字段、搜索字段、筛选字段：
from django.contrib import admin from .models import StockBatch @admin.register(StockBatch) class StockBatchAdmin(admin.ModelAdmin): list_display = ('batch_no', 'merchant', 'category', 'origin_quantity', 'remaining_quantity', 'unit_price', 'status', 'put_in_time') list_filter = ('status', 'category', 'put_in_time') search_fields = ('batch_no', 'merchant__name', 'merchant__stall_no') list_editable = ('status',) date_hierarchy = 'put_in_time' ordering = ('-put_in_time',) }这里有几个很实用的点：
list_display定义列表页显示的列，注意关联字段要用merchant__name这种双下划线写法。list_filter生成右侧筛选栏，对状态、日期这种字段非常有用。search_fields定义搜索框能搜哪些字段，关联字段同样用双下划线。date_hierarchy会在列表页顶部生成一个可以按日期逐层钻取的时间筛选条，查看某一天的交易记录极其方便。list_editable允许在列表页直接编辑字段值，比如批量调整批次状态，省得点进详情页。
5.3 Admin界面美化：不写前端代码也能做出像样的后台
如果要在市场管理方的电脑上直接操作，建议给Admin后台套一个现代化的UI主题。目前生态里比较成熟的是 SimpleUI 和 django-jet，我用的是 SimpleUI，原因是它配置简单、中文文档完善、不用改现有逻辑。
安装：
pip install django-simpleui然后在INSTALLED_APPS里把simpleui放到django.contrib.admin之前：
INSTALLED_APPS = [ 'simpleui', 'django.contrib.admin', # ... 其他App ]就这么两步，再刷新后台页面，整个界面就从土里土气的Django默认风格变成了现代化侧边栏布局。SimpleUI还支持自定义首页、隐藏不需要的模块、按用户显示不同菜单，这些配置项可以在官方文档里查到，不赘述。
5.4 内联模型解决主从表数据录入问题
销售订单和销售明细是一对多关系。默认情况下，管理员需要先创建一个订单，然后再到另一个页面给这个订单添加明细，体验很差。Django Admin的TabularInline可以把明细和主表放到同一个页面录入：
class SaleOrderItemInline(admin.TabularInline): model = SaleOrderItem extra = 1 @admin.register(SaleOrder) class SaleOrderAdmin(admin.ModelAdmin): list_display = ('order_no', 'merchant', 'total_amount', 'created_at') inlines = [SaleOrderItemInline]用了inline之后，管理员在订单编辑页面就能直接增加、删除明细行，保存主表的时候明细分录一并写入，整个操作体验提升非常大。
6. 部署上线环节的实战记录
6.1 开发环境与生产环境的配置切换
项目开发阶段用的是Django自带的SQLite数据库和开发服务器，上线部署需要切换到MySQL（或者PostgreSQL，但国内用MySQL居多）。我习惯在settings.py里区分开发与生产两套配置，不通过手动改代码切换，而是通过环境变量控制。
import os import pymysql pymysql.install_as_MySQLdb() DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': os.environ.get('DB_NAME', 'cucumber_market'), 'USER': os.environ.get('DB_USER', 'root'), 'PASSWORD': os.environ.get('DB_PASSWORD', ''), 'HOST': os.environ.get('DB_HOST', '127.0.0.1'), 'PORT': os.environ.get('DB_PORT', '3306'), } }需要说明的是，pymysql.install_as_MySQLdb()是为了让Django的MySQL后端能找到驱动，Python3环境里不再原生支持MySQLdb。这个方案在Python 3.8以下版本很常见，但到了Python 3.9以上，建议直接用mysqlclient，因为pymysql不支持MySQL 8.0的caching_sha2_password认证方式。如果遇到Authentication plugin 'caching_sha2_password' cannot be loaded错误，要么给MySQL用户改成mysql_native_password认证，要么换mysqlclient。
6.2 生产环境必需的settings修改
上线前有几个配置是必须改的：
DEBUG = False ALLOWED_HOSTS = ['your.domain.com', '123.456.78.90']DEBUG=False之后，Django不再处理静态文件，所以需要先收集静态文件到指定目录：
python manage.py collectstatic在settings.py里正确配置：
STATIC_URL = '/static/' STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles') MEDIA_URL = '/media/' MEDIA_ROOT = os.path.join(BASE_DIR, 'media')另外时区问题要特别留意。Django项目默认USE_TZ=True，数据库里存的是UTC时间，如果你在页面上直接展示created_at，会发现时间比北京时间晚了8个小时。解决方法是设置：
TIME_ZONE = 'Asia/Shanghai' USE_TZ = True如果设置为USE_TZ=False，Django会直接使用本地时间存库，虽然省事，但后续如果系统要对接其他服务或者迁移，UTC才是更规范的做法。我建议保留USE_TZ=True，页面模板里用{{ record.created_at | date:"Y-m-d H:i:s" }}展示时，Django会自动按当前时区转换。但如果视图里做时间运算，一定要用timezone.now()而不是datetime.now()，这个坑我踩过好几次。
6.3 部署文档的意义和内容组织
这套系统附带部署文档，我把部署过程整理成了一份step by step的文档，实际上这是整个交付物里除了源码之外最值钱的部分。很多初学者照着网上零碎的教程部署Django项目，数据库驱动装不上、静态文件404、时区不对、权限不足，各种问题叠在一起，很容易崩溃。
部署文档我建议至少包含以下内容：
- 服务器环境说明：操作系统版本、Python版本、MySQL版本。
- 系统依赖安装命令：包括Python、pip、venv、MySQL、Nginx的安装。
- 项目代码上传和虚拟环境创建步骤。
- 依赖包安装命令：
pip install -r requirements.txt。 - 数据库配置和迁移命令。
- 静态文件收集配置。
- Nginx + Gunicorn 的配置文件和启动命令。
- 常见问题排查：端口占用、静态文件404、数据库连接拒绝等。
用Gunicorn启动Django应用的命令示例：
pip install gunicorn gunicorn cucumber_market.wsgi:application -b 127.0.0.1:8000 --daemonNginx配置里，关键是把/static/和/media/的请求直接映射到对应目录，把其他请求反向代理到Gunicorn监听的端口：
server { listen 80; server_name your.domain.com; location /static/ { alias /var/www/cucumber_market/staticfiles/; } location /media/ { alias /var/www/cucumber_market/media/; } location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }6.4 数据库从SQLite迁移到MySQL的坑
开发阶段一直用SQLite，迁移到MySQL的时候常见的坑有两个。第一个是数据量大了以后，SQLite里的自增ID到MySQL里默认是从1开始，需要手动设置自增起点，否则可能ID冲突。第二个是字符集问题，MySQL数据库和表的utf8mb4一定要配好，不然存入中文或者其他特殊字符时会报Incorrect string value的错误。
创建数据库时指定字符集：
CREATE DATABASE cucumber_market DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;迁移数据的稳妥做法是，先用Django的dumpdata把数据导出为JSON，然后切换到MySQL配置，再migrate建表，最后用loaddata导回数据。注意dumpdata导出的时候可能会把一些计算字段也导出来，导入时如果报错，把--natural-foreign参数加上，用自然外键而不是ID来关联数据。
7. 这套系统的后续扩展方向
项目做完并不代表这套系统的生命力就到头了。结合我在批发市场观察到的情况，至少有几个方向是值得继续做的。
第一个是数据可视化大屏。市场管理方其实很想把行情数据投到市场入口的大屏上，让采购商一进门就能看到今天的黄瓜行情、各商户的入驻信息。Django后端只需要提供一个返回JSON的API接口，大屏前端用ECharts或者DataV去渲染，技术上没有难点，但效果非常直观。
第二个是移动端适配。商户普遍用手机操作，Django模板渲染的PC端页面在手机上体验一般。短期内不需要做原生App，做一个针对移动端屏幕优化的H5页面，或者用Django REST Framework提供API接口，前端用uni-app或微信小程序做，体验会好很多。
第三个是对接电子秤和扫码设备。批发市场的过磅流程如果能把电子秤的数据直接读到系统里，就省去了手工录入重量的环节。多数电子秤都有RS232串口或者蓝牙接口，硬件对接这块需要写一些串口通讯代码，Python的pyserial库可以做，但需要根据具体秤的型号定制协议。这个方向比较硬核，但对批发市场来说价值很大，能显著提高过磅开单效率。
第四个是支付和结算打通。批发市场目前大量交易还是现金和微信转账，系统如果能生成带订单号的收款二维码，或者对接聚合支付接口，管理员的对账工作能减轻不少。这个方向涉第三方支付平台的资质申请，个人开发者不好搞，但系统完全可以先把“应收应付台账”做好，为将来对接预留接口。
我在实际做这个项目的过程中，最大的体会是：一个管理系统能不能被市场真正用起来，关键不在于技术多花哨，而在于它是不是贴合业务里的真实操作习惯。商户不会因为你的界面好看就用它，但会因为每天对账能省半小时而离不开它。所以无论你是拿这个项目练手Django，还是真的想给某个批发市场做信息化改造，都建议先去现场蹲一个凌晨的交易高峰，感受一下真实的业务流程，然后再打开编辑器写代码。这个习惯，比会任何框架都值钱。
