接到一个需求，要在现有系统里加一个路径规划的小工具，Visual化展示配送路线怎么走最短。一开始想直接套用网上的遗传算法代码，但调参调得脑壳疼，后来换成了模拟退火算法，结合GUI展示，整个项目从构思到跑通Demo大概花了三天。这个项目不是高深的前沿研究，但它是一个特别典型的组合优化实践样本：用模拟退火算法解决TSP（旅行商问题）路径规划，再把求解过程在界面上动态展示出来。适合正在学算法的同学、要做课程设计或小工具开发的开发者，也适合想理解“元启发式算法到底怎么一回事”的入门者。这篇就把我做这个项目的完整思路、代码细节、踩坑记录和调参心得都写出来，能帮你在类似需求里少走弯路。

1. 项目背景与算法选型逻辑

1.1 需求初探：从一个实际的路径问题说起

场景是这样：客户那边有几十个配送点，每天都得决定车辆按什么顺序跑完所有点位再回到出发点，希望总路程最短。这就是典型的TSP，全称旅行商问题。它的约束很简单——每个城市只能访问一次，最后回到起点，目标是最小化总行程。

难点在于组合爆炸。n个城市所有可能的环形路径数量是(n-1)!/2，也就是说10个点大概是18万种排列，15个点就超过4300亿种。想靠穷举在合理时间内找到精确最优解，点在30以上基本不现实。所以这类问题通常不会死磕精确解，而是用启发式或元启发式算法尽快拿到一个足够好的近似解。

当时考察了几类方案：贪心算法最简单，每一步去最近的未访问点，但很容易开局选错后面全盘崩掉；遗传算法适应性很强，但交叉、变异、选择、种群规模一大堆参数，新手调起来很劝退；蚁群算法效果不错，但收敛速度偏慢，画界面时很难直观看到“逐步逼近”的过程。最后选了模拟退火，原因是它结构简单、参数少、可解释性强，而且它天然适合“一路展示给用户看我在慢慢变好”的演示场景。

1.2 为什么是模拟退火：一种在“贪心”和“随机”之间走钢丝的方法

模拟退火的灵感来自冶金学里的退火工艺。金属加热到高温后缓慢冷却，原子在高温时剧烈运动、随机试探各种排列，随着温度降低逐步趋于稳定，最终形成低能量、低缺陷的晶体结构。算法把这个过程搬到了优化问题上。

如果我们直接做“贪心局部搜索”，比如每次都选能让路径变短的调整，问题在于很容易卡进一个局部最优出不来。这就像爬山时只往高处走，最后停在了一个小山坡，而不是整片山脉的最高峰。模拟退火的关键突破在于：允许以一定概率接受“更差”的解。这个概率由当前温度和能量差值共同决定，温度高的时候概率大，相当于系统还在“熔融状态”，什么都敢试；温度逐步下降后概率越小，最后收敛成纯贪心。

这就是Metropolis准则，接受新解的概率是 min(1, exp(-ΔE / T))。其中ΔE是新解能量（路径总长度）减去当前解能量的差值，T是当前温度。如果ΔE小于0，新解更优，无条件接受；如果ΔE大于0，新解更差，也还有机会被接受，只是概率随温度降低而变小。正是这个“容忍差解”的机制，让算法有可能从局部最优里爬出来，去探索别的区域。

算法跑起来就像一个“从乱试到大局渐定”的收敛故事，很适合做成GUI逐帧播放，观众能明显看到路径先剧烈乱跳，随后逐步稳定，最后定格成一条漂亮路线。

1.3 模拟退火的四要素和整体流程

模拟退火解决问题必须定义四件事：状态表示（候选解是什么样子）、能量函数（怎么评判一个解的好坏）、邻域扰动（在当前解附近怎么生成新解）、冷却计划（如何控制温度下降）。对应到TSP上分别是：路径排列、总路程、反转/交换片段、按比例降温。

