简介：《物流配送最优路径规划模拟系统》完整项目开发文档，面向软件工程、计算机等专业课程设计或小型项目实训读者，也适合需要参考需求分析、系统设计与测试文档写作规范的开发者。内容围绕物流配送最短路径与动态规划展开，涵盖需求规格说明、设计规格说明、系统实现说明及测试报告，涉及录入与地图模拟、堵车标注、状态显示等功能模块，并讨论 MFC 界面架构、A* 最短路径、模拟退火与遗传算法在配送路线优化中的应用。资源包共 1 个 doc 文件，约 2.59MB，已整理成一份可直接查阅和借鉴的完整文档。目前已有 1064 人学习，适合用来对照课程设计流程、理解从需求到测试的文档结构，并从中提取算法选型、模块划分、测试用例设计等可复用思路。
1. 20 个客户点的巡回路线，为什么不能用枚举硬算
物流配送最优路径规划模拟系统的需求、设计、实现、测试，被拆成四份文档：需求规格说明书、设计规格说明书、系统实现说明、测试记录。真正把这些文档串成一条线的，是一条硬约束——地图上 1 个仓库加 20 个客户点，巡回路线组合数接近 6×10^16，纯枚举到天亮也出不来结果，只能先用 A* 把两两之间的最短路算成一张矩阵，再用启发式算法在矩阵上求 TSP 近似解。它适合两类人：正在做软件设计与编程实践课程设计、要交齐四件套文档的学生；以及手上有一张网格地图和一堆配送点、想把「标点 → 寻路 → 演示 → 手动验证」整条链路走通的开发者。
2. 需求规格：从七个用例倒推模块划分与可测的性能指标
需求规格说明书这份东西，最容易被写成「功能罗列 + 可行性分析四段式」，写完自己都不想看第二遍。一份真能指导编码的需求文档，判断标准很朴素：把文档交给另一个没参与讨论的人，他能不能照着把界面先搭出来、把按钮先挂上事件、把异常分支先写上return。所以我在整理这份文档时，顺序是反过来走的——先定用例，再定模块，最后才补概述和可行性。
2.1 用例驱动：七个用例怎么翻译成可开发的模块
系统一共抽了七个用例，参与者只有两个：用户和系统数据库。用户侧的七个动作分别是录入配送数据、标注配送点、标注路况、重找路线、暂停配送、手动测试路线、查看历史记录。其中「查看历史记录」需要数据库参与增删改查，其余六个纯前端动作。
这一步的价值在于，用例表和模块表能形成一一映射，中间不留真空地带。比如「标注路况」在用例里只是右击街道、选标注、街道变深蓝三步，但它对应的模块责任其实有三块：图形层要重绘那条Road，逻辑层要把traffic字段置 1，算法层在下次寻路时要把这条边从邻接表里过滤掉。如果需求文档只写「用户可以标注堵车路段」，后面编码时这三块责任极大概率会漏掉一块，最常见的是漏掉算法层的过滤，于是地图上明明标红了，车还是往上开。
| 用例 | 前置条件 | 后置条件 | 落到哪个模块 |
|---|---|---|---|
| 录入配送数据 | 登录主界面 | 返回「已为您找到一条配送路线」，地图同步演示 | 输入区 + 逻辑控制 |
| 标注配送点 | 已右击蓝点选标注 | 蓝点处显示小旗子图样 | 图形绘制 + 实体类状态 |
| 标注路况 | 已右击街道选标注 | 街道变深蓝色 | 图形绘制 +Road.traffic |
| 重找路线 | 已完成初次寻路 | 返回新路线并重新演示 | 算法层二次求解 |
| 暂停配送 | 正在演示过程中 | 返回「暂停配送」，动画停止 | 定时器控制 |
| 手动测试路线 | 已标注点并录入数据 | 路径跟随双击街道移动，状态栏同步 | 图形 + 逻辑 |
| 查看历史记录 | 至少完成过一次配送 | 列表显示记录，编辑框显示路线 | 数据访问层 |
映射做完之后，功能模块的划分就自然而然出来了：录入模块、状态显示模块、选中状态模块、标记图样模块、地图模拟模块、测试模块、核心算法模块、辅助功能模块。每个模块下面再挂具体功能名和详细描述，这就是需求文档里那张「系统功能范围及划分说明」表的来源。我一般会在这张表后面加一列「对应界面控件名」，把IDC_BTN_FIND这类资源 ID 直接写进去，编码阶段省掉一轮来回确认。
2.2 把性能需求写成可测的数字
性能需求是整份文档里最容易被糊弄过去的部分，「响应快」「界面流畅」「准确率高」这种描述等于没写。可行的做法是每条指标都给出输入、输出和判定阈值三要素，让测试阶段能直接拿来当测试用例跑。
| 编号 | 性能名称 | 输入 | 输出/指标 |
|---|---|---|---|
| 1 | 更新处理时间 | 用户单击「寻路」 | 短路径方案 ≤ 30 秒；长路径 ≤ 90 秒 |
| 2 | 响应时间 | 用户单击暂停、测试等按钮 | 界面响应 ≤ 5 秒 |
| 3 | 查询响应时间 | 用户启动历史记录查询 | 地图/列表返回 ≤ 30 秒 |
| 4 | 结果准确性 | 用户输入手算测试数据 | 最优路径准确率 ≥ 90% |
| 5 | 数据点输入最大数 | 用户在地图上选客户位置 | 不超过 20 个 |
| 6 | 数据处理精度 | 系统内部浮点运算 | 输出保留小数点后 1 位 |
| 7 | 连续无故障运行时长 | 系统长时间运行 | ≥ 1 个月 |
第 5 条和第 6 条看着琐碎，实际是全文里最硬的两条约束。客户点数上限 20 直接决定了 TSP 求解的时间预算：21 个点（1 仓 + 20 客）的邻域搜索规模、种群规模、迭代代数都要按这个上限来调参，超过 20 个点不是不能跑，是 30 秒的阈值守不住。精度保留 1 位小数则决定了状态栏里所有比较逻辑的写法——两个里程数相差 0.03 公里时，界面上显示都是同一个值，如果代码里还按全精度比较，就会出现「重找按钮按了十次，界面数字一点没变，但用户以为程序卡死了」的尴尬。
系统里有三个量必须给出明确公式，否则不同人算出来对不上：
- 平均行驶速度 = 额定功率 ÷ 载重质量，再叠加一个由随机算法生成的波动值，最终速度还受当前路段路况约束；
- 配送成本 = 里程数 × 燃油费 + 时间 × 每小时损失费 + 其余费用；
- 预期时长 = Σ(各路段里程 ÷ 各路段速度)。
这三条公式在需求文档里定死之后，界面上「推荐货车配置」和「演算公式」两个菜单项才有东西可展示，测试阶段也才有手算对照的基准。
2.3 异常事件流才是需求文档的含金量
七个用例里，基本事件流写起来都轻松，真正花时间的是异常流。每一条异常流,本质上都是一行防御性代码的来源。
录入配送数据这个用例有五条异常流：需求量未输入或不合法、燃油费未输入或不合法、其余费用未输入或不合法。落到实现上就是三个Edit控件的输入校验，atof之后要判断是否大于 0、是否超出合理区间，而不是让空字符串悄悄变成 0 参与后续计算。
标注路况和标注重找这两个用例的异常流更微妙。「未完成初次寻路就点重找」和「未开始配送就点暂停」，这两条如果不写进文档，编码时很容易只在按钮的OnBnClicked里做一次if (m_route.IsEmpty()) return;就完事，界面上什么提示都没有，用户以为自己点漏了，于是连点十几次。合适的做法是异常流里明确要求给出反馈信息，哪怕只是一行「请先寻路」。
手动测试路线这个用例的异常流还暴露了一个设计问题：「配送点只有仓库点一个」。这种情况在数学上是一条空巡回，代码里如果按正常流程走，会进入求解循环直到超时。所以需求阶段就要把「客户点数 ≥ 1」作为启动寻路的前置校验写进去，而不是留到算法层去兜底。
把这三类异常流写全之后，需求规格说明书就不再是一份交作业用的摆设，它变成了编码阶段的检查清单。我带项目时习惯在文档最后附一张「异常流 → 代码位置」对照表，每条异常流后面手写一个函数名，实现完一个划掉一个，比事后补测试用例省事得多。
3. 总体架构设计：MVC 三层与三个核心类的职责边界
设计规格说明书里最不该省的一张图是类图，但更不该省的是「为什么这么切」。这套系统用的是 MVC 分层，界面上有地图区、输入区、状态区三大块，图层有结点、道路、路线、图样四类绘制对象，算法层有 A* 和退火遗传两套求解器。如果不先把职责边界划清楚，最后一定会变成所有代码堆在视图类的OnPaint和按钮响应函数里，两三千行糊成一坨。
3.1 UI、LogicController、DataBaseHandler：三个类怎么切
三个核心类的切法遵循一条原则：谁拥有数据，谁负责改。UI 类只管画和收消息，LogicController 只管流程和算法调度，DataBaseHandler 只管表和记录集。
// —— 三个核心类的骨架，省略具体成员 —— class CUI : public CDialog { // 只持有绘制需要的东西，不持有算法状态 CPainter m_painter; // 地图、结点、道路、路线的绘制入口 CAssocVars m_assocVars; // 与控件绑定的变量集合（DDX） public: void DrawMap(CDC* pDC); // 重绘整张地图 void DrawRoute(const CRoute& r); // 只负责把路线画出来 // 所有按钮、鼠标、定时器的消息响应都落在这一层 }; class CLogicController { CMap m_map; // 结点表 + 道路表 + 路线表 CAstar m_astar; // 两两最短路求解器 CAnnealGA m_ga; // 退火 + 遗传混合求解器 public: BOOL FindRoute(int planType); // planType: 0 最短路径 / 1 最短时间 BOOL ReFindRoute(BOOL bConverge);// 收敛/非收敛两种重找 BOOL ReRoute(int curNode); // 遇堵车后的子集二次搜索 void Reset(); // 清空标注与路线，回到初始态 }; class CDataBaseHandler { CRecordset* m_pRs; // 记录集 public: BOOL Select(CRoute& r, int id); // 查 BOOL Insert(const CRoute& r); // 增 BOOL Update(const CRoute& r); // 改 BOOL Delete(int id); // 删 void UpdateToCList(CListCtrl& lst);// 结果集刷到列表控件 };这三个类的边界，踩过坑之后我才真正守住。UI 类里绝对不能出现for循环遍历结点算距离，那样一旦换算法，界面代码要跟着改；LogicController 里绝对不能出现GetDlgItem，否则这套逻辑没法脱离对话框单独跑测试；DataBaseHandler 里绝对不能出现「算完再决定要不要存」的业务判断，它只认「存这条记录」这一个指令。
按这个切法，一次完整的寻路流程是这样的：用户在输入区填完参数点「寻路」，UI 收消息后把参数打包传给CLogicController::FindRoute；后者先调m_astar算出两两最短路矩阵，再调m_ga求巡回顺序，得到一条CRoute链表；UI 拿到链表后交给m_painter绘制，同时调CDataBaseHandler::Insert写库。整个链路里，UI 不知道 A* 怎么估价，算法不知道界面长什么样。
3.2 实体类与建表：Node、Road、Route、Astar
实体类一共四个，四个类的字段设计直接对应四张数据库表。
Node是路径结点，编号 1~71，其中 1~49 是道路交叉点，51~71 是可以被标记的仓库/客户点。为什么中间跳过 50？因为早期版本里 50 号被预留给了「浮动车位置」这个后来砍掉的功能，编号没回收——这种历史包袱在文档里写一句，能省掉后来人半小时的困惑。
Road是道路，1~75 条，字段里traffic表示路况（0 流畅 / 1 拥挤），running表示小车当前是否在这条路上。Route是路线链表，next指向下一段。Astar是 A* 求解时的开表结点，带g、price、father三个关键字段。
-- 结点表：1~49 为交叉点，51~71 为可标记的仓库/客户点 CREATE TABLE T_Node ( Id INTEGER PRIMARY KEY, -- 结点编号 X INTEGER NOT NULL, -- 设备坐标 X（像素） Y INTEGER NOT NULL, -- 设备坐标 Y（像素） Choose INTEGER DEFAULT 0, -- 标记类型：0 未标记 1 仓库 2 客户 Been INTEGER DEFAULT 0 -- 是否已配送过 ); -- 道路表：连接两个结点，Traffic 决定 A* 是否跳过这条边 CREATE TABLE T_Road ( Id INTEGER PRIMARY KEY, StartNode INTEGER NOT NULL, EndNode INTEGER NOT NULL, Traffic INTEGER DEFAULT 0, -- 0 流畅 1 拥挤 Length REAL NOT NULL -- 像素长度，乘以比例尺得公里数 ); -- 历史记录表：一次配送存一行，路线明细以文本形式追加 CREATE TABLE T_History ( Id INTEGER PRIMARY KEY, PlanType INTEGER, -- 0 最短路径 1 最短时间 Mileage REAL, -- 总里程 km Cost REAL, -- 配送成本 元 Duration REAL, -- 预期时长 h RouteText TEXT -- 结点序列，如 "51,12,33,7,63" );这里有个细节值得单独说：Length字段存的是像素长度，而不是公里数。原因是设备坐标会随窗口缩放变化，如果直接把公里数写死进表，窗口一变尺寸，结点坐标和道路长度就对不上了。正确做法是表里存像素值，取出来时统一乘比例尺（本项目是 30 像素 = 1 公里）。这个设计在读表的时候多一次乘法，但换来了坐标系与业务数据的解耦，后面做地图缩放时不用改表。
3.3 界面分区与消息响应映射
界面分三块：左边输入区（需求量、燃油费、其余费用、方案选择），右边地图区（结点、道路、图样），底部状态区（总里程、配送成本、预期时长、当前速度、当前路况）。三块区各管各的，互不越界。
消息响应的映射表在设计文档里必须写全，因为 MFC 的消息映射宏一旦漏挂，编译能过，运行时点了没反应，排查起来极其费时。
| 界面元素 | 消息 | 响应函数 | 落在哪一层 |
|---|---|---|---|
| 左键点蓝点 | WM_LBUTTONDOWN | OnLButtonDown | UI → 逻辑层置Choose |
| 右键点街道 | WM_RBUTTONDOWN | OnRButtonDown | UI → 弹出标注菜单 |
| 双击街道 | WM_LBUTTONDBLCLK | OnLButtonDblClk | UI → 手动测试推进 |
| 寻路按钮 | BN_CLICKED | OnBnClickedFind | UI →FindRoute() |
| 重找按钮 | BN_CLICKED | OnBnClickedRefind | UI →ReFindRoute() |
| 暂停/启动 | BN_CLICKED | OnBnClickedPause | UI →SetTimer/KillTimer |
| 动画推进 | WM_TIMER | OnTimer | UI → 逻辑层推进一个路段 |
| 鼠标移动 | WM_MOUSEMOVE | OnMouseMove | UI → 高亮选中态 |
| 历史记录菜单 | COMMAND | OnMenuHistory | UI →DataBaseHandler::Select |
这张表里有一行最容易被忽略：WM_MOUSEMOVE。鼠标移到蓝点上变浅蓝、移到路段上变深蓝，这个「选中状态」功能看似只是改个颜色，实际需要每次移动都做一次命中测试——判断鼠标坐标落在哪个结点的包围盒里，或者落在哪条道路的线段附近。如果命中测试写得糙，用矩形包围盒去套斜线段，就会出现「鼠标离路还挺远，路就亮了」的玄学现象。合理的做法是对线段做点到线段距离计算，阈值取 5 像素左右。
4. 核心算法落地：A* 求两两最短路，退火 + 遗传解巡回
算法这一层是整个项目里唯一不能含糊的部分。需求写得再好、界面做得再顺，如果 20 个客户点的巡回路线要算五分钟，这套系统在答辩现场就演示不下去。所以算法设计的思路是分成两级：底层用 A* 把「任意两点间最短路」这层彻底解决掉，上层用启发式算法在已经算好的距离矩阵上求 TSP 近似解，两级之间靠一张 21×21 的矩阵衔接。
4.1 地图建模：71 个结点、75 条道路与设备坐标
地图用的是 Window 设备坐标系，原点在左上角，X 向右、Y 向下。结点坐标直接从原图标注，道路以「起结点 - 终结点」的二元组存储，长度按两点像素直线距离计算。
为什么不用经纬度或者真实路网坐标？因为这个项目的目标是模拟演示，不是接入真实地图服务。设备坐标的好处是绘图直接可用——CDC::MoveTo、LineTo拿到坐标就能画，不需要任何投影转换；代价是坐标系与物理世界只有比例尺这一个联系，所有业务数值（公里数、时长、成本）都要在读数时乘系数换算。这个取舍在设计文档里要写明，否则后面加地图缩放功能时，会有人试图去改结点坐标本身。
邻接关系存在Node.aroundid[]里，每个结点存相邻结点编号数组和对应道路编号数组。这里有个容易忽略的坑：一条道路是双向的，建邻接表时要在两个端点的aroundid里各加一次，否则 A* 只能单向通行，车开出去回不来。
4.2 A* 的估价函数与两两最短路矩阵
A* 的核心是f = g + h，g是起点到当前点的实际代价，h是当前点到终点的估计代价。这套系统里g用累计的像素距离，h用曼哈顿距离。
// MapLogic.cpp —— A* 求单点到单点的最短里程路线 // start / goal 为结点编号，m_node 是结点表 int CAstar::Search(int start, int goal) { ClearTables(); // 清空开表、闭表、父指针 m_open.Add(start, 0.0, Heuristic(start, goal)); while (!m_open.IsEmpty()) { AstarNode cur = m_open.PopMinF(); // 取 f 最小的结点扩展 if (cur.id == goal) { return cur.id; // 到达目标，沿 father 回溯出路径 } m_close[cur.id] = true; // 遍历当前结点的所有相邻结点 for (int i = 0; i < m_node[cur.id].aroundid.GetSize(); ++i) { int next = m_node[cur.id].aroundid[i]; if (m_close[next]) continue; // 已扩展的结点不再入开表 int roadId = m_node[cur.id].roadid[i]; if (m_road[roadId].traffic == 1) // 堵车路段直接跳过，实现绕行 continue; double g = cur.g + m_road[roadId].Length; if (!m_open.Contains(next) || g < m_open.GetG(next)) { m_father[next] = cur.id; // 记录更优前驱 m_open.Update(next, g, Heuristic(next, goal)); } } } return -1; // 开表耗尽仍未到 goal，判定不连通 } // 曼哈顿估价：横纵像素差之和，在横平竖直的格网路网下更贴近真实里程 double CAstar::Heuristic(int a, int b) { return fabs((double)m_node[a].X - m_node[b].X) + fabs((double)m_node[a].Y - m_node[b].Y); }这段代码里有两个参数值得展开讲。第一个是估价函数的选择：曼哈顿距离在横平竖直的网格路网下不会高估真实里程，满足可采纳性，A* 仍然能找到最优解；同时它比欧氏距离更紧，扩展的结点更少。如果换成欧氏距离，估价值偏小，算法会退化成接近 Dijkstra 的广度扩展，20 个客户点两两求解时耗时会有明显差别。第二个是traffic == 1就continue这一行，它是「最短时间方案」绕开堵车路段的全部实现——不需要在算法里加权重，直接把边从图里删掉即可。
两两最短路矩阵的构建方式很直白：21 个可标记点（1 个仓库 + 20 个客户）组成点集 P，对 P 里每一对点调一次Search，结果存进double dist[21][21]。总共 210 次 A* 调用，在 71 个结点 75 条边的小图上，单次求解通常在毫秒级，整张矩阵的构建时间可以忽略。真正的耗时在下一步。
4.3 遗传 + 退火混合：交叉、变异与 Metropolis 接受
TSP 求解用遗传算法打底，编码方式是整数排列——把客户点编号按访问顺序排成一个数组，比如[53, 61, 58, 66, 71, 52]，适应度取总里程的倒数。选择用锦标赛，交叉用顺序交叉（OX），变异用逆序。
纯遗传算法的问题是早熟：种群在几十代之内就会趋同，二十个点规模下很容易陷入局部最优，而且每次运行结果波动很大。引入模拟退火的思路是给变异和交叉产生的新个体加一道 Metropolis 接受准则——劣解不是一律拒绝，而是以exp(-Δ/T)的概率接受，温度 T 随代数递减，前期允许跳出局部最优，后期逐渐收紧。
// AnnealGA.cpp —— 用退火温度控制遗传算法对劣解的接受程度 void CAnnealGA::Evolve() { for (int gen = 0; gen < m_maxGen; ++gen) { // 温度线性下降：初温取首代平均里程差的 10 倍，末期趋近于 0 double T = m_t0 * (1.0 - (double)gen / m_maxGen); for (int i = 0; i + 1 < m_popSize; i += 2) { // 顺序交叉：保留父代一段连续基因，其余按原顺序补齐，天然避免重复点 OrderCrossover(m_pop[i], m_pop[i + 1], childA, childB); // 交叉结果不直接替换父代，交给 Metropolis 准则裁决 double dA = Cost(childA) - Cost(m_pop[i]); double dB = Cost(childB) - Cost(m_pop[i + 1]); if (AcceptByMetropolis(dA, T)) m_pop[i] = childA; if (AcceptByMetropolis(dB, T)) m_pop[i + 1] = childB; } SortByCost(m_pop); // 按总里程升序 PreserveElite(); // 精英保留：最差 10% 用最优个体覆盖 if (IsConverged()) break; // 连续 20 代最优解无改进则提前退出 } } // Metropolis 接受准则：Δ<0 必接受，Δ≥0 按概率接受 bool CAnnealGA::AcceptByMetropolis(double delta, double T) { if (delta < 0.0) return true; // 更优解无条件接受 if (T < 1e-6) return false; // 温度过低，不再接受劣解 return (rand() / (double)RAND_MAX) < exp(-delta / T); }关键参数有三个：种群规模m_popSize取 30~50，代数m_maxGen取 500，初温m_t0取首代平均里程差的 10 倍。初温这个取法是有讲究的——固定一个常数在不同规模的客户点集合上表现差异极大，按首代的实际差值动态定标，才能保证劣解接受概率在首代维持在 0.5 以上。
有了这套混合求解器，「收敛重找」和「非收敛重找」两个按钮才讲得通。收敛重找每次从当前最优解出发继续迭代，接受准则改成只接受严格更优的解，因此结果单调不增，按十次看到的路线只会越来越短；非收敛重找每次重新随机初始化种群，得到的是同规模下的一次独立求解，结果会上下波动，用来观察算法的波动范围。这两个按钮在答辩现场是很好的演示抓手——连续点十次收敛重找，里程数一路往下掉，比任何 PPT 都有说服力。
4.4 动态规划：绕开堵车路段的子集二次搜索
前三节解决的是静态规划，也就是车还没出发、路况已经标好的情况。动态规划的触发点是：车正在行进途中，用户对前方路段标注了堵车，此时系统必须给出绕行方案。
实现上分四步。第一步把当前堵车路段在Road.traffic里置 1；第二步以小车当前位置的路段端点为新起点，对剩余未配送的客户点重新跑 A* 得到子集距离矩阵；第三步用同一套退火遗传算法求子集的巡回顺序；第四步把已走路径和新巡回路径首尾拼接，返回完整结点序列。
// 遇堵车后的二次搜索：只对剩余配送点重算，已走过的路不重算 BOOL CLogicController::ReRoute(int curNode) { CArray<int, int> remain; for (int i = 0; i < m_map.GetNodeCount(); ++i) { int id = m_map.GetNodeId(i); if (m_map[id].Choose == 2 && !m_map[id].Been) // 是客户点且未配送 remain.Add(id); } if (remain.GetSize() == 0) return FALSE; // 全部配送完毕，直接返仓 // 1. 子集两两最短路（A* 内部会跳过 traffic == 1 的边） BuildSubMatrix(curNode, remain); // 2. 对子集求巡回顺序 CArray<int, int> order = m_ga.Solve(remain); // 3. 拼接：已走路径 + 新巡回路径 + 返回仓库 m_route.Append(m_route.GetTailNode(), order); m_route.Append(order[order.GetSize() - 1], m_wareHouseId); return TRUE; }这里最关键的一个设计决定是「只对剩余点重算」。如果每次都从仓库重新跑一遍完整 TSP，虽然逻辑上更简单，但一方面会推翻已经走过的路径（演示时车会瞬移回仓库），另一方面计算量白涨。只算剩余点，既符合实际配送语义，又把子集规模控制在 20 以内。
5. 避坑与排查：五个最容易翻车的点
这一章按「现象 → 原因 → 解决」来写，五条都是我在这个项目里真实遇到过或者看别人遇到过的问题。每一条都对应一个具体的排查动作，照着做基本能定位。
5.1 估价函数直接抄了欧氏距离，寻路超时
现象：20 个客户点全部标注完之后点「寻路」，短路径方案跑了四十多秒还没出结果，界面上按钮一直是灰的，用户以为程序崩了。
原因：Heuristic里用了两点欧氏距离sqrt(dx*dx + dy*dy)。在 45 度斜线稀少、以横平竖直为主的格网路网里，欧氏距离明显小于实际要走的里程，估价值偏松，A* 的扩展范围接近整个图，退化成了 Dijkstra。再加上开表用的是线性遍历找最小值，每扩展一个结点都要扫一遍整个开表，复杂度又叠了一层。
解决：估价函数换成曼哈顿距离，这是格网路网下更紧且仍然可采纳的估计；同时把开表的最小值查找换成手写的二叉堆，PopMinF从 O(n) 降到 O(log n)。这两处改完之后，同样的 20 个点场景耗时降到了秒级。
5.2 比例尺漏乘，状态栏里程数大了 30 倍
现象：手算一条四段路的配送路线，大约 6.4 公里，系统状态栏显示 192.0 公里，配送成本跟着翻了几十倍，看起来像算法算错了。
原因：Road.Length存的是像素长度，业务层直接把像素长度累加后当成公里数显示，漏了「30 像素 = 1 公里」的比例尺换算。这个 bug 隐蔽的地方在于界面表现是自洽的——里程大、成本大、时长也大，全是同一个倍数偏大，肉眼看不出哪一项异常。
解决：在CRoute里加一个GetMileageKm()方法，内部统一乘1.0 / 30.0，所有界面显示和业务计算都只调这个方法，禁止外部直接读像素累计值。这类单位换算问题，靠代码规范比靠 review 靠谱。
5.3 浮点比较让「收敛重找」永远不收敛
现象：点了十几次收敛重找，路线的形状确实在变，但状态栏里程数一直卡在 6.4 公里不动，偶尔还会跳回一个更大的值。
原因：两处。一是比较用了if (newLen < oldLen)全精度比较，两次求解结果相差 0.001 级别时被判为「没有更优」，于是程序没有更新最优解，界面上却把新路线画了出来，视觉和数值对不上。二是重找时把当前解直接当成初始种群的一个个体塞进去，交叉变异之后精英保留环节又把最优个体覆盖回去了，形成振荡。
解决：比较统一改成按显示精度来，fabs(newLen - oldLen) > 0.05才算有实质变化；重找时把当前最优解单独存一份m_bestRoute，只有新解在显示精度上确实更短才替换，否则保留原解。这条改动之后，收敛重找才真正做到了单调不增。
5.4 定时器里重算路径，小车瞬移加界面卡死
现象：小车正在路上跑，用户标了一条堵车路段，下一秒小车直接跳到了下一个客户点，同时界面卡住两三秒。
原因：OnTimer里为了响应路况变化，每次都调了一次ReRoute，而ReRoute内部要跑 A* 加退火遗传。定时器周期设的是 100 毫秒，等于每 100 毫秒跑一次完整求解，界面线程被算法占满，重绘请求全积压。
解决：路况变化时只置一个脏标记m_bDirty = TRUE，不立刻重算；OnTimer里判断标记，只在小车到达下一个结点时才触发一次ReRoute，也就是让重算发生在路段切换的边界上，而不是每个定时周期。另外在重算期间调用KillTimer暂停动画，算完再SetTimer恢复，视觉上就是车停下来想了一下然后转向，比瞬移自然得多。
5.5 数据库改了但记录集没重查，历史记录对不上
现象：完成一次配送后打开历史记录，列表里能看到新记录，但右侧编辑框显示的路线信息是上一条的；再点几次删除，列表刷新了，编辑框里的内容还留着。
原因：CRecordset派生类在Delete之后没有调Requery，游标还停在原位置；UpdateToCList只清了CListCtrl重新填充，没有同步清空编辑框。MFC 里这类「记录集状态与控件状态不同步」的问题很常见，因为两套状态各自独立维护，谁也不知道对方改了。
解决：把「刷新界面」收敛成一个方法RefreshHistoryView()，内部先Requery再清列表、清编辑框、重新填充，任何增删改之后只调这一个方法，不允许分支里各自刷一部分。这条经验后来被我带到了所有带数据库的课程设计里，凡是「列表 + 详情」的界面，刷新入口都只留一个。
6. 验收与答辩：用一组手算数据证明这条路线真的最短
验收这一步，最省事的做法是打开系统随便点几下说「能跑」，但答辩现场老师大概率会问一句「你怎么证明它找出来的确实是最短」。这时候手里有没有一组手算对照数据，差别特别大。
我的做法是准备三组规模递减的测试数据。第一组只标 2 个客户点，从仓库出发经过 A 到 B 再回仓，一共只有两条可能的巡回路线，手算两个总里程写在纸上，系统跑出来的必须和较小的那个对得上。第二组标 5 个客户点，巡回路线共 4!÷2 = 12 条，用一张表格把 12 条枚举出来排序，看看系统给的解排第几——如果排第一就是最优，排第二以内也算合格，因为设计要求是准确率 90% 以上。第三组标满 20 个点，这一组没法手算，就用来测收敛重找的单调性和寻路耗时。
| 测试组 | 客户点数 | 巡回组合数 | 验证方式 | 判定标准 |
|---|---|---|---|---|
| 组一 | 2 | 2 | 全枚举手算 | 与最小值完全一致 |
| 组二 | 5 | 12 | 表格枚举排序 | 系统解排前 1~2 位 |
| 组三 | 20 | 约 6×10^16 | 收敛重找十次 | 里程数单调不增，单次 ≤ 30 秒 |
除了路线，还有几项要一起验：手动测试路线这个功能本质上是给用户一把尺子——双击一条街道，小车就沿着那条街走一段，状态栏同步更新里程。如果系统自动算出的路线和用户手动双击走出来的路线不一致，说明自动寻路漏了某条更短的路。答辩时当场演示一次「自动寻路 → 手动双击验证某段更短 → 系统重新收敛到更短解」，这个流程比任何功能列表都直观。
成本公式也要现场核一遍。随便取一条路线，把里程数、燃油费、每小时损失费、其余费用四项写出来，按「里程数 × 燃油费 + 时间 × 每小时损失费 + 其余费用」手算一遍，和状态栏显示值对照，保留一位小数后必须一致。这一步能挡掉大部分单位换算和浮点显示的问题。
从那以后我每次带这类项目，都会在开发中期就强制走一遍「两组小规模手算 + 一组大规模性能」的验收流程，而不是等到答辩前一天才想起来测。因为小规模手算能暴露的算法问题，往往是大规模测试里被随机性掩盖掉的那些——比如估价函数写错、比例尺漏乘、边界点不可达。早点发现，改一行代码就完事；晚点发现，就是通宵。希望帮到你。
本文还有配套的精品资源，点击获取
