DeepSORT多目标跟踪实战：数据关联、卡尔曼滤波与ID跳变调参

干这行时间长了，总会被问到一个问题：为什么视频里那段轨迹线每隔几秒就断一次，颜色还乱跳？前阵子帮一个团队看他们的视频分析模块，前端画面上三个行人交错走过，原本三条不同颜色的轨迹，两秒之内互相换了两轮，最后连人带线全乱了。他们的检测模型指标并不难看，问题全出在“把这一帧的框和上一帧的框对应起来”这一步。后来换掉原来的关联逻辑，用 DeepSORT 重新搭了一遍数据关联，才把这个问题压下去。

DeepSORT 属于多目标跟踪里最经典的一类做法：它不负责“看见人”，只负责“认出这一帧的人是不是上一帧那个人”。它是在早期 SORT 的基础上做了三件事——引入深度外观特征、把运动信息的可信度用马氏距离卡住、再按轨迹年龄做级联匹配。这套组合在遮挡、交叉、短时丢失的场景下，表现比纯运动模型稳得多。这篇内容适合三类人看：正在复现多目标跟踪论文的学生、要把跟踪模块塞进实际视频分析产品的工程师、以及在调参阶段被 ID 跳变折磨过的人。下面我就按自己复现和调参的顺序，把 DeepSORT 从思路到代码、从参数到排错讲一遍，重点讲那些文档里不写、但真正决定效果的东西。

1. 先看清 DeepSORT 到底补的是哪块短板

1.1 SORT 崩盘的那个瞬间

要理解 DeepSORT，得先知道它修的是什么。SORT 的思路极简：卡尔曼滤波负责预测每条轨迹在当前帧应该出现在哪，然后把预测框和当前帧的检测框算一个 IOU 代价矩阵，丢给匈牙利算法做最优分配，匹配上的用检测框更新滤波状态，没匹配上的轨迹继续靠预测往前走。整个流程帧间只依赖位置，不需要任何特征，所以速度飞快，早期实现在普通 CPU 上就能跑到每秒几百帧。

它的假设也很朴素：同一目标在相邻两帧之间位移不大，且检测框基本稳定。在人少、走动平缓、帧率高的画面里，这个假设成立得不错。但一旦碰上真实场景就露馅了。我印象最深的是两个人迎面交叉走过的那几帧——两人的框在画面中央大面积重叠，IOU 代价矩阵上两两之间的数值几乎一样，匈牙利算法给出的解在这一帧是对的，下一帧就偏了。因为一旦错一次，被错认的那条轨迹的外观和运动状态都被污染，误差会累积。

还有一种更常见的情况：目标被柱子或别人挡住三到五帧。SORT 里没有外观信息，只能靠 IOU 去判断“这个重新出现的框，是不是刚才那条轨迹”，而遮挡后目标位置已经变了，IOU 归零，匹配必定失败。结果就是原轨迹因超时被删除，目标重新出现时被当成一条新轨迹，分配一个新 ID。在前端看就是轨迹线断了、颜色换了。这类现象在多目标跟踪评测里对应两个指标：ID switch 数量和轨迹碎片化程度。SORT 的 ID switch 之所以高，根子就在这里——它只有运动信息，没有身份信息。

提示：很多人第一次复现 SORT 时会觉得“效果还行啊”，通常是因为用的测试视频人少、遮挡少。换成商场、车站这类拥挤场景，问题会立刻暴露。

1.2 多一路外观特征，等于给每条轨迹发了张脸

DeepSORT 的核心改动，是在匹配代价里加了一项外观距离。具体做法是给每个检测框裁出图像块，送进一个卷积网络，得到一个固定维度的特征向量（原论文用的是 128 维），并做 L2 归一化。两条轨迹之间的外观距离就用这两个向量的余弦距离衡量，取值范围在 0 到 2 之间，越接近 0 说明越像。

这一项的价值在于，它和位置完全解耦。目标被遮挡后位置漂移再大，只要再出现时的外观特征还能和之前存下来的特征对上，轨迹就能接回去。这就是为什么 DeepSORT 在遮挡场景下的 ID switch 明显少于 SORT。

代价也很直接：每帧每个检测框都要过一次卷积网络。原论文给出的大致量级是，在当时的硬件上从每秒几百帧掉到每秒二三十帧。这个开销在很多实际项目里是可以接受的，因为它可以批量化——把一帧里所有检测框裁出来拼成一个 batch，一次前向就能出全部特征，比逐个处理快好几倍。

