简介：面向自动驾驶视觉入门者与语义分割研究者的完整实战资源，基于 Unet++ 网络实现车道线分割，内含约 3200 张自动驾驶道路场景图像及标注，划分训练/验证集，覆盖不同时段与帧，可直接训练自有数据。代码全部为手写，结构清晰，按 README 摆放数据即可运行；训练环节支持 Adam/SGD/RMSProp 优化器、BCE 损失，并提供恒定、余弦退火、step 三种学习率策略，便于对比实验。整个压缩包内共 2000 个文件，以 1859 张 PNG 标注图与 133 张 JPG 原图为主，另有 5 个 Python 脚本、2 个配置文件及 README，压缩包约 489MB；30 个 epoch 下全局像素准确度 0.995、精确度 0.907、召回率 0.908、Dice 0.91，增大轮次仍有提升空间。资源已训练生成最优与最终权重，附带预处理可视化、Dice/Loss 曲线及训练日志，方便直接评估微调；目前已有 654 人学习，适合毕业设计、课程实验或算法落地前验证。

1. 用 Unet++ 做车道线分割：数据集、完整代码与预训练权重的落地路径

车道线分割在自动驾驶感知里看起来是个标准二分类任务，但真正动手做过的人都有体会：普通 Unet 到了弯道、阴影、雨夜场景，输出 mask 要么断裂，要么把路面接缝一起框进来。这份基于 Unet++ 的车道线分割实战资源，把数据集、完整代码和训练好的权重打包在一起，拿到手不用从零开始标数据，直接训练或者加载权重就能出结果。它适合正在跑自动驾驶数据集落地、想对比 Unet 和 Unet++ 效果差异、或者只想快速产出一个可演示分割结果的工程师。全流程按工程交付标准整理，数据划分、损失函数、checkpoint 保存、推理脚本都在，照着跑就能复现指标，不用再花时间把散落的代码拼起来。

2. 训练前准备：Unet++ 结构回顾、车道线数据集目录与依赖环境

2.1 Unet++ 与车道线分割的匹配点：为什么不是普通 Unet 或 DeepLab

车道线目标有两个明显特征：细长、占比小。一张 512×512 的图里，车道线通常只占不到 5% 的像素，一旦下采样次数太多，浅层的线条细节很容易被直接丢掉。普通 Unet 的跳跃连接只是把 encoder 的特征图原样拼到 decoder，浅层信息虽然保住了，但缺少跨层融合，遇到阴影、裂缝、低对比度路面时，模型很容易把纹理相似但语义完全不同的区域一起分出来。

Unet++ 的核心改动是把简单跳跃连接换成了嵌套的密集卷积块。每一层 decoder 的输入都不只来自上一层上采样结果，还同时接收前面多个层级的特征图，这种设计让网络在多个尺度上反复校准分割边界，对车道线这类细长目标更友好。另一个实用点是深度监督（deep supervision），训练时 Unet++ 会从多个子网络分支同时计算损失，权重由深到浅按 [1, 0.5, 0.25, 0.125] 递减。说白了就是让浅层分支也直接接受监督信号，而不是只靠最后一层反传，训练早期收敛明显更快。

如果你在普通 Unet 和 DeepLab v3+ 之间纠结，我的建议很直接：DeepLab 擅长大物体语义分割，但对车道线这种强边缘、长条状目标，空洞卷积的采样间距容易把细线拉断；Unet 结构简单、好调，但特征复用不够。Unet++ 属于两者之间最稳的选择，模型复杂度可控，训练技巧要求也不高。这份资源里默认用 ResNet34 做 encoder，你也可以在配置里换成 ResNet50，代价是显存涨一截。

2.2 数据集目录结构、标签格式与训练/验证划分

这份资源里的数据集是典型的自动驾驶场景车道线图片，原始图像为 RGB，标签是单通道二值 mask，背景为 0，车道线为 1。工程目录大致是下面这个样子，下载后建议先按这个结构核对一遍，避免后面训练脚本找不到路径。

data/lane/ ├── images/ # 原始图像，jpg/png 均可 ├── masks/ # 与 images 同名的标签图，png 格式 ├── train.txt # 训练集文件名列表，每行一个文件名（不含扩展名） ├── val.txt # 验证集文件名列表 └── test.txt # 测试集文件名列表

拿到数据后第一件事不是直接开训，而是检查train.txt和val.txt的划分是否和 images、masks 目录一致。如果不一致，可以用下面这段脚本重新划分，核心是固定随机种子，保证每次划分结果可复现。