整体流程是：先随机生成一个初始路径，设定初始温度T0，然后进入外层循环，每一轮里做多次内循环——每次对当前路径做一次随机扰动、算一下新的总路程，按Metropolis准则决定接受还是拒绝，记录历史最优。一轮结束就把温度乘以降温系数α，继续下一轮，直到温度低于停止阈值或者连续很多轮都没有改进为止。

这个流程的代码骨架很简洁，但真正的功夫在细节：扰动怎么设计、温度怎么给初值、每一轮内循环多少次，这些东西直接决定了最终结果质量和收敛速度。我最初就是因为图省事随便写了扰动和温度，结果算法要么早熟，要么跑了半天还在原地打转，后面专门花了一晚上调这几个环节，收获非常大。

2. 核心算法设计：状态、能量与搜索策略

2.1 状态编码与能量函数

TSP的状态编码我直接用0到n-1的整数排列，也就是配送点的访问顺序。比如[0, 3, 1, 2]表示从点0出发，经过3、1、2，最终还要回到0。编码本身没有取巧空间，任何排列都是合法路径，这让后面生成新解的操作变得直观。

能量函数就是路径总长度。因为要计算闭合回路，需要把最后一个点再到第一个点的距离也算上。计算式写出来：distance(0,3) + distance(3,1) + distance(1,2) + distance(2,0)。给定坐标矩阵后，这就是标准的欧氏距离累加。

有一个经常被忽略的小细节：路径是环形的，所以[0,1,2,3]和[1,2,3,0]、[3,2,1,0]其实表示同一条路线。做状态展示时，最好固定起点为0，并且规定方向，这样GUI上不会出现“明明是最优解但画出来方向相反导致看着别扭”的情况。我在第一次做界面时没注意这点，最优路径出现了两个镜像版本，被前辈指出后改了编码方向。

2.2 新解生成策略：那些年我用过的扰动方式

新解生成是模拟退火最重要的“动作”，它决定了算法在解空间里怎么移动。我前后试了三种常见的扰动方式。

第一种是交换两个位置，随机选中路径上的两个城市下标，交换它们的位置。这种扰动非常轻，改变的影响面小，适合后期精细打磨，但在初期收敛太慢，经常要很多次随机扰动才能碰到一个明显更好的解。

第二种是片段反转，也叫2-opt扰动。随机选择路线中的一段连续子序列，把它的顺序反过来。比如路径[0,1,2,3,4]，选中下标1到3，反转后变成[0,3,2,1,4]。这个操作的意义在于它能直接消解路径中的交叉现象。TSP最优解有一个经典性质：最优路径在几何上不会自交。2-opt扰动专门盯着交叉边做“解扣”动作，因此效果极好，是我最终的主力扰动方式。

第三种是整段搬移，把一段连续的路径切下来，插入到另一个随机位置。这种扰动幅度大，适合在高温期快速探索较大范围，但容易把好不容易建立的局部结构打乱，我在中期测试里用了一段时间后放弃了。

最终我的方案是混合扰动：高温阶段以随机反转片段为主、偶尔做一次片段搬移，低温阶段只用2-opt反转，把扰动幅度收窄、精细打磨。这个思路对应了物理退火中“高温充分探索、低温精细收敛”的本质，测试下来比单一扰动效果稳定太多。

这里有一个性能优化技巧：扰动不要每次都重新计算完整路径长度。片段反转只影响了两条连接的边——被反转片段头和尾各自连到外部的两条边，距离增量可以增量式算出来，复杂度从O(n)降到O(1)。n在30以下时差距不明显，但点多了以后，这套优化能让内循环次数翻倍提升，后面的实验结果也验证了这一点。

2.3 冷却计划表：温度、速率与终止条件

冷却计划是模拟退火的“节奏控制”。我的初始设置是：初始温度T0、降温系数α、每个温度下内循环次数L、停止温度T_min。

初始温度T0怎么定：一个比较靠谱的经验法是先用当前初始解做若干次随机扰动，统计这些扰动的距离变化量ΔE，然后反推一个温度，让最差的ΔE也有至少0.8的接受概率。计算公式是 T0 = -max(|ΔE|) / ln(0.8)。这保证了算法初期有充足“乱试”的能量，避免一开始就陷入贪心。