除了外观，DeepSORT 还加了另外两处改动，很多人容易忽略。第一是马氏距离门控：不是所有检测都允许和轨迹匹配，只有滤波器的预测分布和检测框之间的马氏距离小于卡方分布的 95% 分位点（4 个自由度时约 9.4877）时才允许。这相当于告诉算法“物理上不可能跑这么远的目标，别硬匹配”。第二是级联匹配：按轨迹上一次被更新的时间长短分层，越近被更新过的轨迹优先级越高，先参与匹配。这个设计是为了解决一个具体问题——如果一条轨迹已经丢失很久了，它的预测位置很不可靠，却和新出现的检测框匹配上了，就会抢走本该属于活跃轨迹的检测。

1.3 卡尔曼滤波在这里预测的到底是什么

DeepSORT 的卡尔曼滤波状态向量是 8 维，不是常见的 4 维。具体是中心点横坐标、中心点纵坐标、宽高比、高度，以及对应的四个变化率。观测向量是前 4 维，也就是检测框转换过来的中心点、宽高比、高度。

为什么不用左上角和右下角四个坐标？因为那样坐标之间存在强耦合：目标走近镜头时框整体变大，四个坐标同时变化，滤波器的噪声建模会变得很难看。而用中心点加宽高比加高度，好处是把“平移”和“尺度变化”分开了。中心点描述平移，高度描述尺度，宽高比在多数场景下近似恒定（人站着和走着的宽高比差异不大），所以它的变化率可以被压得很小，相当于给滤波器减少了一个自由度。

这里的物理假设是匀速模型：目标在相邻帧之间以近似恒定速度运动。对行人这种运动来说，一秒二三十帧的采样下这个假设勉强成立；对急停急转的车辆或者被抛掷的物体就不成立了，误差会明显变大。我在处理快速变向的场景时，会把过程噪声调大一点，让滤波器更相信观测而不是预测，代价是框会跟着检测抖动。

2. 三个模块是怎么咬合成一条跟踪链的

2.1 单帧之内的完整时序

一帧进来之后的顺序是固定的，顺序错了效果就会差。我把它拆成六步：

1. 所有已存在的轨迹先用卡尔曼滤波做一次预测，把状态推进到当前时刻。
2. 当前帧的检测框全部送进特征提取网络，得到归一化后的特征向量。
3. 计算代价矩阵，同时算外观余弦距离和运动马氏距离。
4. 对外观距离超过阈值、或马氏距离超过卡方阈值的配对，直接把代价置为无穷大，等于禁止匹配。
5. 做级联匹配：先让丢失 0 帧的轨迹参与匹配，再让丢失 1 帧的、2 帧的……一直到设定的上限。每一层内部用匈牙利算法求最优分配，匹配成功的从候选里移除，进入下一层。
6. 对剩下的未匹配检测和未确认轨迹（刚出现、还没连续命中够次数的），再用 IOU 做一次兜底匹配。

最后是状态更新：匹配上的轨迹用检测框做卡尔曼更新，未匹配的轨迹只做预测、丢失计数加一，超过最大存活帧数就删除。检测框里没被任何轨迹匹配上的，新建一条未确认轨迹。

这个顺序里有两个容易写错的地方。第一个是预测必须在计算代价之前，我见过有人在更新之后才预测，结果整条链的时间戳错了一帧，效果肉眼可见地差。第二个是门控必须在匈牙利算法之前，如果先做分配再过滤，等于让匈牙利算法在一堆非法配对上做优化，结果一定不对。

2.2 外观特征的存取与代价融合

每条确认轨迹都会维护一个特征库，保存它最近若干次匹配成功时对应的检测特征。原论文设的上限是 100 条，超出后按先进先出淘汰。计算某条轨迹和某个检测的外观距离时，不是只比最后一帧的特征，而是把这个检测的特征和轨迹特征库里的每一条都比一遍，取最小值作为距离。取最小值而不是取平均，是因为只要历史上有那么一帧拍到了清晰正脸，就应该能认出来；取平均反而会被模糊帧拖累。

这里有个实践中的关键点：特征一定要做 L2 归一化。余弦距离的定义依赖向量模长，如果不归一化，模长大的特征在点积里会占主导，距离计算就失去意义。我在第一次自己实现时就漏了这一步，结果外观距离全挤在一个很小的区间里，阈值怎么调都没用。