import os import random random.seed(42) root = './data/lane' images = sorted([ f for f in os.listdir(os.path.join(root, 'images')) if f.lower().endswith(('.jpg', '.jpeg', '.png')) ]) random.shuffle(images) split_idx = int(len(images) * 0.85) with open(os.path.join(root, 'train.txt'), 'w') as f: f.write('\n'.join(images[:split_idx])) with open(os.path.join(root, 'val.txt'), 'w') as f: f.write('\n'.join(images[split_idx:]))

这段脚本的逻辑很简单：先列出 images 目录下所有图片文件名，打乱顺序后按 85%/15% 切分成训练集和验证集。训练比例可以按数据量调整，数据量少于 500 张时建议把比例拉到 0.9，否则验证集会因为样本太少而出现指标抖动。注意脚本只写入了文件名，没有写入目录前缀，训练脚本里读取train.txt时一般会拼上images/和masks/前缀，所以你不需要在 txt 里写完整路径。

2.3 环境依赖：PyTorch、CUDA 版本与一键安装

车道线分割训练最好有一块 8GB 显存以上的 GPU，我建议的配置是 Python 3.8、PyTorch 1.13 或 2.0、CUDA 11.8。这套组合在大多数工作机上不会遇到兼容性问题。如果 CUDA 版本不同，安装命令也要对应调整。

pip install torch==1.13.1 torchvision==0.14.1 --index-url https://download.pytorch.org/whl/cu118 pip install -r requirements.txt

requirements.txt里一般包含 opencv-python、numpy、albumentations、tqdm、tensorboard 这几个常用库。albumentations 负责数据增强，建议保留，不要为了省安装时间把它注释掉，后面训练阶段会用随机翻转、亮度抖动、轻微旋转来提升模型对光照变化的鲁棒性。如果机器上没有 GPU，CPU 也能跑推理，但训练 120 个 epoch 会非常煎熬，不建议尝试。

装完环境后顺手跑一句python -c "import torch; print(torch.cuda.is_available())"，输出 True 再继续。很多训练翻车其实不是模型问题，而是 PyTorch 装了 CPU 版，模型一直跑在 CPU 上，训练速度慢到你以为代码死循环了。

3. 完整训练：超参数、损失函数与训练日志解读

3.1 训练入口与核心参数配置

这份资源的主训练脚本是train.py，所有关键参数都可以通过命令行覆盖。第一次复现建议直接用下面这条命令，不要一上来就改网络结构。

python train.py \ --arch unet_plus_plus \ --data ./data/lane \ --input-size 512 \ --epochs 120 \ --lr 1e-4 \ --batch-size 8 \ --device 0

--arch指定网络结构，这里必须传unet_plus_plus。--input-size是训练时的输入分辨率，512 是速度和精度的平衡点；如果你跑 1080Ti 或显存只有 11GB，降到 384 可以显著降低显存占用，精度损失大约在 1 到 2 个 IoU 点。--lr初始学习率用 1e-4 起步，不要在刚开训时用 1e-2，Unet 系列对学习率很敏感，调大之后 loss 大概率直接放飞。--batch-size在 8GB 显存卡上建议设 4，16GB 可以设 8，具体数值根据 OOM 报错调整。

训练脚本的数据加载部分一般会做三件事：读取train.txt里的文件名列表、从 images/masks 目录读图、再做随机裁剪和归一化。归一化的 mean/std 通常使用 ImageNet 统计值 [0.485, 0.456, 0.406] 和 [0.229, 0.224, 0.225]。这里最常见的问题是图像读到网络前没有除以 255，导致输入范围在 0 到 255 而不是 0 到 1，loss 会在一开始就异常偏大。

3.2 损失函数：BCE + Dice Loss 的组合与深度监督权重

车道线分割的样本极度不均衡，背景像素远多于车道线像素，单独用 BCE 会让模型倾向于把一切预测为背景，因为这样 loss 仍然很低。实践中更稳的组合是 BCE 加 Dice Loss，Dice Loss 直接优化目标区域的重叠度，对类别不均衡天然不敏感。

import torch import torch.nn.functional as F def dice_loss(pred, target, smooth=1e-6): pred = pred.contiguous().view(pred.size(0), -1) target = target.contiguous().view(target.size(0), -1) intersection = (pred * target).sum(dim=1) dice = (2.0 * intersection + smooth) / ( pred.sum(dim=1) + target.sum(dim=1) + smooth ) return 1.0 - dice.mean() def bce_dice_loss(pred, target): bce = F.binary_cross_entropy_with_logits(pred, target) dice = dice_loss(torch.sigmoid(pred), target) return bce + dice