降温系数α：我取0.995，也就是每轮温度乘以0.995。这个值的含义是温度下降比较缓慢，给足算法探索时间。如果设到0.9，温度会断崖式下跌，结果往往很差；设到0.999又太磨叽，算一次要跑很久。0.98到0.999之间是常用区间，建议从0.995起步再根据耗时调整。

内循环次数L：通常取状态规模的10到100倍。n=30时，我选择L=100×n=3000次。这个次数决定了同温度下尝试多少个邻居解，太少会“没把握住机会”，太多又浪费时间。

终止条件：温度低于0.001就停止。以T0=10000、α=0.995计算，需要满足10000×0.995^k<0.001，解出k>log(0.001/10000)/log(0.995)，约等于3447轮温度循环。每轮做3000次内循环，总迭代量超千万次。这在现代机器上依然跑得很快，但GUI里如果逐帧播放，千万级操作会明显卡顿，所以我的做法是GUI播放时降低内循环次数，完整高精度计算放在后台跑，跑完再回填结果。

这组参数不是随手拍脑袋，也不是看标准教程抄的，而是我从结果倒推出来的一套平衡方案：保证路径质量接近暴力搜索最优解的同时，把耗时控制在可接受范围内。

3. 代码实现：从距离矩阵到退火主循环

3.1 数据准备与距离计算

先造测试数据。我使用随机生成城市坐标的方式，坐标取(0,0)到(100,100)的整数点，保证距离计算不出现过多浮点误差。需要固定随机种子，这样每次跑出来的初始解一致，方便前后版本对比和复现。

距离矩阵用一个n×n的二维列表存起来，precompute所有点两两之间的距离。不要在能量函数里临时去算平方开根号，那样每轮迭代都要重复算n×n次，纯属浪费。距离矩阵只算一次，之后所有查表都是O(1)时间。

import math import random def generate_cities(n, seed=42): random.seed(seed) points = [(random.randint(0, 100), random.randint(0, 100)) for _ in range(n)] return points def build_distance_matrix(points): n = len(points) dist = [[0.0] * n for _ in range(n)] for i in range(n): for j in range(i + 1, n): dx = points[i][0] - points[j][0] dy = points[i][1] - points[j][1] d = math.sqrt(dx * dx + dy * dy) dist[i][j] = d dist[j][i] = d return dist

如果真实业务场景给的不是坐标而是路网距离，直接把距离矩阵填进去就行，模拟退火对这个不敏感，只要能量计算一致就可以。

3.2 模拟退火主流程代码

以下是核心的模拟退火求解函数，每一步都做了注释，方便对照理解。这段代码兼顾了质量和可读性，是迭代了多次之后的版本，不是一次性写出来的。

def simulated_annealing(dist, init_path, t0=10000, alpha=0.995, inner_factor=100, t_min=0.001): n = len(dist) current = init_path[:] # 当前解 best = current[:] # 历史最优解 best_len = path_length(best, dist) # 这里用初始解扰动来估算初始温度，避免温度设计全靠拍脑袋 t = estimate_initial_temperature(dist, current) if t0 is None else t0 while t > t_min: for _ in range(int(inner_factor * n)): # 2-opt扰动：随机选一段子序列反转 i = random.randint(0, n - 1) j = random.randint(0, n - 1) if i > j: i, j = j, i if i == j: continue new_path = current[:i] + current[i:j+1][::-1] + current[j+1:] new_len = path_length(new_path, dist) delta = new_len - path_length(current, dist) if delta < 0 or random.random() < math.exp(-delta / t): current = new_path if new_len < best_len: best = new_path[:] best_len = new_len t *= alpha return best, best_len

这里有一个值得注意的性能问题：扰动后重新计算完整路径长度是O(n)，而用增量式计算只需要O(1)。上面的示例为了可读性用了完整计算，但如果要追求性能，需要单独实现增量更新，在高n时有显著收益。我在最终版本里对delta做了增量计算，代码会复杂一些，但效率提升明显。