代价融合的形式是两项加权：

# cost_appearance: 余弦距离，范围 [0, 2] # cost_motion: 马氏距离的平方，已做卡方门控 cost_matrix = lam * cost_appearance + (1 - lam) * cost_motion

关于这个加权系数 lam，不同开源实现的默认值并不一致，很多工程实现把它设得接近 1，也就是以外观为主、运动为辅。我的理解是这样更符合 DeepSORT 的设计意图：运动项的主要职责是门控，也就是把物理上不可能的配对排除掉，而不是参与最终打分。因为一旦让运动项占较大权重，画面里目标密集、预测框互相重叠时，代价矩阵会重新退化成一堆相近的数值，外观这一路就白加了。

2.3 匈牙利算法的适用边界

匈牙利算法求的是二分图上的最小代价完美匹配，它的前提是两边数量相等且所有配对都合法。实际场景里检测数和轨迹数一般不相等，所以实现上要先对代价矩阵补零或补大值，让它变成方阵，求解后再把补出来的部分丢掉。

它还有一个隐含假设：每个检测最多属于一条轨迹，每条轨迹最多对应一个检测。这个假设在绝大多数情况下是对的，因为一个目标在同一时刻只应该出现一次。真正的风险不是这个假设本身，而是代价矩阵里的数值不可靠——如果门控没做好，矩阵里全是相近的小数值，匈牙利算法给出的“最优解”在数学上没错，在物理上却是错的。

另一个容易被忽略的是规模问题。匈牙利算法的时间复杂度是三次方级别，检测和轨迹各几十个的时候完全无感，但如果画面里有上百个目标，单帧的求解耗时会明显上升。真遇到这种场景，通常的做法是先把画面分区，或者用稀疏匹配的思路先过滤掉大量不可能的配对，把矩阵降下来。

3. 把论文公式翻成能跑的代码

3.1 环境和依赖上先踩的坑

复现这类算法，环境问题往往比算法本身更耗时间。我用的组合是 Python 加数值计算库、科学计算库（主要用它的线性分配求解器）、图像处理库和一个深度学习框架。几个具体的坑：

数值计算库的新版本对一些旧写法做了移除，很多几年前的开源实现在导入阶段就会报属性不存在的错误。更稳的做法是锁定一个经过验证的版本区间，别一上来就装最新版。

线性分配求解器的接口在不同版本间改动过，旧代码里用的那个函数名已经被弃用，改成新名字后返回值的顺序也可能变，务必确认拿到的是行索引和列索引两个数组。

深度学习框架的推理模式一定要显式开启，否则在循环里会不断构建计算图，显存会一路涨上去，跑几百帧就崩。这一点在自己写的推理循环里特别容易忘。

3.2 卡尔曼滤波的核心实现

状态转移矩阵是 8×8 的单位阵，再在左上角填上位置到速度的耦合项；观测矩阵是 4×8，只取前四维。下面是我常用的一个精简版本，去掉了原实现里的部分工程细节，但逻辑完整：

import numpy as np class BoxTracker: def __init__(self, bbox): # bbox = [x1, y1, x2, y2] self.kf = self._init_filter(bbox) self.hits = 1 self.time_since_update = 0 self.features = [] @staticmethod def _to_z(bbox): x1, y1, x2, y2 = bbox w, h = x2 - x1, y2 - y1 return np.array([[x1 + w / 2.0], [y1 + h / 2.0], [w / max(h, 1e-6)], [h]]) def _init_filter(self, bbox): x = np.zeros((8, 1)) x[:4] = self._to_z(bbox) F = np.eye(8) for i in range(4): F[i, i + 4] = 1.0 # 位置 += 速度 H = np.zeros((4, 8)) for i in range(4): H[i, i] = 1.0 P = np.eye(8) * 10.0 P[4:, 4:] *= 100.0 # 初始速度方差给大，表示不确定 return {"x": x, "F": F, "H": H, "P": P} def predict(self): kf = self.kf kf["x"] = kf["F"] @ kf["x"] h = max(kf["x"][3, 0], 1e-3) # 噪声用框高缩放：远处的目标像素位移小，噪声也小 std_pos = np.array([2/20, 2/20, 1e-2, 2/160]) * h std_vel = np.array([1/160, 1/160, 1e-5, 1/160]) * h Q = np.diag(np.square(np.r_[std_pos, std_vel])) kf["P"] = kf["F"] @ kf["P"] @ kf["F"].T + Q