dice_loss里smooth=1e-6是为了防止分母为 0，这个值不能省，也不能改成整数 1，否则在训练初期预测概率接近 0 时，损失会被异常拉高。bce_dice_loss中 BCE 输入的是 logits，所以前面没有接 sigmoid，而 Dice 计算时传入的是torch.sigmoid(pred)，两者处理的分布不同，这是很多人在复现时会忽略的细节。

由于 Unet++ 有深度监督分支，每个分支都会输出一个预测图。常规做法是每个分支都过一遍bce_dice_loss，然后乘上对应的权重再求和。权重默认 [1, 0.5, 0.25, 0.125]，意思是越靠近原始输入分辨率的浅层分支权重越低，越靠近最终输出的深层分支权重越高。

3.3 训练日志、可视化与 checkpoint 保存策略

训练开始后，控制台会持续打印当前 epoch、loss、IoU、lr 等信息。正常的收敛规律大致是：前 5 个 epoch loss 从 0.8 左右快速降到 0.3 以内，后续 20 到 40 个 epoch 缓慢下降，IoU 逐步从 0.4 爬到 0.8 以上。如果 10 个 epoch 后 IoU 还不到 0.2，不要急着继续跑，先回去检查数据加载和标签是否对齐。

python train.py \ --arch unet_plus_plus \ --data ./data/lane \ --resume ./checkpoints/last.pth

训练中断是常态，主流训练脚本都会在每轮结束保存两个文件：last.pth和best_iou.pth。last.pth用于断点续训，恢复时保持优化器状态、当前 epoch 和 learning rate；best_iou.pth只在验证集 IoU 创新高时覆盖保存。续训命令如上，注意--resume和从头训练的区别：从头训练会重新初始化优化器，续训则把优化器状态也加载回来，学习率调度器也会从上次位置继续，否则中断恢复后学习率回到初始值，模型效果会明显退步。

日志建议用 tensorboard 或者直接保存到 csv 文件，不要只用 print 输出。等到训练结束再翻终端滚动记录，你会后悔没有留结构化日志。工程里常见的落盘格式是每行一个 json，包含 epoch、train_loss、val_iou、lr 四个字段，后面画曲线和调参都方便。

4. 避坑指南：Unet++ 车道线分割训练与推理的 5 个实战问题

4.1 训练第一个 epoch 就出现 Loss 为 NaN

现象：loss 在几轮迭代内从正常值直接变成 NaN，且之后无法恢复，控制台开始爆出大量 RuntimeError。

原因：最常见的是学习率过大导致梯度爆炸，其次是标签图是 0 到 255 的灰度图，但代码里没有除以 255，BCE 在 logits 和 target 范围不一致时计算出的梯度会非常不稳定。另一个少见但同样致命的原因是数据里存在坏图，有某张 mask 是全黑，Dice 分母处理不当直接溢出。

解决：先把学习率降到 1e-4，如果还 NaN，就在数据加载处加上mask = mask / 255.0。检查 train.txt 里是否有文件名和实际目录对不上，一旦数据加载器读到空白图，模型学到的全是噪声。最后确认dice_loss里有smooth，并且pred和target都做了contiguous().view()，避免维度不对导致的隐性问题。

4.2 显存不足，batch-size=8 直接 OOM

现象：训练脚本启动后不久，CUDA 报out of memory，有时在第一个 epoch 结束前就崩掉。

原因：Unet++ 相比普通 Unet 多了大量密集卷积块和深度监督分支，前向传播会同时保存多个中间特征图，显存占用比想象中高。输入尺寸 512、batch-size 8、ResNet34 encoder 的组合在 8GB 显卡上基本没戏。

解决：先降到 batch-size 4 或者 2，确认能跑通再逐步往上加。其次是配合 PyTorch 的 AMP 混合精度训练，显存能省下将近一半。再不行就把输入尺寸从 512 降到 384。我也见过有人直接在训练脚本里加torch.cuda.empty_cache()，其实这只是把显存碎片清理一下，解决不了根本的占用问题，不要指望它在训练循环里力挽狂澜。

4.3 预测 mask 错位，车道线整体偏移或断裂

现象：训练指标不差，val IoU 有 0.75 以上，但可视化的预测图层叠到原图上后，车道线和真实位置对不齐，有些路段断成几截。

原因：这是训练和推理阶段预处理不一致造成的。训练时用了随机裁剪、随机旋转，推理时没有对齐中心裁剪和缩放参数；另一个高发原因是数据增强里随机旋转角度设置过大，比如 ±30 度，车道线是有明确方向性的目标，旋转太狠会让模型学到错误的几何关系。

