做物流管理系统这件事，我在好几个项目里反复折腾过，技术栈也从最开始的单体 PHP 一路换到 Python 后端加 Vue 前端的组合。说实话，标题里提到“Python 基于 Vue 的物流管理系统”，落到实际开发场景中，就是一套典型的前后端分离项目：后端负责订单、车辆、司机、仓储这些业务数据的处理，前端用 Vue 做操作界面，PyCharm 作为日常开发工具。这篇文章就按我自己的实操路径，把从选型、建模、接口、联调到部署的完整过程拆开来讲，包括踩过的坑和优化细节，给准备做类似系统的朋友一个可以直接参考的蓝本。
1. 技术栈怎么定：Django 还是 Flask，前端为什么选 Vue
1.1 后端框架的取舍逻辑
很多人一上来就在 Django 和 Flask 之间纠结。我的建议是：先看你的业务形态，再选框架，不要凭“哪个火”来定。
物流管理系统本质上是一个偏数据管理的系统，订单要建表、车辆要建表、用户要建表，还有大量增删改查操作和权限控制。这种场景下，Django 的优势非常明显：自带 ORM、自带 Admin 后台、自带用户认证体系，甚至自带迁移工具，能省掉大半的基础设施搭建时间。比如你要给仓库管理员做一个简单的数据录入界面，Django Admin 直接配置一下就能用，这在项目早期非常救命。
Flask 也不是没有用武之地，它更适合接口数量少、业务逻辑简单、或者你已经有现成数据库和前端页面、只需要一套轻量 API 的场景。但一旦业务复杂起来，你会发现用户认证要自己写、ORM 要自己配、表单校验要自己造轮子，工作量会逐渐堆高。
我在实际项目中采用了一个折中方案：主框架用 Django，但所有核心业务接口都走 Django REST Framework，不走 Django 的模板渲染。前端完全交给 Vue，Django 只作为纯后端 API 服务。这样既保留了 Django 的开发效率，又维持了前后端分离的灵活性，后续如果要把接口拆成微服务，也不会伤筋动骨。
如果你的团队里有人只熟悉 Python 不熟悉前端，初期可以用 Django Admin 顶一下后台管理，再逐步用 Vue 页面替换。这不是偷懒，是务实的迭代策略。
1.2 前端框架与 IDE 的配合
前端选 Vue，主要看中的是它的渐进式特性。物流管理系统里有大量的表单页面、表格页面、状态流转组件，Vue 的双向绑定和组件化开发在处理这类交互时非常顺手。相比 React 的学习曲线，Vue 对后端开发者友好得多，模板语法直观，状态管理用 Pinia 或 Vuex 也不会绕太多弯。
配合 PyCharm 开发时要注意一个细节：PyCharm 专业版对 Vue 的支持比较完善，包括模板语法高亮、指令补全和 refactor 功能，但社区版基本只能当作纯文本编辑器使用。我用的是 PyCharm 专业版，配合 Node.js 插件，前后端代码可以在同一个 IDE 里管理，调试的时候可以同时开两个终端，一个跑 Django，一个跑 Vue 开发服务器，效率比来回切编辑器高不少。
另一个容易被忽略的点是 Python 解释器配置。PyCharm 里新建项目时，建议直接为后端代码创建虚拟环境，Python 版本用 3.10 或 3.11 都行，别用太老的版本，否则一些新库装不上。前端部分不要硬塞进同一个解释器环境，Vue 依赖的是 Node 生态，跟 Python 虚拟环境无关，两者独立运行、通过 HTTP 通信。
2. 环境准备与工程初始化实操
2.1 PyCharm 下的项目目录规划
一个前后端分离项目，如果目录从一开始就乱掉，后面会非常痛苦。我的标准目录结构是这样规划的：
logistics_system/ ├── backend/ # Django 后端 │ ├── manage.py │ ├── config/ # 项目配置 │ ├── apps/ │ │ ├── orders/ # 订单模块 │ │ ├── fleet/ # 车辆模块 │ │ ├── users/ # 用户模块 │ │ └── reports/ # 报表模块 │ └── requirements.txt ├── frontend/ # Vue 前端 │ ├── src/ │ │ ├── api/ # 接口封装 │ │ ├── views/ # 页面组件 │ │ ├── router/ # 路由配置 │ │ └── store/ # 状态管理 │ ├── package.json │ └── vite.config.js └── docs/ # 文档创建顺序有讲究。先在 PyCharm 里新建一个空白项目，然后分别初始化后端和前端。后端用 Django 命令创建，前端用 Vite 脚手架创建，比手动建目录靠谱得多。
后端初始化建议直接使用 Django REST Framework 的组合模板，命令如下：
django-admin startproject config . python manage.py startapp orders python manage.py startapp fleet python manage.py startapp users这里有个细节：startproject config .后面的点是让配置文件生成在当前目录，而不是再套一层目录。很多初学者忽略这个点，导致后面所有 import 都要多写一层路径，非常烦人。
前端用 Vite 创建 Vue 项目：
npm create vite@latest frontend -- --template vue这会在 frontend 目录下生成一个标准的 Vue 3 项目。记住选 Vue 3 而不是 Vue 2，新项目完全没必要用旧版本。
2.2 依赖安装与版本锁定
依赖版本这个坑我踩过不止一次。Django 和 Django REST Framework 的版本必须兼容，否则会出现一堆莫名其妙的报错。我当前项目用的是：
Django==4.2.7 djangorestframework==3.14.0 django-cors-headers==4.1.0 djangorestframework-simplejwt==5.3.0 mysqlclient==2.2.0前端核心依赖：
{ "dependencies": { "vue": "^3.4.0", "vue-router": "^4.2.0", "pinia": "^2.1.0", "axios": "^1.6.0", "element-plus": "^2.5.0" } }Element Plus 是 Vue 3 下最常用的 UI 组件库，物流管理系统里的表格、表单、弹窗、日期选择器都可以直接用它，省去自己写大量样式的时间。我把 Element Plus 和 Axios 列为前端基础依赖，任何页面开发都离不开这两样。
安装完依赖后，建议立刻在 PyCharm 的终端里跑一次python manage.py migrate，确认数据库连接正常，再跑一次npm run dev，确认前端能启动。这两步如果有一项失败，一定是环境问题，趁早解决，不要拖到功能开发阶段才排查。
3. 数据库建模与用户权限设计
3.1 核心表结构规划
物流管理系统的数据模型，核心对象不外乎这几个：用户、订单、车辆、司机、仓库、运输路线。我把它拆成四张核心业务表加若干张关联表。
订单表的字段设计要特别注意状态字段，它是整个业务流转的线索：
class Order(models.Model): order_no = models.CharField(max_length=32, unique=True, verbose_name="订单编号") sender_name = models.CharField(max_length=64, verbose_name="寄件人") sender_phone = models.CharField(max_length=20, verbose_name="寄件电话") sender_address = models.CharField(max_length=256, verbose_name="寄件地址") receiver_name = models.CharField(max_length=64, verbose_name="收件人") receiver_phone = models.CharField(max_length=20, verbose_name="收件电话") receiver_address = models.CharField(max_length=256, verbose_name="收件地址") status = models.CharField(max_length=20, default="pending", verbose_name="订单状态") assign_vehicle = models.ForeignKey("fleet.Vehicle", null=True, blank=True, on_delete=models.SET_NULL) create_time = models.DateTimeField(auto_now_add=True) update_time = models.DateTimeField(auto_now=True) class Meta: db_table = "biz_order"订单状态我建议做成常量，不要直接在代码里写字符串：
class OrderStatus: PENDING = "pending" # 待分配 ASSIGNED = "assigned" # 已分配车辆 IN_TRANSIT = "in_transit" # 运输中 DELIVERED = "delivered" # 已签收 CANCELLED = "cancelled" # 已取消车辆表则要记录车辆的基本信息、载重、状态和当前位置快照：
class Vehicle(models.Model): plate_no = models.CharField(max_length=20, unique=True, verbose_name="车牌号") driver_name = models.CharField(max_length=64, verbose_name="司机姓名") driver_phone = models.CharField(max_length=20, verbose_name="司机电话") capacity = models.DecimalField(max_digits=8, decimal_places=2, verbose_name="载重(吨)") status = models.CharField(max_length=20, default="idle", verbose_name="车辆状态") current_lng = models.DecimalField(max_digits=9, decimal_places=6, null=True, blank=True) current_lat = models.DecimalField(max_digits=9, decimal_places=6, null=True, blank=True)这里有个设计心得：车辆的当前位置字段我一开始用FloatField，后来发现经纬度精度有问题，改成了DecimalField。如果你对接的是地图服务，经纬度精度会直接影响轨迹回放和距离计算的准确性，这个坑提前避掉。
仓库表和运输路线表要单独拆分。仓库表相对简单，就是仓库名称、地址、管理员和联系方式的集合；运输路线表则要把起点、终点、里程、预计耗时和途经站点存清楚，因为后续计算运费和时效都依赖这张表。
3.2 权限体系与登录认证
物流管理系统涉及多角色用户，权限控制做不好，整个系统形同虚设。我按四类角色设计：系统管理员、仓库操作员、司机、客服。Django 自带的Group和Permission机制可以满足大部分需求，但配合 Django REST Framework 的权限类会更灵活。
我先自定义一个角色枚举：
class UserRole: ADMIN = "admin" WAREHOUSE = "warehouse" DRIVER = "driver" CUSTOMER_SERVICE = "customer_service"然后在用户模型里加一个role字段，并重写has_perm逻辑，让角色判断更直接：
class User(AbstractUser): role = models.CharField(max_length=20, default=UserRole.WAREHOUSE) phone = models.CharField(max_length=20, blank=True)认证方案我推荐用SimpleJWT，因为 Vue 前端用 localStorage 存储 Token，每次请求把 Token 放在 Authorization 头里，后端通过 JWT 校验用户身份，这种模式比 Session 更适合前后端分离架构。配置时记得把ACCESS_TOKEN_LIFETIME设置为 8 小时左右，太短会让司机频繁登录，太长安全隐患大。
权限控制的核心逻辑写在一个通用的权限类里：
from rest_framework.permissions import BasePermission class IsAdminOrWarehouse(BasePermission): def has_permission(self, request, view): if not request.user or not request.user.is_authenticated: return False return request.user.role in [UserRole.ADMIN, UserRole.WAREHOUSE]每个视图或视图集上标注这个权限类，就能做到不同角色访问不同接口。比如司机只能查看和更新自己车辆的订单状态，管理员可以查看全部订单并分配车辆。
4. 后端接口设计与业务逻辑实现
4.1 订单流转接口的实现
订单模块是物流管理系统的中枢，无论是创建订单、分配车辆、更新运输状态，都要走接口。我用 Django REST Framework 的ViewSet统一管理，配合ModelSerializer简化序列化逻辑。
先写序列化器：
class OrderSerializer(serializers.ModelSerializer): status_display = serializers.CharField(source='get_status_display', read_only=True) class Meta: model = Order fields = ['id', 'order_no', 'sender_name', 'sender_phone', 'sender_address', 'receiver_name', 'receiver_phone', 'receiver_address', 'status', 'status_display', 'assign_vehicle', 'create_time']再写视图集：
class OrderViewSet(viewsets.ModelViewSet): queryset = Order.objects.all().order_by('-create_time') serializer_class = OrderSerializer permission_classes = [IsAuthenticated] def get_queryset(self): user = self.request.user if user.role == UserRole.DRIVER: return Order.objects.filter(assign_vehicle__driver_name=user.username) return super().get_queryset() @action(detail=True, methods=['post']) def assign(self, request, pk=None): order = self.get_object() vehicle_id = request.data.get('vehicle_id') try: vehicle = Vehicle.objects.get(id=vehicle_id) except Vehicle.DoesNotExist: return Response({'error': '车辆不存在'}, status=400) order.assign_vehicle = vehicle order.status = OrderStatus.ASSIGNED order.save() return Response(OrderSerializer(order).data)这里最需要留意的是get_queryset的重写逻辑。司机登录后，不应该看到所有订单，我通过request.user去关联车辆表，筛选出分配给自己车辆的订单，这就实现了最基本的业务隔离。
分配车辆这个动作，除了更新订单表，还要同时更新车辆状态，这就涉及事务处理：
from django.db import transaction @transaction.atomic def assign_order_to_vehicle(order_id, vehicle_id): order = Order.objects.select_for_update().get(id=order_id) vehicle = Vehicle.objects.select_for_update().get(id=vehicle_id) if vehicle.status != 'idle': raise ValueError('当前车辆不可用') order.assign_vehicle = vehicle order.status = OrderStatus.ASSIGNED order.save() vehicle.status = 'busy' vehicle.save()select_for_update在这里很重要，如果没有它，在高并发场景下可能出现两笔订单同时分配到同一辆车的情况。用行级锁把订单和车辆锁住，再执行更新，能有效避免脏数据。
4.2 车辆调度与路线匹配逻辑
车辆调度是整个系统里业务逻辑最复杂的一块。表面上看是给订单分配车辆，实际要考虑车辆载重、当前位置、目的地、司机当天工作时长等多个约束条件。我第一版只做了简单的“空闲车辆随机分配”，上线后被客户吐槽调度效率太低，后来迭代成了带约束的分配算法。
基本思路是两步走：
第一步，筛选可用车辆。条件是车辆状态为空闲、载重不小于订单预估重量。
def get_available_vehicles(order): return Vehicle.objects.filter( status='idle', capacity__gte=order.estimated_weight )第二步，在可用车辆里选最优解。简单项目不一定要上复杂的路径规划算法，用贪心策略算每个候选车辆到发货点的直线距离，选最近的：
import math def calculate_distance(lng1, lat1, lng2, lat2): # 简化球面距离计算，适合业务初版 return math.sqrt((lng1 - lng2) ** 2 + (lat1 - lat2) ** 2) def recommend_vehicle(order, vehicles): def distance(v, order): if not v.current_lng or not v.current_lat: return float('inf') return calculate_distance( float(v.current_lng), float(v.current_lat), float(order.sender_lng), float(order.sender_lat) ) return min(vehicles, key=lambda v: distance(v, order))这里我故意用的是简化后的距离公式，因为真实系统中应该去调地图服务的距离计算接口。但有个经验可以分享：初版系统先用简单方案跑通流程，确认整体链路没问题，再逐步嵌入地图 API 替换距离计算，这样迭代风险最小。
路线匹配方面，我做了一个线路表，保存不同区域间的标准运输路线和耗时。系统根据订单的发件地和收件地，先去线路表匹配，匹配不到就标记为“待人工确认”，由客服在后台手动调整。这个设计避免了完全依赖地图 API 的高成本，也不至于让初版系统裸奔。
5. Vue 前端页面结构与接口联调
5.1 页面路由和组件拆分
前端页面我按业务角色来组织，不做大而全的单页，而是按功能拆成若干独立视图。路由设计如下：
const routes = [ { path: '/login', component: Login }, { path: '/', component: Layout, children: [ { path: '/orders', component: OrderList, meta: { roles: ['admin', 'warehouse', 'customer_service'] } }, { path: '/orders/create', component: OrderCreate, meta: { roles: ['admin', 'warehouse'] } }, { path: '/vehicles', component: VehicleList, meta: { roles: ['admin', 'warehouse'] } }, { path: '/routes', component: RouteList, meta: { roles: ['admin'] } }, { path: '/reports', component: ReportView, meta: { roles: ['admin'] } } ] } ]路由重定向和拦截要写在一个统一的入口处。我的做法是在全局前置守卫里做两件事：检查用户是否已登录，检查当前用户角色是否有权限进入目标页面。这样前端就能在页面渲染前做一层拦截，避免直接通过修改路由地址访问到无权限页面。
组件拆分的原则是：每个页面一个视图组件，每个可复用的模块一个子组件。比如订单列表页里，搜索表单是独立组件，表格是独立组件，状态标签是独立组件，分页器也是独立组件。这样维护的时候，改搜索条件不会影响表格，改表格列不会影响分页，各改各的，互不干扰。
物流管理系统里最常用的交互是表格，Element Plus 的el-table组件基本能满足需求。但要注意，当数据量大时，直接用后端返回的列表数据渲染会卡顿，需要配合后端的page和page_size参数做分页加载。前端只要维护当前页的page和page_size状态，请求时带上这两个参数，就能把渲染压力降到最低。
5.2 请求封装与状态管理
前端所有接口请求，我都封装在一个统一定义的模块里。这样做最大的好处是，如果后端接口地址变了，只需要改一个文件，不用满项目找axios.get。
import axios from 'axios' import { ElMessage } from 'element-plus' import router from '../router' const service = axios.create({ baseURL: import.meta.env.VITE_API_BASE_URL || 'http://localhost:8000/api', timeout: 15000 }) service.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers.Authorization = `Bearer ${token}` } return config }) service.interceptors.response.use( response => response.data, error => { if (error.response && error.response.status === 401) { localStorage.removeItem('token') router.push('/login') } ElMessage.error(error.response?.data?.detail || '请求失败') return Promise.reject(error) } ) export default service拦截器是这里的关键。请求拦截器自动给所有请求加上 Token，避免在每个页面里重复写拿 Token 的逻辑；响应拦截器统一处理 401 跳转和错误提示，让页面代码更干净。
所有接口按模块拆分：
// api/order.js import request from '../utils/request' export function getOrderList(params) { return request.get('/orders/', { params }) } export function createOrder(data) { return request.post('/orders/', data) } export function assignVehicle(orderId, vehicleId) { return request.post(`/orders/${orderId}/assign/`, { vehicle_id: vehicleId }) } export function updateOrderStatus(orderId, status) { return request.patch(`/orders/${orderId}/`, { status }) }状态管理我用 Pinia 存两类东西：当前登录用户的信息，以及车辆列表里下拉选项的缓存数据。不建议把所有数据都塞进 Store，物流管理系统里大量数据是一次性展示的，放页面组件里就行，放进全局 Store 反而会带来状态同步问题。
接口联调阶段，最容易出的问题就是字段名不一致。后端create_time前端写成createTime，这种低级错误会让排查浪费大量时间。我的规避办法是约定好：前后端字段统一走 snake_case，不做驼峰转换。虽然前端代码风格上驼峰更常见，但为了减少对齐成本，索性在后端序列化器里不配置source，前端也老实按 snake_case 取数据，实测下来能省很多口舌。
6. 开发过程中的常见报错与排查实录
6.1 跨域请求被拦截
前后端分离开发时，跨域问题基本都会遇到。前端跑在localhost:5173，后端跑在localhost:8000，浏览器会拦截不同端口的请求，报CORS错误。
我的解决方案是用django-cors-headers：
pip install django-cors-headers然后在settings.py里配置：
INSTALLED_APPS = [ ... 'corsheaders', ] MIDDLEWARE = [ 'corsheaders.middleware.CorsMiddleware', ... ] CORS_ALLOWED_ORIGINS = [ 'http://localhost:5173', ]注意中间件顺序，CorsMiddleware要放在所有中间件最前面，特别是在CommonMiddleware之前，否则请求会被提前返回，CORS 头加不上。
还有一种常见情况：请求能到后端接口，但响应里没有 CORS 头。这种通常是接口直接抛了 500 错误，被浏览器判定为跨域失败，实际上是后端逻辑出错了。排查的时候先看后端控制台有没有异常日志，别一直盯着前端报错信息。
6.2 数据库迁移文件冲突
用 Django 开发，多人协作时最容易出迁移冲突。A 同事生成了0002_xxx.py迁移文件，B 同事也生成了同名迁移文件，两者合并时直接报错。
解决办法是约定：每次新增字段或修改模型，都先执行makemigrations，但不要马上migrate，而是把迁移文件提交后再执行迁移。如果有冲突，就删掉冲突的迁移文件，只保留主分支的版本，然后让所有本地环境重新建库测试。
另一个常见的坑是换了数据库之后迁移失效。项目初期用 SQLite，后期换成 MySQL，老的迁移文件里如果用了 SQLite 特有的字段类型，迁移会报错。建议从一开始就确定生产数据库。物流管理系统我推荐 MySQL，因为它在并发和数据处理上更可靠，SQLite 只适合本地开发调试。
MySQL 连接配置：
DATABASES = { 'default': { 'ENGINE': 'django.db.backends.mysql', 'NAME': 'logistics_db', 'USER': 'root', 'PASSWORD': 'your_password', 'HOST': '127.0.0.1', 'PORT': '3306', 'OPTIONS': { 'charset': 'utf8mb4', }, } }utf8mb4这个配置别忘了，不然订单地址里出现生僻字或 emoji 字符时，数据库会报编码错误。这个坑是用户真实反馈后我才发现的。
6.3 Vue 打包后访问接口 404
本地开发没问题，部署后就出各种问题，这是前后端分离的经典痛点。一个典型的场景：前端npm run build之后放到 Nginx，刷新某个子路由页面直接 404。原因很简单，Nginx 没有配置前端路由的 fallback。
Nginx 配置要加：
location / { try_files $uri $uri/ /index.html; }这样所有前端路由都回退到index.html，由 Vue Router 接管页面渲染。
接口请求 404 则是baseURL配置问题。本地开发时前端请求http://localhost:8000/api，部署之后前端跑在 Nginx 下，请求应该走同域名的/api路径，再由 Nginx 代理到后端服务：
location /api/ { proxy_pass http://127.0.0.1:8000/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这个配置配好之后，前端变量的VITE_API_BASE_URL设为空字符串，请求直接走相对路径/api/...，就不会出现部署后因为请求地址不对导致接口不通的问题。
7. PyCharm 开发调试技巧与项目心得
7.1 断点联调的正确姿势
前后端分离项目，最难调的是接口数据对不上。我在 PyCharm 里习惯的做法是，前端跑在浏览器里，后端 PyCharm 里开 Django Debug 模式，两端同时操作。
具体来说，先给后端接口打上断点，然后在 PyCharm 右上角选择 Django Server 配置，点击 Debug 启动。前端页面做任何操作，请求到达后端时，PyCharm 就会停在断点处，这时可以查看request.data、request.query_params、self.request.user等关键对象，确认前端传过来的数据是否符合预期。
如果前端报错，但后端断点没触发，说明请求根本没到后端，问题出在前端路由、Token 或跨域；如果断点触发了但返回的数据前端不认，问题出在序列化器字段或类型转换。这种二分法排查很高效，能省下大量时间。
Django REST Framework 的 API 页面也是个好帮手。开发时直接在浏览器访问http://localhost:8000/api/orders/，DRF 会渲染一个可视化接口页面，可以在页面上直接测试接口，不用每次都从前端页面点进来。这个调试功能我在很多项目里都在用，遇到权限或字段问题时，先在 DRF 页面测一遍，能快速定位是不是前端的问题。
7.2 我踩过的一些坑和建议
整个项目做下来，我整理了几条对后来人有用的经验。
第一，订单编号的生成规则一定要提前定好。我用的是“日期 + 随机数”方案：
import random import string from datetime import datetime def generate_order_no(): date_part = datetime.now().strftime('%Y%m%d') random_part = ''.join(random.choices(string.digits, k=6)) return f"LG{date_part}{random_part}"这个方案看起来简单，但已经能覆盖每天十万单以内的业务量，后期如果订单量大了再改成分布式 ID 生成器也不迟。
第二，车辆位置数据更新的频率不要太高。最开始我设计每 5 秒刷新一次位置，结果数据库压力巨大，高峰期直接拖慢整个系统。后来改成前端页面可见时 30 秒拉取一次，后台任务每 5 分钟批量更新一次轨迹记录，性能问题立刻缓解。
第三，权限控制的粒度宁愿细一点，也不要粗心大意给了过多权限。我最初为了开发方便，把一些接口设置成了IsAuthenticated就能访问，结果仓库操作员也能看到全公司的报表数据，幸好是内部测试时期发现的，不然上线就是事故。每个接口都用最小权限原则过一遍，是对自己也是对用户负责。
第四，日志和异常监控一定要尽早接入。我用的是 Django 的logging配置，在settings.py里加了文件日志，记录所有 4xx 和 5xx 请求。这样就算用户反馈问题，我能直接翻日志看到具体原因，而不是靠猜。
LOGGING = { 'version': 1, 'disable_existing_loggers': False, 'handlers': { 'file': { 'level': 'WARNING', 'class': 'logging.FileHandler', 'filename': 'logs/backend.log', }, }, 'loggers': { 'django': { 'handlers': ['file'], 'level': 'WARNING', 'propagate': True, }, }, }这套日志配置匆忙间搭起来可能感觉不够“高级”，但实际排查问题时，一个记录完整的日志文件比任何监控大屏都管用。
7.3 从开发到上线还差什么
系统功能开发完成，不代表可以立刻上线，我这里列一下我自己项目里最后几天做的事，给准备交付的朋友一个检查清单：数据库备份策略、服务器环境配置手册、Nginx 反向代理配置、HTTPS 证书、前端打包产物验证、后端接口文档导出、初始管理员账号创建、角色权限预置、测试数据清理、操作日志检查周期确认。
这些事看起来琐碎，但每一项都在真实上线时发挥过作用。比如操作日志检查周期，如果不提前配置，上线后日志文件会越来越大，最后撑爆磁盘，这是我们在一次压测时真实遇到过的情况，提前处理比事后救火要容易得多。
最后说一点个人体会：做一个物流管理系统，技术难点其实不在某个具体框架怎么用，而在于怎么把“订单从创建到签收”这条业务链路梳理清楚，并让每个角色在系统里都能找到自己关心的信息。Django、Vue、PyCharm 都只是工具，真正有价值的是你对业务的理解和对细节的把控。如果你也正在做类似项目，建议花时间把订单状态机好好画一画，把每个状态之间的转换条件列清楚，后面所有开发工作都会顺畅很多。