预测里最关键的一行是噪声用框高做缩放。为什么？因为画面里近处的目标像素位移大，远处的目标像素位移小，如果用固定噪声，远处目标的滤波器会过于相信预测、反应迟钝。用高度缩放相当于给每个目标一个和它尺度相称的噪声水平，这是原实现里一个很容易被抄漏的细节。

更新阶段则要先把检测框也转成观测向量，再算卡尔曼增益、更新状态和协方差。这里有个数学上的小处理：得出的框高度可能因为噪声变成负数，物理上不成立，所以要把它夹到一个最小值，同时限制宽高比的范围，避免更新后框变形。

3.3 外观特征网络的接入方式

特征提取这块，原论文用的是一套在大规模行人重识别数据上预训练的网络。自己复现的时候不一定要重训，直接用现成的重识别模型做推理就能跑起来，效果也不算差。输入通常是 128×64 的矩形图块，宽高比 2:1，正好符合行人框的形态；如果用来跟踪车辆，输入比例得改成接近 1:1，否则图像被拉伸后特征会失真。

预处理有几件事必须对齐：颜色通道顺序（训练时用什么顺序，推理就必须用什么顺序）、归一化用的均值和标准差、以及是否做了翻转。我见过效果奇差但代码完全跑通的案例，最后查出来是训练时按 BGR 顺序，推理时喂了 RGB，外观特征全部偏了一个色调，余弦距离根本分不开人。

批量化处理是提速的关键：

def extract_features(frame, boxes, model, batch_size=32): feats = [] for i in range(0, len(boxes), batch_size): crops = [crop_and_resize(frame, b, size=(64, 128)) for b in boxes[i:i + batch_size]] batch = preprocess(np.stack(crops)) # 归一化 + 转通道顺序 out = model.infer(batch) # 推理模式，不建图 out = out / np.linalg.norm(out, axis=1, keepdims=True) # L2 归一化 feats.append(out) return np.concatenate(feats, axis=0)

裁图的时候记得把框扩一点点边距，通常上下左右各扩 5% 到 10%。因为检测框往往卡得比较紧，把头部和脚部裁掉一点，特征质量会明显下降。这个细节在原论文里没强调，但在实际使用中影响不小。

3.4 轨迹生命周期的三个开关

DeepSORT 的轨迹有明确的状态机，不是“匹配上就一直活着”这么简单。三个关键参数决定了一个目标从出现到消失的全过程：

未确认轨迹的处理方式不一样：它不参与级联匹配，只参与最后那一轮 IOU 兜底匹配。这样设计的好处是，一个偶发的误检不会被立刻升级成正式轨迹，从而不会污染外观特征库。我在密集场景里把 n_init 从 3 提到 4 之后，误检产生的轨迹数量少了一大截，代价是画面边缘新进入的目标要晚半秒左右才被画出来——这个延迟在很多场景里可以接受，在要求极低延迟的场景里就不能动。

4. 参数不是玄学，每个旋钮都有物理对应

4.1 max_age 应该由帧率和遮挡时长换算出来

这是我最想强调的一点。很多人在调这个参数时是瞎试，试到效果看起来可以就停了。实际上它可以算出来。

max_age 的单位是帧，物理意义是“目标消失后最多多少帧内重新出现，还能被接回原轨迹”。如果你知道现场最常见的遮挡时长大概是 1 秒，视频是 25 帧每秒，那么理论下限就是 25 帧。考虑到预测误差会随时间累积、执跟踪越来越不可靠，可以在此基础上给 20% 到 30% 的余量，取 30 左右是合理的。

反过来，如果你的摄像机只有 10 帧每秒，同样 1 秒的遮挡只需要 10 帧，那么 max_age 设成 30 就意味着允许目标消失 3 秒还保留轨迹——这个值太大了，一旦目标真的离开画面，这条幽灵轨迹会在系统里存留 3 秒，期间还可能抢走别人的检测框。这就是为什么照抄别人代码里的 30 会出问题：帧率不同，同样数值对应的物理时长完全不同。

注意：换了摄像机的帧率、换了场景，max_age 必须重新算一遍。它是全流程里对帧率最敏感的参数。

4.2 外观阈值在“宁可错认”和“宁可重开”之间拉扯

