Django充电桩管理系统：核心设计、数据库建模与计费实战解析

我一直觉得Django 这类业务管理系统最不缺的就是“能跑的项目”最缺的是“能讲清楚为什么这么设计”的源码。最近在整理一个新能源汽车充电管理系统前后花了大概两周时间把核心模块撸完顺手把源码也打包了一份。这篇文章就围绕这个项目聊聊系统设计、数据库建模、核心业务逻辑和部署踩坑尽量把每个关键决策背后的原因也讲清楚让拿到源码的朋友不只是会启动更能真正看懂、能改、能扩展。1. 系统整体设计与思路拆解1.1 充电管理系统的真实业务需求在动手写代码之前先想明白一件事一个充电管理系统到底要解决谁的什么问题从运营方角度看痛点很直接充电桩分布在多个站点每根桩是空闲、占用还是故障靠人工巡检根本不现实用户充了电电费怎么结算、服务费怎么收、余额够不够扣全靠手工账本迟早要乱设备接入、异常报警、月度营收统计这些都是运营决策的刚需。从用户角度讲最关心的是三件事附近哪里有空闲桩、充电状态能不能实时看到、充完电到底扣了多少钱。这三件事对应到系统里就是站点信息展示、充电订单实时状态追踪、计费账单明细。从开发者角度呢这类系统其实是一个非常典型的“带状态流转的业务系统”充电桩有状态、订单有状态、支付有状态而且各个状态之间是有约束关系的。状态管理做清楚了整个系统的骨架就稳了。这套系统的核心模块我拆成了四块用户与权限、站点与充电桩管理、充电订单与计费、数据统计与报表。用户端提供扫码充电、订单查看、余额充值与消费记录管理端则是桩的维护、价格策略配置、订单管理、异常处理。前后台共用一套 Django 工程只是通过不同的视图和权限层做隔离避免维护两套后端。1.2 技术选型为什么是 Django 而不是 Flask 或 Spring Boot这个项目选择 Django不是因为它最流行而是因为它和“管理类业务系统”的匹配度最高。Django 自带 Admin 后台在不写一行前端代码的情况下就能完成基础数据管理自带 ORM充电桩、订单这类实体的增删改查和关联查询非常顺手自带用户认证体系把 AbstractUser 扩展一下就能满足用户表字段定制自带 Migrations 迁移机制模型改动后同步数据库结构比手写 SQL 高效得多。和 Flask 对比Flask 的优势是轻量灵活但业务系统需要的那套东西——Admin、Auth、ORM、表单校验——在 Flask 里都得自己拼装开发效率低不少对于一个需要快速交付、且业务规则有一定复杂度的项目来说Django 的全家桶方案更合适。和 Spring Boot 对比Java 生态在企业级场景确实更重更稳但对于中小型充电运营场景Python Django 的开发成本和迭代速度优势明显而且只要数据库设计和事务控制做到位业务正确性同样有保证。这个项目如果一开始用 Spring Boot光环境搭建和依赖管理就会多花不少时间。实际开发中我做了一个小对比供参考维度DjangoFlaskSpring Boot开发效率高内置组件全中需自行组装中低配置较多内置管理后台自带开箱即用需扩展需集成ORM 能力强适合复杂关联弱依赖扩展强但学习成本高适合场景业务管理系统轻量API服务大型企业级平台这套系统选择 Django 的另外一个原因是它的 ORM 在做“按站点统计充电量”“按桩查询订单列表”这类聚合查询时非常直观不需要写一堆原生 SQL。后文会具体展示这些查询怎么落地。1.3 项目整体目录结构与模块划分源码的目录结构遵循 Django 工程的标准约定但做了一点针对充电业务的特别设计。项目名我定为 charging_system核心应用有两个accounts 负责用户认证与授权charging 负责站点、充电桩、订单、计费等核心业务。这样拆分的原因很简单——把用户体系独立成 app后续哪怕新增小程序端、管理端用户模型都不用动。charging app 内部按业务对象又分了几个模块文件每个文件只聚焦一件事。models.py 只放数据模型views.py 只放视图函数services.py 专门放计费引擎和订单状态流转这类核心业务逻辑。为什么要单独拆一个 services.py因为视图里的代码应该只负责“接请求、调服务、返回结果”而计费规则、状态判断这种可能被多个入口复用的逻辑放在服务层里才是正确的位置。如果将来有新的入口接入比如 API 接口依然可以直接复用 services 里的方法。静态资源和模板也做了区分用户端用 Bootstrap 做响应式页面管理端用 Admin 搭配 SimpleUI 皮肤报表页面用 ECharts 渲染柱状图和折线图。静态文件统一放在 static 目录下模板放在 templates 下并区分 user 和 admin 两个子目录。2. 核心功能设计与数据库模型拆解2.1 四大核心模块的功能边界系统不追求大而全而是先把充电业务最核心的闭环做完整。第一是用户端功能注册登录、个人资料、余额充值、充电消费记录、账单导出。第二是站点管理功能站点名称、地址、经纬度、充电桩数量统计、站点状态管理。第三是充电桩管理功能桩编号、类型交流/直流、功率、状态空闲/充电中/离线/故障、实时电价关联。第四是订单计费功能用户扫码启动充电、记录充电开始时间与起始电量、充电期间状态更新、结束充电时计算费用并扣费。这四个模块的依赖关系是站点包含充电桩充电桩产生订单订单关联用户并按规则计费。数据流向非常清晰所以数据库模型的设计也遵循这条主线。2.2 用户扩展模型与权限设计用户这块Django 自带的 User 模型字段够用但不够用——够用的是账号密码邮箱这些基础字段不够用的是手机号、余额、积分这类业务字段。所以直接采用继承 AbstractUser 的方式扩展新增 phone、balance、avatar、gender 等字段。余额字段必须用 DecimalField 而不是 FloatField这点我在代码里加了非常明确的注释。浮点数在二进制下没法精确表示十进制小数0.1 加 0.2 这种看似简单的问题在计算机里会变成 0.30000000000000004金额计算一旦出现这种误差对账的时候就会莫名多出几分钱。DecimalField(max_digits10, decimal_places2) 配合 Django 的 Decimal 对象可以保证金额精度。权限方面用户角色分为普通用户、站点管理员、超级管理员。超级管理员用 Django 自带的 is_superuser 字段即可站点管理员则通过一个 Profile 的 role 字段区分。普通用户只允许操作自己的订单和自己的余额这个限制我不仅在前端隐藏了按钮后端视图里也做了二次校验避免有人绕过前端直接构造请求。2.3 充电桩与站点的模型字段全解析站点表 Station 的主要字段有名称 name、地址 address、经度 longitude、纬度 latitude、联系电话 contact_phone、状态 status。经纬度字段我用的是 DecimalField 加 max_digits9 和 decimal_places6这个精度大约能定位到 0.1 米级别足够用于地图展示和附近站点查询。充电桩表 ChargingPile 的核心字段如下class ChargingPile(models.Model): PILE_TYPE_CHOICES ( (AC, 交流桩), (DC, 直流桩), ) STATUS_CHOICES ( (IDLE, 空闲), (CHARGING, 充电中), (OFFLINE, 离线), (FAULT, 故障), ) pile_no models.CharField(充电桩编号, max_length32, uniqueTrue) station models.ForeignKey(Station, on_deletemodels.CASCADE, verbose_name所属站点) pile_type models.CharField(桩类型, max_length10, choicesPILE_TYPE_CHOICES, defaultAC) power models.DecimalField(功率(kW), max_digits6, decimal_places2) status models.CharField(当前状态, max_length10, choicesSTATUS_CHOICES, defaultIDLE) price_per_kwh models.DecimalField(电价(元/度), max_digits5, decimal_places2) service_fee_per_kwh models.DecimalField(服务费(元/度), max_digits5, decimal_places2) create_time models.DateTimeField(创建时间, auto_now_addTrue)桩编号使用唯一约束就是既要避免重复录入也方便后续对接硬件设备时用它作为通信标识。状态字段只定义了四种状态没有搞得太复杂。实际业务中桩的状态可能更多比如“预约中”“维护中”但对于第一版系统四种状态足够覆盖核心场景了。桩类型和功率是关联的交流桩一般是 7kW 或者 22kW直流桩则是 30kW 到 120kW 不等设计时把这个作为展示信息同时也可用于后台的功率负荷统计。状态设计这块我走了不少弯路纠结过“到底应该用 CharField 还是 IntegerField”。最后选择 CharField 配合语义化常量纯粹是因为代码可读性好。订单状态用数字编号虽然省空间但看到order.status 2的时候没人知道 2 是什么意思。用CHARGING表达状态代码即文档。2.4 充电订单与计费相关表设计订单表是所有业务逻辑中最重要的表。字段设计直接决定了后续计费、对账、统计的复杂度。class ChargeOrder(models.Model): STATUS_CHOICES ( (PENDING, 待支付), (CHARGING, 充电中), (FINISHED, 已完成), (CANCELLED, 已取消), (REFUNDED, 已退款), ) order_no models.CharField(订单编号, max_length64, uniqueTrue) user models.ForeignKey(User, on_deletemodels.PROTECT, related_nameorders) pile models.ForeignKey(ChargingPile, on_deletemodels.PROTECT, related_nameorders) start_time models.DateTimeField(开始充电时间) end_time models.DateTimeField(结束充电时间, nullTrue, blankTrue) start_kwh models.DecimalField(起始电量(kWh), max_digits10, decimal_places2, nullTrue, blankTrue) end_kwh models.DecimalField(结束电量(kWh), max_digits10, decimal_places2, nullTrue, blankTrue) total_kwh models.DecimalField(充电量(kWh), max_digits10, decimal_places2, nullTrue, blankTrue) amount models.DecimalField(订单金额(元), max_digits10, decimal_places2, nullTrue, blankTrue) status models.CharField(订单状态, max_length10, choicesSTATUS_CHOICES, defaultCHARGING) create_time models.DateTimeField(创建时间, auto_now_addTrue)订单编号采用“日期 随机串”的生成方式比如 20250612103015 加 6 位随机字母而不是自增 ID。为什么因为订单号要暴露给用户查看如果直接用自增 ID用户可以猜到订单量也容易被枚举遍历。随机订单号这件事成本很低但安全性提升明显。还有几个字段的设计值得注意。起始电量允许为空因为一部分老旧桩不返回实时电量数据只能按充电时长估算。结束时间和结束电量都允许为空因为充电可能异常中断这时候需要人工介入。订单金额也允许为空只有充电结束后才回填避免“先填一个预估金额然后后续还要改”的数据一致性麻烦。使用on_deletemodels.PROTECT而不是 CASCADE这个细节我特别说明一下用户或者充电桩一旦有了订单记录就不应该被直接删除。业务数据要保留删除用户会把历史账单一起删掉这在真实运营中是不可接受的。PROTECT 会在尝试删除时报错强制操作者改用停用或软删除的方式。计费相关的计算不需要单独建表因为每度电的价格已经冗余存储在了充电桩表里订单金额只需要在结束充电时根据充电量和单价相乘得出即可。但要注意如果未来开放“分时电价”或者“会员折扣”那价格策略就需要独立成表了到时候订单里的金额字段就成了冗余快照这是后话。3. 关键业务逻辑与计费规则的代码实现3.1 充电启动流程状态校验与订单创建用户点击“开始充电”后后端要做的第一件事是校验不是生成订单。这个顺序特别重要。def start_charging(request, pile_id): pile get_object_or_404(ChargingPile, pkpile_id) if pile.status ! IDLE: return JsonResponse({code: 400, msg: 该充电桩当前不可用}) # 并发情况下防止重复启动 with transaction.atomic(): updated ChargingPile.objects.select_for_update().filter( pkpile.pk, statusIDLE ).update(statusCHARGING) if not updated: return JsonResponse({code: 400, msg: 该充电桩已被占用}) order ChargeOrder.objects.create( order_nogenerate_order_no(), userrequest.user, pilepile, start_timetimezone.now(), statusCHARGING ) return JsonResponse({code: 200, data: {order_id: order.id}})这里的核心是transaction.atomic()配合select_for_update()。想象一下两个用户同时扫码同一根空闲桩不加锁的话两个人都通过了status ! IDLE的判断然后各自创建了一条充电订单这根桩就被充电两次了。普通系统可能觉得无所谓最多浪费点数据但充电桩是物理设备同一时间只能给一辆车充电这种并发错误会直接导致真实世界的事故。行级锁的原理是在 SELECT 查询时对命中的行加写锁事务提交前其他事务无法修改这一行。第二个请求执行到 update 时发现状态已经变成 CHARGINGupdated 为 0于是直接返回“已被占用”。这就是并发环境下正确的业务判断方式。3.2 计费引擎设计阶梯价与动态费用计费是充电系统里最容易出 bug 的地方。这个项目的计费支持两种模式普通固定单价和按功率区间阶梯单价。实现时我写了一个独立的计费函数放在 services.py 中def calculate_fee(pile, start_kwh, end_kwh, charge_duration): kwh end_kwh - start_kwh # 阶梯电价逻辑不同功率区间不同单价 if pile.pile_type DC and pile.power 60: unit_price pile.price_per_kwh * Decimal(1.2) else: unit_price pile.price_per_kwh energy_fee kwh * unit_price service_fee kwh * pile.service_fee_per_kwh total energy_fee service_fee return total.quantize(Decimal(0.01), roundingROUND_HALF_UP)特别注意最后的quantize操作。这是 Decimal 的精确舍入方法ROUND_HALF_UP 表示四舍五入。为什么不用 Python 内置的 round因为 round 遵循“银行家舍入”规则遇到 0.005 这类边界值会舍成偶数而不是我们预期的一律进位。计费金额的舍入规则必须在代码层面明确否则同样的充电量和单价不同环境跑出来可能差一分钱财务对账会非常头疼。计费函数设计成独立函数还有一个好处单元测试非常好写。我写了一组测试用例覆盖了普通桩、大功率桩、边界值舍入、零电量等场景每次改动模型字段或者规则时跑一遍测试就知道有没有影响核心计费逻辑。实际测试中发现一个隐藏问题如果桩上报的电量不是递增的比如车辆中途断电重启导致电量倒退那 end_kwh - start_kwh 就会变成负数。因此计费前要先做异常处理当 kwh 为负值时记录异常日志并把订单标记为异常待人工处理而不是直接扣费。3.3 结束充电与账户余额扣减结束充电的流程比启动更复杂因为涉及金额计算和余额扣减两件事而这两件事之间必须保证要么都成功、要么都失败。def finish_charging(order_id): with transaction.atomic(): order ChargeOrder.objects.select_for_update().get(pkorder_id) if order.status ! CHARGING: raise BusinessException(订单状态异常无法重复结算) pile order.pile end_kwh get_end_kwh_from_device(pile) end_time timezone.now() kwh end_kwh - order.start_kwh if kwh 0: kwh Decimal(0) # 记录异常日志标记人工处理 amount calculate_fee(pile, order.start_kwh, end_kwh, end_time - order.start_time) order.end_kwh end_kwh order.end_time end_time order.total_kwh kwh order.amount amount order.status FINISHED order.save() user User.objects.select_for_update().get(pkorder.user_id) if user.balance amount: # 余额不足订单置为待支付状态 order.status PENDING order.save() return {code: 400, msg: 余额不足请充值后再支付} user.balance - amount user.save() BalanceLog.objects.create( useruser, orderorder, change-amount, balance_afteruser.balance, remark充电消费 )事务保证了金额计算和扣费的原子性。如果扣费成功但订单状态没有更新用户会发现钱扣了订单还是充电中这是很不好的体验。反过来如果订单更新了但扣费失败钱对不上账更麻烦。这两步操作必须放进同一个事务。另外在扣费前我又查了一遍用户余额为什么因为充电开始到结束可能过去了半小时甚至更久用户可能在此期间有另一笔消费把余额花掉了一部分。如果不用select_for_update在读余额时锁住这行并发场景下两个事务同时读到余额 100各自扣掉 80最后数据库里剩下 20但实际应该扣两次变 -60这就是经典的“丢失更新”问题。用行锁串行化这一行的读写才能避免超扣。余额流水表 BalanceLog 几乎是必须的。用户对账、客服排查、财务审计都靠它。字段包含当前余额快照 balance_after这是为了在余额变更后能追溯当时的账户状态否则只能看到一笔 -80 的流水却不知道这 -80 是在余额 100 还是 1000 的基础上扣的。3.4 电量统计与多维度数据报表运营系统没有统计报表就等于白做。充电量、营收、客单价、站点利用率这些指标直接决定运营策略。Django ORM 对这类聚合查询支持得很好下面这个查询是统计某站点下每天的充电量与营收from django.db.models import Sum, Count, F report_data ( ChargeOrder.objects .filter(pile__stationstation, statusFINISHED, end_time__isnullFalse) .annotate(dayF(end_time__date)) .values(day) .annotate( total_kwhSum(total_kwh), total_amountSum(amount), order_countCount(id) ) .order_by(day) )F 表达式可以引用模型字段进行运算F(end_time__date)表示取 end_time 的日期部分。这个查询一次数据库往返就把站点每天的数据全部统计出来了性能比 Python 层循环累加高得多。管理端展示的图表我使用的是 ECharts后端提供 JSON 接口返回聚合结果前端用 Ajax 请求后渲染折线图和饼图。折线图展示近 30 天充电量趋势饼图展示站点营收占比柱状图对比交流桩和直流桩的利用率。数据可视化在这类系统里的价值在于运营人员不需要看数据库报表打开首页就能知道哪个站点忙、哪个站点闲以及哪个站点的服务费定价可能有问题。4. 系统环境搭建与全流程启动4.1 开发与部署环境准备这个项目是基于 Python 3.10 Django 4.2 开发的。为什么选 Django 4.2因为这是 4.x 系列的 LTS 长期支持版本至少能持续收到安全更新比追最新的 5.x 更稳。数据库使用 MySQL 8.0本地开发时也可以切到 SQLite只需要改一下 DATABASES 配置。环境准备这里我踩过很多次坑整理一下最稳妥的顺序# 1. 创建虚拟环境避免污染全局 Python python3 -m venv venv source venv/bin/activate # 2. 安装依赖 pip install django4.2.* mysqlclient pillow django-simpleuimysqlclient 这个包在 macOS 和 Linux 上偶尔会安装失败因为它是编译型包依赖系统的 mysql_config 工具。如果遇到报错先通过系统包管理器安装 MySQL 开发库再重试。Windows 上则是另一个故事建议直接换用 pymysql 并在项目入口加入pymysql.install_as_MySQLdb()这行兼容代码。4.2 Settings 核心配置注意事项配置方面有几个点特别容易出问题。第一是时区如果USE_TZ TrueDjango 默认使用 UTC 时间但国内的业务系统无论展示还是计费都应该用本地时间。折中方案是数据库存储 UTC 时间然后设置TIME_ZONE Asia/Shanghai同时保持USE_TZ TrueDjango 会自动在存储和读取时做时区转换。这个方案的好处是数据库里所有时间都是 UTC以后做跨地域扩展时不会混乱页面显示和订单时间则自动换算成北京时间。这里有个很隐蔽的坑如果USE_TZ True直接用 Python 的datetime.now()生成的 naive datetime 写入模型字段Django 会直接报错。必须使用django.utils.timezone.now(),或者datetime.now(timezone.utc)。我最初就是在这个问题上卡了半小时报错信息提示 RuntimeWarning 但程序照样跑数据里的时间却差整整 8 个小时。第二是静态文件配置STATIC_URL和MEDIA_URL需要正确指定媒体文件目录用来存放用户上传的头像和站点图片。部署到生产环境时还要注意Django 默认不托管静态文件需要交给 Nginx 来处理。4.3 数据库迁移与初始数据数据库迁移是整个启动流程里最容易出错的一步。顺序是先改好模型然后生成迁移文件python manage.py makemigrations accounts charging python manage.py migratemakemigrations 会对比模型定义和数据库当前状态生成增量迁移脚本。migrate 则按顺序执行这些脚本。如果模型改了但没执行迁移启动系统时会看到 “table xxx has no column named yyy” 之类的报错。初始数据方面我准备了一个init_data.py脚本放在项目根目录运行后会自动创建几个测试站点和十几根充电桩同时生成一个测试账号方便拿到源码的朋友快速进入体验状态不用自己去后台手动录入。桩编号和站点编码都是模拟数据但字段格式和真实场景一致可以当作后续导入真实数据的模板。4.4 项目启动与测试运行启动前先做一次系统性检查这一步能避免 90% 的启动问题# 检查项目配置是否有错误 python manage.py check # 创建超级管理员账号 python manage.py createsuperuser # 启动开发服务器 python manage.py runserver 0.0.0.0:8000浏览器访问http://127.0.0.1:8000就是用户端页面访问http://127.0.0.1:8000/admin进入管理后台。登录超级管理员后可以看到站点管理、充电桩管理、订单管理全部功能模块。如果页面样式丢失检查静态文件配置和python manage.py collectstatic是否执行过。这是一个新手高频问题十个人里至少有四个人会在这里卡住但排查方向非常固定。4.5 生产部署方案简述开发服务器runserver是单线程且性能很弱只适合本地调试绝对不能用于生产。生产环境我采用的标准组合是 Nginx Gunicorn MySQL。Gunicorn 负责运行 Django 应用Nginx 反向代理处理静态资源和流量转发。部署时还需要设置环境变量把 SECRET_KEY、DEBUG、数据库密码等敏感信息从代码里拆出来这点非常重要。很多项目源码在 Git 仓库里直接明文写着数据库密码一旦仓库泄露整个生产环境就裸奔了。使用os.environ.get(DJANGO_SECRET_KEY)方式读取环境变量就算代码被看到了没有环境变量也跑不起来。还有几个生产环境的硬性要求DEBUG 必须设为 FalseALLOWED_HOSTS 必须配置为实际域名所有请求强制 HTTPS关闭 Debug 页面防止异常信息泄露。我用一个检查清单每次部署前逐项确认检查项目开发环境生产环境DEBUGTrueFalseALLOWED_HOSTS空配置域名SECRET_KEY固定伪随机环境变量注入静态文件Django 托管Nginx 托管数据库SQLite/MySQLMySQL5. 常见问题与排查技巧实录5.1 时区导致的时间错乱问题这类问题最典型的症状是订单时间显示“上午 8 点”实际充电发生在“下午 4 点”。排查步骤很简单先用 Django Shell 检查当前时间和timezone.now()是否一致from django.utils import timezone print(timezone.now())如果输出的是 UTC 时间需要检查TIME_ZONE和USE_TZ配置。我遇到过用户反馈订单结束时间比开始时间早 7 个多小时的情况——因为电池管理系统上报时间用的是本地时间而 Django 以 UTC 解析造成 8 小时偏移而当时恰好在夏令时和非夏令时切换期又有额外偏差。最后统一约定所有设备上报时间戳一律携带时区标识后端统一转 UTC 存储展示时再转换。约定越清晰问题越少。5.2 数据库迁移报错与字段变更的坑迁移报错最典型的场景是修改了模型字段后直接运行 migrate系统提示 “column does not exist”。原因是 makemigrations 只对比了之前的迁移文件和当前模型不会自动同步数据库里的实际结构。解决方法是先让模型与上一次迁移保持一致然后重新生成迁移文件。另外如果在已有数据的表里新增非空字段且没有给默认值migrate 会报错提示需要先提供默认值或允许为空。比如给充电桩表新增一个 rating 字段时如果直接加CharField(max_length10)会因为存量数据无法满足非空约束而失败。正确做法是加default或nullTrue或者分两步走先新增可空字段迁移后填充数据再修改为不可空。这个操作顺序非常重要。5.3 并发请求导致的超扣或重复订单超扣问题前面讲过并发锁的解决方案但实际开发中还有另一类更容易被忽略的情况MySQL 默认隔离级别是 REPEATABLE READ在这个隔离级别下两个事务同时更新同一行时如果没有 SELECT FOR UPDATE后提交的事务覆盖前一个事务的修改。我负责的一个早期项目里用户在充电结束瞬间正好在另一台设备上充了值结果余额显示充值成功但扣费却是用旧余额扣的账务平不了。排查后就是缺少select_for_update。给所有“读-改-写”操作都加上行锁这个坑才算彻底填平。这类并发问题很难在功能测试阶段暴露因为单个用户操作很难触发。我在项目里留了一个并发测试脚本模拟 20 个线程同时抢同一根桩用来验证锁是否生效。第一次跑这个脚本时真的复现了重复订单修完锁之后再去跑就只剩一个成功了。5.4 前端跨域与接口对接注意事项如果这个项目的 API 后续要对接小程序或者 App跨域问题就会冒出来。开发环境下可以采用 django-cors-headers 这个组件配置CORS_ALLOWED_ORIGINS即可。生产环境如果接口由 Nginx 代理同域部署则不存在跨域问题。需要注意的另一点是 CSRFDjango 对 POST 请求有 CSRF 校验小程序端请求没有带 cookie 里的 csrftoken会被 Django 拒绝。解决方案是使用 JWT 代替 Django Session 认证或者为 API 专门设置csrf_exempt但显然后者不安全不推荐。5.5 充电桩状态不同步的异常处理真实场景中充电桩硬件和服务器之间的状态可能因为网络波动出现不同步。桩显示充电中服务端订单已经结束服务端显示空闲桩其实还在充电。这类问题无法完全避免但可以通过定时对账任务来弥补。系统里我写了一个 audit 命令每五分钟拉取一次桩的上报状态并与数据库比对如果发现不一致记录告警日志并自动修正桩状态。这个命令通过 Crontab 定时调度稳定性比 Celery 定时任务简单得多适合中小型项目。这里要强调一个思路当硬件状态和软件状态不一致时永远以设备上报为准不要以软件自动判断为准。因为软件可能因为 bug 误判而设备的物理状态是事实。自动修正的逻辑是设备上报“空闲”数据库是“充电中”那订单大概率已经完成了需要人工确认设备上报“充电中”数据库是“空闲”那可能是有人还没有下单就插枪了这时候应该触发异常告警而不是自动改状态。6. 系统后续的扩展方向与二次开发建议6.1 计费策略的扩展空间当前系统采用的是固定单价和简单阶梯价对于大多数场景够用了。但如果运营方想推出分时电价高峰时段贵、低谷时段便宜就需要增加一个价格策略表配置不同时间段的价格系数。订单金额不再直接由单价计算而是根据充电过程中不同时段的电量分段累计。这种设计对计费函数的影响较大建议一开始就把计费入口收敛在 services.py 里扩展时只改这一个函数和新增一张表不用动视图层。计费引擎的未来方向还有会员折扣、套餐包、优惠券抵扣。哪怕现在不做设计订单表时也要预留一个 discount_amount 字段避免后续加需求时做数据库大迁移。6.2 地图周边站点推荐功能用户端目前是列表方式展示站点体验上还有很大提升空间。接入地图 SDK 后可以根据用户当前经纬度按距离排序返回附近的充电站并用地图打点展示空闲桩数量、功率类型、当前电价。后端需要增加一个按距离排序的接口MySQL 8.0 支持空间数据类型可以用 ST_Distance_Sphere 函数直接计算球面距离性能也不错。6.3 小程序端接口复用Django 的视图函数天然支持返回 JSON 数据只需要在视图函数里判断请求方式就能同时支持页面和小程序接口。建议下一步把核心接口抽出独立的 url 路径加上/api/前缀配合 Django REST Framework 做序列化和权限控制。前端页面的接口可以继续沿默认路径小程序端走/api/一套后端两端用同时也为后续前后端分离打基础。目前在充电桩上实现订单查询、余额充值等能力用 Django REST Framework 的 ViewSet 和 Router 可以很快搞定序列化器复用现有的模型定义返回字段可以灵活裁剪不必把多余的管理字段暴露给客户端。6.4 设备接入协议与远程监控当前系统和硬件设备的对接是模拟的实际生产环境需要接入具体的充电桩通信协议。常见的对接方式是 OCPPOpen Charge Point Protocol桩端通过 WebSocket 主动上报状态变化服务端可以下发启动、停止指令。这样系统架构会新增一层消息中间层但订单状态流转依然复用的是现有的底层逻辑只需要把设备状态同步的逻辑替换成监听 OCPP 消息。如果是中小型充电站也可以采用更轻量的 MQTT 协议每个充电桩作为一个主题发布者后端订阅所有桩的状态消息再用通道推送状态变化到用户端页面实时展示。我个人测试下来充电管理系统这类项目核心复杂度从来不在技术本身而在于业务状态的完整流转。把充电桩状态、订单状态、支付状态理清楚这套系统就等于成功了一大半。最后再分享一个小技巧开发这类业务系统一定要从最开始就保留状态变更日志哪怕只是简单地记录“谁在什么时间把哪个字段从 A 改成 B”。线上出问题的时候这些日志就是最重要的排查线索。我自己在开发过程中就靠这个功能快速定位过一个异常充电订单——用户说没充过电但订单显示完成日志显示是运维人员用后台误操作的几行日志就解释清楚了来龙去脉。这个习惯比任何高级框架和花哨功能都值钱。