解决：把 albumentations 里的旋转角度控制在 ±5 度以内，不要用通用分割里常用的 ±30 度。推理管线必须和训练管线保持一致，训练时如果 resize 到 512×512，推理时也要先做同样的 resize，之后再对 mask 做反向 resize 回到原图尺寸。很多复现项目只看指标不看图，等真正可视化时才发现这一点。

4.4 加载训练好的权重时报 missing keys 或 unexpected keys

现象：model.load_state_dict(torch.load('best_iou.pth'))直接报错，提示缺少deep_supervision相关的键，或者多出不该有的键。

原因：Unet++ 在训练阶段会保留深度监督分支，推理时如果代码把deep_supervision设置为 False，模型结构里就不存在那些分支，state_dict 自然对不上。另一个原因是保存权重时直接存了整个 model 而没有存 state_dict。

解决：加载权重时先打印state_dict的 key，确认模型结构开关是否一致。推理脚本里建议固定使用deep_supervision=False构建模型，再用torch.load并去掉以deep_supervision开头的键，或者直接用load_state_dict(weights, strict=False)。这样虽然不会报错，但一定要自己确认缺失的键确实是深度监督分支，而不是主分支被悄悄改名了。

4.5 可视化结果颜色混乱，BGR 和 RGB 通道对调

现象：分割结果形状正确，但叠加到原图后整体色调发蓝发红，像是颜色被反转了。

原因：OpenCV 读取图片默认是 BGR 通道顺序，训练时如果用的是 PIL 或 matplotlib 读取就是 RGB，一旦两个流程混用，模型看到的输入分布和训练分布不一致，预测结果自然不对。

解决：统一在数据加载入口做一次cv2.cvtColor(img, cv2.COLOR_BGR2RGB)。推理可视化时，再转换回来叠加。最简单的方式是推理脚本全部用 OpenCV 读图，转成 RGB 后进模型，输出的 mask 是单通道二值图，叠加时直接用 OpenCV 的addWeighted，不要再用 matplotlib 中转，能少踩一次颜色坑。

5. 推理验证与交付：加载训练好的权重，可视化并校准端到端时延

训练和避坑都过了之后，最后一步是把模型从 Jupyter 实验环境挪到真实推理链路里。我用的是这个工程自带的predict.py，加载best_iou.pth，对单张图片做前向推理并统计端到端耗时。这里的端到端指的是从图片读入内存、预处理、模型推理到输出 mask 的完整时间，不包含后处理拟合车道线方程的部分。

import cv2 import torch import time model = build_unet_plusplus(num_classes=1).cuda().eval() model.load_state_dict(torch.load('weights/best_iou.pth')) img = cv2.imread('samples/road.jpg') x = cv2.cvtColor(img, cv2.COLOR_BGR2RGB) x = torch.from_numpy(x).permute(2, 0, 1).unsqueeze(0).float().cuda() / 255.0 t0 = time.time() with torch.no_grad(): out = model(x) logits = out[0] if isinstance(out, list) else out mask = torch.sigmoid(logits).squeeze().cpu().numpy() > 0.5 latency = (time.time() - t0) * 1000 overlay = img.copy() overlay[mask > 0] = (0, 0, 255) cv2.imwrite('result.jpg', overlay) print(f'end-to-end latency: {latency:.2f} ms')

这段代码的关键在out[0] if isinstance(out, list) else out，因为 Unet++ 在推理时模型的deep_supervision开关一旦关闭，输出就不再是列表，直接取主分支 logits。mask > 0.5是二值化阈值，0.5 对大多数场景够用，如果预测结果偏保守、车道线断断续续，可以降到 0.35 再试，但阈值太低会把路面阴影带进来。

我习惯把端到端时延压到 32.8 毫秒这个量级作为验收分界线。这个数字不是凭空定的，单帧图像从送入网络到输出车道线 mask 的延迟压在 33 毫秒以内，才能给上层规划留出足够决策余量。实测这份权重在 RTX 3090 上接近这个值，换到较低分辨率的边缘设备时需要结合 TensorRT 再做一次加速，但作为 CPU 上的项目交付验证，这个指标足够说服团队进入下一阶段。

自己在做验收时吃过一次亏：当时只看 IoU 高就以为可以上车验证，结果可视化后发现模型在强光路段不断把路肩裂缝识别成车道线。那之后我每次都强制走完一遍全流程：读图、转 RGB、resize 对齐、推理、反变换到原图、叠加可视化、统计时延，任何一个环节不过关都不算交付完成。这份资源里已经有训练好的权重和验证脚本，你只需要把数据路径换成自己的场景图，跑一遍这段流程就能确认模型边界在哪里。希望帮到你。

本文还有配套的精品资源，点击获取