外观门控阈值控制的是“两个特征差到什么程度就判定不是同一个人”。调小，判定严格：不容易把 A 认成 B，但遮挡后重新出现的目标可能因为光照变化、姿态变化导致特征漂移，接不上，轨迹断开。调大，判定宽松：容易接回，但画面里穿相似衣服的人会被混为一谈，出现整条轨迹被吞掉的情况。

经验上的判断方法是看同类距离和异类距离的分布有没有重叠。做法很简单：在验证集上跑一遍，记录所有匹配成功的配对的外观距离（同类），再记录所有实际的错误跨越配对的距离（异类），画两个直方图。如果两者之间有明显的谷底，阈值取在谷底就能两头兼顾；如果两者大量重叠，说明当前的外观特征对你的数据根本区分不开，这时候调阈值是徒劳的，得回去换特征模型。

我遇到过一种情况特别典型：工地场景，所有人穿同款反光背心，戴同款安全帽，外观特征几乎只能靠体型和裤子颜色区分。这类场景下阈值调到 0.2 附近就已经开始频繁错认，最后只能靠提高运动项权重、缩短 max_age 来缓解，本质上是在回避外观不可用这个事实。

4.3 检测质量就是跟踪效果的天花板

这话可能有点绝对，但在我经手的项目里基本成立。跟踪是在检测结果上做关联，检测漏掉的人，跟踪必然断；检测框抖动，卡尔曼的速度估计就会跟着抖；检测把两个人合成一个框，跟踪就必然把两条轨迹合并。

衡量方式很直接：先只看召回率。如果某一帧里的人检测召回只有七成，那这一帧至少会丢失三成目标的位置信息，对应的轨迹要么只做预测往前挪，要么直接超时删除。这种情况下你把 max_age 调多大都接不回来，因为根本没有框可以匹配。

具体做法上，我会先跑纯检测，把每帧的检测数画成曲线，和人工标注的量对比，找出丢得最厉害的那些帧和产生的原因（尺度太小？遮挡？逆光？），把这一环先修好，再去调跟踪参数。顺序反过来做，往往是在一条本来就不稳的链路上反复微调，事倍功半。

5. ID 跳变现场：一条从现象追到根因的排查链

5.1 先把故障分成四类

“效果不好”这个描述没法排查，必须先分清是哪一类问题。我一般把它们分成四种，每种对应的根因和处理手段完全不同：

判定方法很土但有效：逐帧截图看。取一段有问题的视频，用工具逐帧导出，把每帧的框和 ID 标注写上去，人工过一遍，看是哪一帧开始出错的。这一步看起来笨，但比盯着汇总指标猜快得多。

5.2 逐层往下钻的排查顺序

确定故障类型之后，我通常按这个顺序查：

第一步，确认是检测问题还是关联问题。把跟踪结果里所有轨迹的框去掉，只看原始检测框的标注，对着视频看检测本身有没有丢、有没有合并。这一步能砍掉一半的排查范围。

第二步，关掉外观项，只留运动。如果关掉之后 ID 跳变没有明显变差，说明外观项根本没起作用——可能是特征没归一化，可能是阈值设置让所有配对都被拒绝了，也可能是特征提取时输入预处理错了。这一步能揪出“外观模块形同虚设”这类隐性故障，我遇到过好几次。

第三步，打印代价矩阵。在出问题的那几帧里，把代价矩阵的数值输出出来看。正常的矩阵应该呈现出明显的偏好结构，每行有一个明显低于其他列的值；如果整行数值都在一个很窄的区间里，说明这一帧的信息量不足，算法在做“掷硬币”式的选择。

第四步，检查马氏距离门控的拒绝率。统计每帧有多少配对因为马氏距离超限被禁掉。在大面积遮挡或者目标突然加速的场景下，这个比例会飙升，意味着滤波器预测已经失效，此时就算外观能对上，配对也会被门控拦掉。这个统计很少有人做，但它能解释很多“明明外观看起来是对的却没匹配上”的困惑。

第五步，统计每个轨迹的特征库规模。如果某条轨迹的特征库里只有一两帧特征，说明它刚确认不久就断了，问题在检测端；如果特征库很满但依然错配，问题在特征质量或阈值。

5.3 常见的根因和对应处置

跑下来最常撞见的是这几种：

低帧率导致预测漂移。摄像机抽帧到 8 帧每秒，目标在两帧之间走了大半个身位，前文提到的 N_init=1 的普通滤波器预测，和观测差了很远，马氏距离直接被卡死。处置方式是提高处理帧率，或者把过程噪声调大，让滤波器不那么迷信匀速假设。

