蓝鸽货运系统产品系统

1.1 立项原因（旨在解决的产品问题）
本物流货运系统主要解决以下核心问题：
传统物流信息不透明问题

寄件人和收件人无法实时追踪货物位置
物流状态更新滞后，用户体验差
缺乏统一的物流信息平台
商家物流管理效率低下

批量下单流程繁琐，人工操作易出错
订单状态分散，难以统一管理
缺少数据统计分析能力
快递轨迹一致性问题

多快递公司数据标准不统一
轨迹信息推送延迟或丢失
转单后物流信息断层
地址识别与面单处理

手动录入地址效率低且易错
OCR 面单识别集成需求
智能地址解析需求
1.2 业务背景
随着电商和新零售的快速发展，物流配送成为商业闭环中的关键环节。本系统面向以下业务场景：

目标用户群体：

电商平台商家（B 端）
普通消费者（C 端）
物流公司/快递员
平台运营管理人员
业务流程：

用户下单 → 商家接单 → 快递揽件 → 运输中转 → 配送到达 → 客户签收
↓ ↓ ↓ ↓ ↓ ↓
创建订单 打印面单 装车扫描 轨迹追踪 卸车扫描 完成配送

核心价值：

提供一站式物流管理服务
实现物流信息实时追踪
降低商家物流运营成本
提升终端用户体验

核心功能：

批量下单：支持一次性创建多个物流订单，提高商家效率
订单跟踪：实时追踪订单状态变化
智能识别：自动识别快递公司（支持主流快递公司）
转单管理：支持转运场景，记录转单信息（快递公司、单号）
打印管理：批量更新打印状态，支持电子面单打印
2.2.2 物流轨迹实时追踪
轨迹采集方式：

快递 100 订阅推送：通过快递 100 平台订阅物流信息，自动推送到回调接口
定时任务扫描：定时刷新未完结订单的轨迹信息
手动刷新：用户主动刷新轨迹信息
轨迹状态：

created（订单已创建）
picked_up（已揽件）
in_transit（运输中）
transfer_order（已转单）
delivered（已送达）
cancelled（已取消）
特色功能：

轨迹地图可视化：集成快递 100 轨迹地图 API
H5 查询：支持通过手机号快速查询订单
店铺隔离：用户可设置默认店铺，查看对应订单
2.2.3 智能地址识别
功能特性：

文本地址识别：从非结构化文本中提取省市区、详细地址、联系人、电话
OCR 面单识别：识别快递面单图片，自动填充订单信息
中通专用识别：针对中通快递优化地址识别算法
三级联动选择：省市区三级联动选择器
2.2.4 数据统计分析
统计维度：

时间维度：按日、周、月、年统计
店铺维度：各店铺订单量对比
状态维度：各状态订单分布
用户维度：用户下单频次统计
数据展示：

订单总数及趋势图
完成率统计
打印率统计
店铺排名
2.2.5 便捷下单功能
业务场景： 针对高频发货商家，预先创建一批订单编号，实际发货时快速匹配使用。

功能特点：

批量生成预制订单
订单批次管理
快速下单通道
支持 Excel 导入导出

作为项目的核心架构师和全栈开发者，我负责了以下全部工作：
3.1.1 架构设计
系统架构规划：设计前后端分离的微服务架构
技术选型：选择合适的技术栈和框架
数据库设计：设计订单、轨迹、地址等核心表结构
API 接口规范：制定 RESTful API 设计规范
权限控制设计：基于 RBAC 的权限管理体系
3.1.2 系统设计
领域模型设计：物流订单、轨迹、物品等实体关系
业务流程设计：订单状态流转、轨迹推送等业务流程
接口设计：定义各模块接口协议
异常处理机制：统一的异常处理和错误码规范
3.1.3 核心开发
订单管理模块：完整实现订单 CRUD、批量下单、转单等功能
轨迹追踪模块：集成快递 100、实现轨迹订阅与推送
地址识别模块：实现智能地址解析和 OCR 识别
统计报表模块：多维度数据统计与分析
便捷下单模块：预制订单生成与管理
3.1.4 测试工作
单元测试：核心业务逻辑单元测试覆盖
集成测试：模块间接口联调测试
性能测试：压力测试和性能优化
Bug 修复：生产问题定位与修复
3.1.5 上线部署
环境配置：开发、测试、生产环境配置
数据库迁移：SQL 脚本编写与执行
应用部署：服务器部署与配置
监控配置：日志监控和告警设置
3.1.6 运维维护
日常运维：系统运行监控与维护
性能优化：慢查询优化、缓存优化
功能迭代：根据业务需求持续迭代
技术支持：解答用户问题和技术咨询
难点描述：

多快递公司数据标准不统一

不同快递公司返回格式差异大
状态定义不一致（如"已发货"vs"运输中"）
时间格式不统一
轨迹信息推送延迟或丢失

快递 100 推送可能延迟
网络异常导致推送失败
重复推送造成数据冗余
转单后物流信息断层

原运单号与新运单号关联困难
轨迹信息需要合并展示
状态同步不及时