def path_length(path, dist): return sum(dist[path[i]][path[(i+1) % len(path)]] for i in range(len(path))) def delta_length(path, i, j, dist): n = len(path) # 反转[i:j+1]后，受影响的只有 (i-1,i) 和 (j,j+1) 两条边 before1 = dist[path[i-1]][path[i]] after1 = dist[path[i-1]][path[j]] before2 = dist[path[j]][path[(j+1) % n]] after2 = dist[path[i]][path[(j+1) % n]] return (after1 + after2) - (before1 + before2)

注意这里i和j都是闭区间内的下标，边界情况是i=0时i-1要取n-1，j=n-1时j+1要取0，代码里用取模处理了。这是最容易出bug的地方，我就是在这栽过一次，反转路径时总想着「边界无所谓」，结果算出来距离对不上，等画图时才发现路径被切断了。

3.3 扰动函数与能量更新的边界细节

2-opt扰动生成新路径的方式是current[:i] + current[i:j+1][::-1] + current[j+1:]。这个写法简洁，但复制整个列表也有开销。更好的做法是原地修改：先记录i和j位置的旧值，原地把i到j反转，再恢复反转前需要的边界信息。不过Python列表切片反转本身是C层操作，性能远高于纯Python循环，所以实际使用中直接用切片反而更快，这也是我测试后的体会。

能量增量式更新之所以省时间，核心原因是在内循环的千万次操作中，绝大多数量是路径总长度，全量计算的O(n)开销会被放大到可怕的程度。我做了一个简单benchmark：n=50时，全量计算的模拟退火跑完整流程需要约9秒，增量式只需要约2秒。这个差距在GUI演示里非常致命——用户看着界面卡住不动，体验极差。

还要注意，即使接受概率公式用了math.exp，当delta很大且t很大时，exp(-delta/t)可能下溢成0；当delta为0时exp(0)为1，随机数永远小于1，所以会接受无变化的新解。这不影响正确性，但会导致“白做一次扰动”。一个常见的优化是当delta为0时直接跳过接受逻辑，继续下一次迭代。

3.4 输出与优化结果验证

先把求解结果打印出来，和暴力搜索在小规模数据上对比一下。n=10的城市，暴力搜索可以枚举所有(n-1)!/2=181440种路线，用不到一秒时间确认最优解。我做了三组不同随机种子下的模拟退火求解，最低最优差距都在0.5%以内，运行时间稳定在0.1秒量级。

这份对比是给用户和团队吃定心丸的关键证据。没有这个验证，别人就会怀疑你的算法到底有没有用、结果靠谱不靠谱。所以做这类项目时，务必在交付文档里附上一张“算法质量验证表”，把小规模问题与暴力解对比、大规模问题与已知下界对比的结果都写清楚。

城市数量: 10 暴力搜索最优路径长度: 273.12 模拟退火最优路径长度: 273.12 偏差比例: 0.00% 运行时间: 0.09s 城市数量: 30 模拟退火最优路径长度: 428.56 运行时间: 2.3s

4. GUI展示：让算法过程看得见

4.1 界面布局设计：左图右表下按钮

GUI的核心目标是展示“求解过程”，而不是只给一个最终结果。用户看着路径从一团乱线逐渐整理成有序的环线，才能真正理解模拟退火“先探索后收敛”的特性，也更容易信任结果。

我的界面布局分三块：左侧是一个800×600的画布，用来画城市点和当前路径；右侧上方是参数面板，显示当前温度、当前路径长度、历史最优长度、迭代轮数；右侧下方是按钮区，包括“开始”“暂停”“单步执行”“重置”“重新生成城市”。整体框架非常简单，就是一个Tkinter窗口加一个Canvas和一个Frame侧栏。

技术选型上，我推荐直接用Tkinter，它内置在Python标准库里，不需要额外装第三方GUI框架。电子产品、科研软件那种高级观感先不考虑，先把流程跑通、数据展示准确比什么都重要。如果你要极致的视觉效果，可以考虑PyQt5，但学习成本高不少，这个项目用不到那个程度。