外观模型跨域失效。用公开数据集训出来的特征模型，套到一个俯拍、逆光、低照度的场景里，特征分布完全偏移。处置方式是拿本场景的数据做一轮微调，哪怕是几千个样本的简单分类任务，也能把特征空间拉回来不少。

框抖动引起速度估计震荡。检测框在相邻帧间忽大忽小，高度变化率被滤波器学成一个大数值，下一帧的预测框就飞出去了。处置方式是对检测框做轻量平滑（比如指数滑动平均），或者把观测噪声调大，降低滤波器对单帧观测的信任。

同类相遇时的特征污染。两个人擦肩，其中一个人被短暂遮挡，此时如果外观门控太松导致错配，错误目标的特征会被写进轨迹的特征库。之后这条轨迹带着被污染的特征，反过来又会影响后续匹配，误差自我强化。处置方式是给特征库加一道质量门槛，距离过大的配对不写库，宁可这次不更新，也别把脏数据存进去。

6. DeepSORT 的边界：哪些场景它注定吃力

6.1 高密度场景下的匹配冲突

级联匹配的设计初衷是让“新鲜”的轨迹优先，这在中等密度场景里很管用。但当画面里同时有几十个目标、且他们互相遮挡时，问题会变成另一种形态：多条轨迹在同一位置附近，外观又因为遮挡只剩半截身子可用，级联的优先级排序就失去了区分意义。

我实测过一个密集出入口的画面，峰值时一帧有三十多个框。这种情况下 DeepSORT 的表现明显不如稀疏场景，ID 跳变集中在人群交汇的那几秒。能做的优化有限，比较有效的是缩短级联的层数上限（别让丢失太久的轨迹还参与优先级排序）、以及把外观特征库的更新条件收紧，只在高置信匹配时更新。

6.2 换目标类别，特征模型必须重来

这是很多人踩过的坑。DeepSORT 论文里的外观模型是在行人数据上训练的，把它直接拿来跟车辆、动物、包裹，效果会打折扣。原因是多方面的：车辆的宽高比和行人完全不同，裁出来的图块比例就不对；行人的纹理特征集中在衣着，车辆集中在车灯、车牌、轮廓，特征模型没见过这些模式。

处置方式有两种。一种是换一个在通用图像上预训练的特征模型，虽然不如专门训练的贴合，但至少不会严重偏斜；另一种是拿本场景数据微调，做法是把跟踪问题转成“同一目标在不同帧的图块属于同一类”的分类任务，用对比学习的思路训一个小的特征网络，数据量要求不高，几千组正负样本就能拉出可用的效果。

6.3 与后续思路的取舍判断

近几年的多目标跟踪研究在 DeepSORT 的框架上又往前走了几步，主要的改进方向有两类。一类是在匹配环节上做文章：不完全丢弃低置信度的检测框，而是把它们留到第二轮，和还没匹配上的轨迹再做一次关联。这个思路对遮挡恢复很有效，因为被遮挡的目标检测置信度会掉，但框往往还在。另一类是在运动模型上做补偿：当摄像机本身在移动时，卡尔曼滤波的匀速假设会失效，需要先从画面里估计出全局运动，把轨迹位置校正之后再匹配。

判断该不该换，我给的标准是这样的：如果你的场景里主要矛盾是遮挡导致的断轨迹，那先试低分框二次关联的思路，改动小、收益直接；如果是摄像机在动（车载、云台、手持），那运动补偿是绕不过去的，只调参数收效甚微；如果是外观本身区分不开（制服、同款），那么换哪个关联算法都帮不上，问题在特征模型上，得回到数据侧解决。

我在实际项目里的体会是，DeepSORT 的稳定性很大程度上不取决于算法本身，而取决于你有没有把它的三个假设对清楚：目标做匀速运动、外观特征在当前场景可分、检测质量足够支撑关联。三个假设都成立时，默认参数就能跑得不错；任何一个不成立，调参就变成了在错误的维度上做无谓的努力。

最后分享一个我常用的验证方法：不要只看汇总指标，把跟踪结果按轨迹 ID 分组，统计每条轨迹的存活帧数和平均特征库大小，按存活帧数升序排列，看最短的那几条。短命轨迹往往就是问题所在，点开看它们对应的画面，通常一眼就能看出是遮挡、误检还是外观混淆。这比从头翻视频高效得多，也是我每次迭代参数后必做的一步。