航拍旋转目标检测有一个很尴尬的现实：水平框（HBB）在密集停车场和港口场景下，已经逼近了它的物理上限。车辆斜向停放、船舶以任意角度靠泊、飞机在停机坪上呈扇形排布，水平框会把大量背景像素吞进候选区域，密集场景下旋转框之间的 IoU 分布高度重叠，NMS 的阈值无论怎么调，都在“漏检”和“误合并”之间反复横跳。YOLO 系列从 v8 开始提供 OBB 分支，但真正把 OBB 从“能训”推到“敢在边缘设备上端到端部署”的，是 2026 年 1 月随ultralytics 8.4.0正式落地的 YOLO26 家族。
这篇文章不堆参数表，而是回答一个问题：YOLO26-OBB 在航拍场景里，相对 YOLO11-OBB 和新兴的 RT-DETR 系 OBB 方案，到底值不值得切？我会覆盖架构设计、DOTA 实测数据、部署方案、生态工具和安全风险五个维度，所有数据标注来源，能复现的地方给命令。
一、航拍 OBB 的老问题：角度回归的“边界悬崖”和 NMS 的延迟抖动
在进入 YOLO26 之前，有必要把航拍 OBB 的两类结构性痛点说清楚，否则后面的架构改进就失去了锚点。
第一类痛点是角度回归的边界不连续。DOTA 数据集包含 188,282 个实例，图像尺寸从 800 到 4000 像素，目标朝向任意、密度极高。旋转框的角度参数具有周期性：一个 89° 的框和一个 −91° 的框在几何上是同一个框，但在回归损失里相差 180°。当预测值在边界附近抖动时，损失会突然爆炸式增大，这
架构)