import tkinter as tk from tkinter import ttk class SimAnnealGUI: def __init__(self, root): self.root = root self.root.title("模拟退火路径规划演示") self.canvas = tk.Canvas(root, width=800, height=600, bg="white") self.canvas.pack(side=tk.LEFT, padx=10, pady=10) self.control_frame = ttk.Frame(root) self.control_frame.pack(side=tk.RIGHT, fill=tk.Y, padx=10, pady=10) # ... 后续添加参数标签和按钮 self.city_points = [] # 城市坐标 self.current_path = [] # 当前路径索引 self.best_path = [] # 历史最优路径索引 self.temperature = 0.0 self.iteration = 0

4.2 算法与界面的联动：别用死循环，改用after定时器

一开始我图省事，在“开始”按钮里直接调了simulated_annealing主函数，整个求解在一个while循环里跑，结果界面直接卡死——按钮按下后，窗口经理无法重绘，看起来就像程序死掉了，实际上是在疯狂计算。

这个问题的本质是GUI的事件循环被阻塞了。解决方案有两种：一是把求解放到子线程里跑，然后用队列把每一帧的路径数据传给主线程刷新界面；二是把算法改造成“生成器”，每执行一轮或每接受一次更新就yield一份状态快照，主程序再用after定时器定期拉取快照刷新画布。

我实践下来更推荐第二种方案。生成器方式不涉及线程同步问题，After定时器天然地解决了刷新频率控制，代码也更清晰。具体做法是把模拟退火的主循环改成一个generator，每次yield返回(path, temperature, best_len)三元组，外部GUI每20ms调用一次next(generator)，拿到数据就重绘画布一次，同时更新右侧参数标签。

def anneal_generator(dist, init_path, t0, alpha, inner_factor, t_min): n = len(dist) current = init_path[:] best = current[:] best_len = path_length(best, dist) t = t0 while t > t_min: for _ in range(int(inner_factor * n)): i = random.randint(0, n - 1) j = random.randint(0, n - 1) if i > j: i, j = j, i if i == j: continue new_path = current[:i] + current[i:j+1][::-1] + current[j+1:] delta = delta_length(current, i, j, dist) if delta < 0 or random.random() < math.exp(-delta / t): current = new_path if path_length(current, dist) < best_len: best = current[:] best_len = path_length(current, dist) yield current, t, best_len t *= alpha yield best, 0, best_len

注意这里yield放在内循环里，意味着每次接受新解就刷新一次画面。初期接受频次高，界面会快速跳动，接近收敛时接受频次降低，动画自然变慢，这个节奏其实正好契合了“逐渐稳定”的视觉需求。

4.3 展示信息的选择与视觉优化

画布上画三类元素：城市点、当前路径连线、历史最优路径连线。城市点用小圆圈加编号，让观众能看清访问顺序；当前路径用灰色细线，历史最优用红色粗线，两者叠加对比，一眼就能看出算法是否在往正确的方向走。

右侧参数面板除了显示温度、迭代次数、路径长度外，我还额外加了一个实时更新的折线图，画的是路径长度随迭代次数的走势。不是用matplotlib嵌入，而是直接在Canvas里用create_line画折线，纯手绘。这个折线图的价值在于让观众直观看到距离的“阶梯式下降”——开始会上下剧烈波动（因为接受差解），后面逐渐平滑，这正是模拟退火接受劣质解特征的直接可视化证据。

城市点坐标需要从求解空间映射到画布像素空间。由于生成城市时坐标范围是(0,0)到(100,100)，画布是800×600，缩放倍数是8倍，也就是像素坐标=(x8+margin, y8+margin)。如果城市坐标范围不确定，需要动态计算min和max，再做归一化缩放。我第一次没做归一化，直接硬编码8倍缩放，结果有城市跑出画布边界，排查了半天才意识到是缩放的问题。

4.4 交互功能扩展：参数滑块与多组实验对比

为了让演示效果更丰满，我加了几个交互控件：城市数量输入框、初始温度滑块、降温系数滑块、单步执行按钮。在演示给同事看时，可以先随机生成20个城市，用较高的初始温度跑一遍，再把初始温度调低跑一遍，两条距离曲线一对比，观众马上就明白了“初温高了前期波动大、初温低了收敛快但容易早熟”这个抽象概念。

单步执行按钮的实现方式是：把生成器记住，每点一次按钮就调用一次next(generator)然后刷新画面。这个功能调试算法时极其有用，你可以一帧一帧地看路径是怎么变的，配合右侧参数面板的值变化，很容易定位到算法逻辑或图形渲染的bug。这个功能最开始只是我调试的辅助工具，后来演示时反而成了亮点，因为观众可以自己控制播放节奏，仔细研究某一步发生了什么。

5. 参数调优与实验效果对比

5.1 初温与降温速率的影响实验

我做了三组参数实验来观察初温和降温速率的影响。测试用同一组随机生成的城市，固定n=30，保证唯一变量是目标参数。

第一组：初温T0=10000，α=0.995。这组是标准推荐配置，结果稳定，路径长度428.56，耗时2.3秒，路径几乎没有自交。

第二组：初温T0=100，α=0.995。温度起点太低，算法从一开始就陷入局部搜索，失去了“高容错探索”的阶段，路径长度456.23，比第一组多约6%，能明显看到路径有交叉。

第三组：初温T0=10000，α=0.9。降温速率太快，每个温度下还没来得及充分探索就进入低温阶段，路径长度462.78，且多次运行结果方差很大，不稳定。

这个实验说明一个规律：模拟退火对初温和降温速率极其敏感。初温负责“兜底探索能力”，降温速率负责“探索时间的分配”，两者失衡都直接劣化结果。标准参考值是T0在目标问题初始解温度附近，α在0.95-0.999之间，具体值建议用多组测试快速扫描，不要拍脑袋。

5.2 初始解与搜索多样性的权衡

初始解用随机生成还是贪心生成，这个问题我纠结过一阵子。贪心初始解（从点0开始每次去最近的未访问点）能显著降低初始路径长度，让模拟退火起点更高、前期迭代更快，理论上可以让算法少走弯路。但我的实验发现：就最终解质量而言，随机初始解配合充足的高温探索期，反而更容易找到更优解。原因在于贪心初始解把解空间的范围限制住了，算法可能在一个“局部优质区域”周围绕圈，跳不出去。

实际操作中的建议是：追求当前问题的最优质量，就用随机初始解，多跑几次取最好结果；追求演示效果、希望动画前期不那么混乱，就用贪心初始解。两种方案相差不大，但在对质量要求高的时候优先保证探索充分性。

5.3 多轮重启策略与实际结果对比

单次模拟退火运行存在随机性，即使参数完全一样，不同随机种子下结果也会有差异。应对办法是“多轮重启”：连续跑5-10次，保留历史最优。这就像扔骰子，虽然不是每次都能掷出高分，但只要多试几次，最高分的期望值就会提升。这个策略在算法设计里非常常用，它不需要改动任何代码逻辑，就是一个外层包循环。

我在n=30的情况下跑了10次，最优428.56、最差442.31、平均436.8。最优结果的收敛路径图是一条平滑的大环线，几乎没有交叉；最差结果有几处局部绕路，肉眼能明显看出还有优化空间。所以给用户演示时，我经常跑3轮取最优结果，视觉上更漂亮，真实感更强。

5.4 与暴力搜索的对比校验

模拟退火毕竟是近似算法，必须有一个“信任基础”。我强烈建议项目初期就做小规模暴力对比。n=10时暴力枚举只需要计算181440条路径，普通计算机在一个秒级时间内跑完。把模拟退火结果和暴力结果对比，如果差距超过1%，肯定是算法实现或参数有问题。

我还在n=12时做了一次暴力验证，枚举量是(n-1)!/2约2000万，耗时几秒，模拟退火结果距离暴力最优仅差0.08%，让我对算法实现彻底放了心。这个验证过程虽然简单，但特别重要——它把一个看起来像黑盒的算法变得有据可查，后续调参也有了一个基准参考值。

6. 常见问题与避坑实录

6.1 算法不收敛或结果质量差

症状是跑完以后路径长度远高于预期，或者路径图里能看到明显的交叉。排查顺序我有自己的一套清单：先看初始温度是否过低，接着看降温系数是否太快，再看内循环次数是否太少，最后检查距离增量计算是否写错。这几个因素按影响权重排序，初温和降温速率通常占80%的问题原因。

另一个容易忽略的坑是路径表示方式“固定起点”问题。如果你在扰动过程中没有固定起点，反转操作可能把起点也反转进去，导致最终路径的起始点不停变化。虽然这不影响路径长度，但GUI画图时起点的微小偏移会让动画出现“无故跳动”的视觉假象，看起来很不专业。解决方法是：始终把起点固定在索引0的位置，反转或搬移操作都不允许触碰第0个元素。

6.2 GUI卡顿与重绘延迟

内循环次数太多时，每次yield的频率很高，画布重绘跟不上，界面肉眼可见的卡。我解决这个问题的方法是在yield前加一个简单的采样逻辑：只有当路径长度变化超过一定阈值时才yield，否则继续算。这个阈值最初设为距离变化超过0.1就刷新帧率，后面调试发现阈值太高会漏掉细节，改成按迭代轮数抽样更稳定：每迭代100次就强制yield一次，既不卡顿也保证画面连续。

还有一个体验优化：画布上如果新旧路径都画出来，不删除旧线，图形会越来越花。必须在每次刷新前用canvas.delete("path_line")和canvas.delete("best_line")清掉旧线，再画新线。这是比性能优化更基础的图形正确性问题，不处理的话界面几分钟就糊成一团。

6.3 距离计算的浮点精度与边界bug

用整数坐标生成的TSP实例，理论上的欧氏距离大多是无理数，浮点误差无法完全避免。通常这个误差只有10的负14次方级别，对结果排序没有影响。但如果你把坐标改成带小数的真实经纬度，距离差在很小的时候反而可能因为浮点误差导致比较方向出错。稳妥做法是：在构建距离矩阵时统一用math.hypot(dx, dy)计算，同时在每次比较路径长度时加一个微小容差epsilon=1e-9。

边界bug最典型的出现在增量式距离更新。我花了整整一个晚上定位了问题：j=n-1时，代码里(j+1)%n取到0，这是正确的；但i=0时，代码里path[i-1]取到path[-1]，Python里这是最后一个元素，居然也“正确”地取到了环上最后一个节点。这个巧合导致我第一次没发现bug，直到换了n的奇偶性测试才暴露。写这类型代码时一定要显式处理(i-1+n)%n和(j+1)%n，不要依赖Python负索引，虽然结果一样，但可读性和安全性差太多。

6.4 随机种子与结果复现

调试时每次运行结果不同，最容易让人分不清是算法改了还是随机数变了。我强烈建议在GUI和命令行里都暴露一个“随机种子”参数，默认固定。这样同一份数据、同一组参数、同一个种子，运行结果完全一致，可以放心地调试和对比。

进入正式演示或交付阶段前，记得把随机种子去掉或者设为None，让每次运行都有一点随机性。毕竟真实业务中用户不希望每次看到完全一样的路线，多跑几次取最优才是正路。

6.5 经典边界条件速查表

我整理了这份速查表，是我实现一遍后觉得最重要的边界情况，全部踩过坑或见过别人踩坑。

写在最后的一点体会

这个项目做完后，我对模拟退火的看法从“一个没什么用的随机搜索技巧”变成了“组合优化问题里的万金油基础款”。它比精确算法适用范围广得多，比一般贪心算法抗陷能力好得多，比遗传算法参数少、可控性强得多。做GUI展示的过程也让我把算法的行为特征牢牢记在了脑子里——看着温度一点点降下来、路径一点点理顺，那种直观感受比读一百篇论文都深刻。

你要是在自己的项目里也打算用模拟退火，我有一条最实在的建议：先放弃界面，把核心求解器和暴力验证跑通，确认算法质量没问题，再回头加GUI。GUI只是外壳，算法才是内核，这个顺序千万别搞反。