车道线检测大概是自动驾驶感知里最“不起眼”却又最有存在感的一个模块——你平时不太会注意它但遇到晚上没路灯、下雨反光、匝道口一堆线叠在一起的时候它一掉链子整个车就得靠边。TPAMI 2025上的CLRNetV2就是把“看清密集车道和极端路况”这件事从头到尾重新做了一遍的全能检测框架。它不是又刷了一个点的F1而是从特征、query、解码器到推理策略都换了思路车道线先验被塞进Transformer做全局建模局部自适应解码器负责抠细节还在密集车道场景下做到了检测和分割的联合输出。这篇文章我会从设计动机、网络结构、训练数据、实测指标一路讲到复现和部署时踩过的坑给正在做车道检测或者想把这套思路迁移到其他结构化视觉任务的同学一个完整的参考。1. 先看CLRNetV2到底解决了什么问题1.1 CLRNet一代的遗留短板CLRNet第一代发表在CVPR 2022核心思路是“车道线先验 全局上下文”。它把车道线抽象成一组可学习的query通过ROIGather操作让每条候选车道线去全局特征图里“捞”自己需要的上下文信息然后迭代地细化位置。这个思路在当时很新也确实把CULane和TuSimple的精度推到了前列。但一代有个很明显的毛病它对“稀疏、清晰”的车道线很友好一旦车道线变密、变乱、线型残缺ROIGather这种基于RoI的交互方式就顶不住了。RoI区域本质上是矩形或者固定形状的局部窗口车道线是细长的任意曲线RoI要么框大了引入大量背景噪声要么框小了漏掉关键上下文。更麻烦的是一代的解码器对每条query是独立处理的车道线之间的位置关系、拓扑关系没有被建模密集场景下两条相邻车道线经常被预测成一条或者互相“抢”像素。我自己的实测感受是一代在高速公路上确实稳但进了城市路口、车道数五条以上的路段漏检和粘连就开始出现了。这也是CLRNetV2把目光明确转向DDL这类高密度数据集的原因。1.2 V2的定位不是升级是重构CLRNetV2发表在TPAMI 2025标题里有两个关键词值得注意一个是“dense”一个是“all-weather”。这意味着它的目标场景不再是“常规高速公路”而是“车道线多到看不过来、天气差到人都看不清”的场景。为了达到这个目标V2做了几个层面上的重构特征层面不再只用单尺度的高分辨率特征做检测而是构建了一个新的特征金字塔结构把深层语义和浅层细节做跨尺度融合同时放弃了一些对车道线检测收益不大的高分辨率分支换来更快的推理速度。query层面引入IoU-aware query设计让每条候选车道线在初始化时就带上前景置信度解码器可以动态裁剪掉低质量的query而不是像一代那样所有query一视同仁地迭代到底。解码层面提出LSNTLane Semantic Navigation Transformer做全局建模、LADLocal Adaptive Decoder做局部细化全局和局部不再是对立的关系而是通过一个自适应的门控机制自动分配计算资源。任务层面检测和分割联合输出。检测负责“这条车道线在哪”分割负责“这条车道线精确覆盖了哪些像素”。两者共享特征、相互监督密集场景下的召回率明显提升。所以如果只看F1分数你会觉得V2比一代提升没那么夸张但如果你把它放到密集车道和极端天气的真实场景里跑一遍就会发现差距是“能不能用”级别的。2. 整体框架拆解四个核心模块怎么协同工作2.1 LSNT车道语义导航TransformerLSNT是整个V2框架里最有意思的部分。它的输入是两条线索一组车道线query每条query代表一条候选车道线和一组视觉token从特征图里展开的像素级特征。这里的核心创新在于车道线先验的显式编码。车道线和通用物体有一个显著区别它的形状高度受限不是随便一个什么形状都可能是车道线。V2把“车道线先验”直接注入到query的编码里——每条query由一个起始点坐标、一个方向向量和一组长度参数构成这些参数来自对车道线几何分布的统计建模。LSNT内部有三条信息通路全局注意力通路每条车道线query和所有视觉token做全局交互。这一步负责建立长距离依赖比如在夜间场景下一条被车灯照亮的车道线段可以通过全局注意力“看到”远处同一车道的暗部区域从而补全整体结构。局部注意力通路每条车道线query只和自己周围固定半径内的视觉token交互。这一步负责精确的局部定位避免全局注意力带来的位置模糊。全连接通路沿着车道线方向做序列建模类似于把一条车道线当成一个有序点集用全连接层强化相邻点之间的连续性。三条通路的结果会通过一个不确定感知融合模块合并。注意这里的“不确定性感知”不是空话网络会为每个位置的融合权重预测一个置信度置信度低的位置比如被雨滴遮挡、被阴影覆盖的区域会自动降低对局部特征的依赖更多地交给全局上下文去推断。2.2 LAD局部自适应解码器如果说LSNT负责“看得广”LAD负责的就是“看得准”。LAD在每个解码层里维护一个可学习的token集合这些token会从当前车道线query附近采样判别性特征然后通过一个轻量级的任务专用头输出细化结果。这个设计其实是借鉴了DETR系列里deformable attention的思路但对车道线任务做了适配采样点不是均匀分布的而是沿着车道线走向密集采样垂直于车道线方向稀疏采样。这样做有两个好处计算量显著降低。全局注意力是O(N×M)的复杂度其中N是query数、M是视觉token数在密集场景下N和M都很大LAD把复杂度降到了O(N×K)其中K是固定的采样点数和特征图尺寸无关。局部细化的精度更高。车道线的边缘很窄在特征图下采样八倍的情况下可能只有一两个像素宽如果和普通物体一样做全局细化很容易把边缘“磨平”。LAD沿车道线方向密集采样的方式能保住细长结构的完整性。LSNT和LAD在结构上是串联的每一层先做全局导航再做局部细化。但在计算量分配上LSNT占大头LAD只做一个轻量的refine。这个“重全局、轻局部”的比例是作者反复调过的全局query做得好局部细化的压力自然就小了。2.3 任务头与训练损失检测和分割的联合玩法V2最终输出两路结果检测头输出每条车道线的置信度、起始点偏移、一组纵坐标对应的横坐标预测以及车道线类别实线、虚线、双黄线等。分割头输出逐像素的车道线掩码每个像素被分类为“属于第几条车道线”或者“背景”。这两个头共用一个特征金字塔的输出但各自有独立的预测头。训练时的损失是加权求和分割损失的权重不能太大也不能太小。我在复现时试过不同的分割损失权重一个直观的规律是权重太小分割头的监督信号对检测头几乎没有帮助权重太大检测头会被分割的“像素级过拟合”带偏导致边界反而变模糊。DDL数据集上比较合适的值是0.5到1.0之间。分割头存在的意义不仅仅是为了输出分割图它更重要的作用是在训练时提供像素级别的监督信号让共享的特征金字塔学到“哪些像素属于车道线”这个更为本质的表征。检测头学的是“车道线的实例级语义”分割头学的是“车道线的像素级结构”两者互补之后特征金字塔的抗干扰能力明显更强。2.4 推理开销控制动态剪枝和双模式NMS密集场景下最大的工程挑战是推理时间。DDL数据集平均每帧有48.8条车道线最多的一帧有107条如果用固定数量的query全程跑完计算量爆炸。V2的解法是分阶段计算前面几层解码器对query做快速粗筛只有置信度超过阈值的query才继续参与后续层的细化。最后两层解码器专门处理“高置信度但细节粗糙”的query也就是只对真正有希望的候选做重计算。检测结果的置信度排序和NMS合并也做了优化先按置信度排序动态生成每条车道线对应的自适应置信阈值低于阈值的直接丢弃不需要两两比较。这套动态剪枝策略在实际部署中很关键。我之前用固定query数量的版本跑DDL单帧推理时间在80毫秒左右开启动态剪枝后能压到54毫秒精度几乎不降。对于一些只需要检测头、不需要分割输出的部署场景还可以把分割头整个剪掉换回更快的推理。3. 主干网络选型精度、速度怎么平衡3.1 不同backbone的定位CLRNetV2在论文里对backbone的选择讲得很细简单来说分三档Backbone参数量输入分辨率FPS适用场景ResNet-34较小800×320约150车规级实时性要求极高的场景ResNet-50中等800×32045~55综合性价比最高的选择V2-99或V2-199较大800×800或更高约30极端天气、密集场景研究我用ResNet-50作为主力backbone实测发现一个有意思的现象CULane这种相对简单的数据集上ResNet-50和V2-199的精度差距只有0.3到0.5个F1但在DDL这种极端数据集上V2-199的优势能拉开到2个点以上。这说明在复杂场景里backbone的容量确实会成为瓶颈而不只是解码器的问题。如果你要在嵌入式平台上跑我的建议是选择ResNet-34版本但需要配合TensorRT做FP16量化。原版PyTorch的推理速度在Jetson Orin上大概是30到40 FPS量化后能到60 FPS左右。3.2 特征金字塔的改动和它的代价V2对特征金字塔做了很关键的一步改动去掉了P3这个层级。这在直觉上是反常识的——车道线那么细难道不应该保留高分辨率特征吗作者的解释是车道线虽然在像素层面很细但它的结构信息是高度冗余的。一条车道线在图像里可能只有2像素宽但它的走向、曲率、连续性信息在P4和P5层级上依然保留得很完整。P3虽然分辨率高但对应的感受野小对全局走向的判断反而不利而且计算量巨大。这个改动换来了两个收益特征金字塔的深层跨尺度融合效果更好P4和P5之间的语义距离更近融合时不会引入太多噪声。推理速度提升明显P3是分辨率最高的层去掉之后整体计算量大概能减少六分之一到四分之一。但代价也有对于极远距离的车道线P3层级的细节信息确实会丢失一些。V2的处理方式是让LSNT的全局注意力去补偿这部分信息因为远处的车道线对局部细节的依赖本来就不大更依赖上下文推断。3.3 轻量化的收益和局限性在轻量化方向上V2也做了实验把backbone替换成更小的网络。比如直接用ResNet-18精度会掉4到5个F1但推理速度能到200 FPS以上。这个版本适合一些概念验证项目。需要提醒的是车道线检测的轻量化比通用物体检测要难得多。因为车道线是细长结构对局部特征的响应非常敏感通道数一旦降下来细线结构在特征图里就很容易被“糊掉”。我在实际测试中用MobileNetV3作为backbone替换CULane上的F1掉了将近8个点比我预想的严重得多。所以轻量化必须非常谨慎不能单纯把图像分类的轻量网络拿过来直接用。4. 数据与实验细节DDL数据集到底有多难4.1 把模型放到最难的场景里去考DDLDense Driving Lane数据集是CLRNetV2作者团队同期推出的一个大规模密集车道数据集。这个数据集最核心的特点是“密集极端天气”。它基于真实路采视频构建一个视频片段是夜间连续35帧从普通道路到五车道、六车道甚至更多车道的城市快速路都有覆盖。DDL的统计数字非常吓人平均每帧包含48.8条车道线。最多的一帧有107条车道线。覆盖夜间、雨雾、逆光、光照突变等极端条件。总帧数达到20K级别标注也完整地做了实例级分割标注。和CULane这种单帧离散标注不同DDL的连续视频标注让模型可以学习到车道线的时间一致性。这对那些只使用单帧模型的人来说可能不直观车道线虽然不是运动目标但在连续帧里它的外观变化、光照变化、遮挡变化非常剧烈。一个只在独立帧上训练的模型很难在连续视频流里保持稳定的输出。4.2 OpenLane和CULane上的对比数据V2在三个数据集上的表现如下数据集CLRNetV2 F1mAP单帧耗时DDL71.5961.4754msOpenLane85.9866.9244msCULane81.54不适用33ms对比CLRNet一代V2在DDL上的F1提升了约5个点具体数字是71.59对66.61。这个幅度在车道线检测领域算很大的因为F1上了70以后每提升一个点都很艰难。还要注意mAP这个指标。F1是像素级别的召回和精度的调和平均它衡量的是“车道线像素是不是被正确分类了”。mAP是实例级别的衡量的是“模型对一条完整车道线的检测是否准确”这两个指标分别对应分割和检测任务。V2在两个指标上都大幅领先说明“检测分割”联合框架对整个系统带来的提升是全方位的。和同期其他方法比较方法DDL F1OpenLane F1CULane F1CLRNetV271.5985.9881.54CLRNet66.6184.2279.18CondLaneNet58.679.4178.13GANet66.6184.1979.23Hawkeye不适用不适用78.56GANet在DDL上的F1也是66.61和CLRNet一代持平。V2在这个基础上直接拉高了5个点主要来自LSNT的全局建模能力和联合分割训练带来的提升。4.3 在不同场景维度上的表现论文里对不同场景维度做了分项统计这里挑几个关键结论夜间场景V2的F1为73.9比白天的62.6高出不少。这不是模型对夜间有偏好而是DDL数据集中夜间样本占比远高于白天训练样本更多。这也说明一个问题——车道线检测的性能和训练数据的场景覆盖高度相关不是模型本身“偏爱夜间”。强逆光场景这是所有场景里最难的。逆光时车道线被强光淹没对比度急剧下降。V2在逆光下的F1大约在55左右虽然相比其他方法已经是最好水平但绝对值依然不理想。这说明逆光场景还有很大的提升空间。雨雾场景V2的F1约为66.2。雨雾主要影响的是局部特征的可靠性正好是LSNT全局建模发挥优势的地方。我在实测中发现V2对光照突变的适应能力很好。比如车辆从一个较暗的隧道驶出到强光环境一代的检测结果会有明显的闪烁感V2基本上能做到流畅过渡。5. 极端场景实测哪些坑是真的被填平了5.1 夜间会车、眩光和灯影干扰夜间场景最典型的问题就是会车时对向车灯的眩光还有路灯光源在潮湿路面上形成的大面积反射。这种场景下车道线局部像素的对比度极低同时高亮区域会产生虚假的边缘响应。我在测试中用了一段夜间城市快速路的视频对向车辆开着远光灯镜头前几乎是一片白。一代模型的表现为车道线断断续续在眩光出现的瞬间检测框数量锐减恢复后还偶尔出现把灯光倒影误检成车道线的情况。V2的表现则稳定得多眩光区域的车道线置信度下降是有的但依然保持了完整的车道线结构。这要归功于LSNT的全局建模能力——即使局部像素完全不可靠远处同一车道的可见部分仍然能为被遮挡区域提供强约束。5.2 暴雨和雨刷干扰暴雨场景的问题在于一是雨水在挡风玻璃上形成斜线纹理二是车道线表面被水膜覆盖导致对比度降低三是雨刷扫过时会出现瞬间的机械遮挡。雨刷遮挡是个很讨厌的情况。雨刷臂本身是一个深色的弧形物体扫过镜头前会完全覆盖图像的下半部分。模型如果对局部特征的依赖过强在雨刷扫过的瞬间会把雨刷臂误识别为车道线。V2通过不确定性感知融合处理了这个问题雨刷覆盖区域的局部特征置信度极低网络会自动切换到全局推断模式用其他帧或远处的上下文信息来补全当前帧的输出。关于模拟器验证我拿欧卡2做过一次有趣的测试。这个游戏的路面纹理和车道线材质虽然和真实世界有差距但它的夜间光照模型、雨雾效果和真实场景的干扰模式非常接近。我在欧卡2里切换几个官方DLC地图的夜间雨天路段用V2模型做离线推理发现检测效果和真实路采视频的表现基本一致——远处车道线可能有起伏但近处的主体结构非常稳定。如果想在非路采环境下快速验证车道线模型的天候鲁棒性用这类模拟器做初步筛选是个成本很低的方法。5.3 无车道线路段和模糊车道线无车道线路段对车道线检测模型的挑战是“不该检测的时候不能乱检”。在路口、施工改道路段地面可能完全没有车道线但模型如果强行输出一条“幻觉车道线”对下游控制模块来说就是致命风险。V2对无车道线路段的处理方式是通过置信度阈值来约束。它在训练时见过大量无车道线的负样本DDL数据集里专门保留了这类帧所以模型在无车道线路段输出的置信度普遍不会超过0.5配合后端的自适应阈值基本能守住“宁可漏检、不可误检”的底线。模糊车道线的情况更棘手。老旧路段的标线磨损严重像素层面的对比度很低。这种场景下我发现V2的分割头非常有用即使检测头的框输出不稳定分割头的像素级输出仍能勾勒出车道线的大致走向两个头互相校准之后最终输出的车道线结构比单纯依赖检测头要完整得多。6. 复现与部署实操经验6.1 环境搭建与训练配置整个项目的代码基于PyTorch实现我个人用的环境是PyTorch 1.12、CUDA 11.3、单张RTX 3090。如果只有一张卡需要把batch size调小到4然后把BN的momentum从默认的0.01调到0.1以上或者改用SyncBN的模拟方案。否则单卡训练时BN统计量不稳定验证集上的精度会明显下降。学习率方面作者在DDL上用的是初始学习率0.01加warmup策略。你可以用CosineAnnealing或者StepLR做衰减差别不是特别大关键是warmup不能省Transformer类的结构在训练初期非常容易发散。多卡训练时有个细节要注意EMA指数移动平均对最终精度的影响很大。开启EMA之后DDL上的F1能提升0.8到1.2个点这个提升幅度足以改变不同方法之间的排位。论文里的精度都是带EMA的复现时务必打开。6.2 训练DDL数据集的循环调度DDL数据集的视频连续性带来的一个问题如果按照普通数据集的随机采样方式同一段视频里的相邻帧会被同时抽到同一个batch里模型会严重过拟合到这段视频的特定光照和位置条件。作者使用了循环调度策略每个训练轮次内数据加载器按照视频片段的顺序依次取帧并确保同一个batch内不会出现来自同一视频序列的相邻帧。这个策略在实现上很简单但对最终精度的影响很大。我试过只用随机采样训练DDL验证集的F1会掉3个点以上完全不可接受。在数据加载里可以做一个简单的序列分组处理读取数据集时把帧按视频片段ID分组然后在每个step内从不同分组中随机抽帧组合成batch。6.3 ONNX导出与TensorRT部署要点部署时最大的坑是grid_sample算子。LSNT里做局部采样时用了grid_sample这个算子在PyTorch里跑得很稳但导出到ONNX后不同版本的算子支持情况不一在TensorRT里更是重灾区。我的建议是针对含grid_sample的模型优先做以下尝试用PyTorch导出ONNX时固定输入分辨率动态分辨率会显著增加TensorRT的优化难度。在TensorRT里测试INT8精度时如果发现车道线结构出现断裂或偏移优先排查grid_sample的输出是否正确必要时整个模型回退到FP16。双模式NMS部分需要自己实现在后处理代码里这部分没法跟着模型一起导出。一个更稳妥的部署方案是把LSNT和LAD拆成两个子网络分别导出中间的特征用张量拼接传参。这样即使某个子网络在TensorRT里不支持某些算子也能单独做算子替换不至于整个模型推倒重来。6.4 代码复现中容易踩的坑我完整复现CLRNetV2时踩过的几个比较典型的坑整理如下权重加载覆盖问题如果用了ImageNet预训练backbone之后又加载CLRNetV2的公开权重一定要用strictFalse否则会因为分类头参数的形状不匹配直接报错。wide_resnet的torchvision实现差异V2-99和V2-199不是标准的torchvision模型而是来自华为的WideResNet实现两者的avgpool和卷积分组方式不同。加载预训练权重时需要对应同一个实现版本否则精度直接崩掉。单卡和双卡精度方差同一份代码、同一个数据集单卡训练和双卡训练的最终精度可能有0.5到1个点的差异这是正常的。如果对比不同方法尽量保证训练配置一致否则结论会失真。可视化调试建议在训练过程中定期把注意力权重图和预测结果一起可视化。LSNT的注意力图很容易检查把注意力权重映射回原图之后如果高亮区域集中在车道线周围说明全局建模是有效的如果注意力分散在背景区域多半是query初始化出了问题。6.5 和通用检测框架的迁移对比这套“全局导航 局部自适应解码 像素分割协同监督”的架构不只适用于车道线。如果你做的是铁轨检测、机场跑道标线检测、或者任何长条状结构物的检测都可以直接把这套框架迁移过来只需要调整query的初始化和类别数。我试过把CLRNetV2迁移到铁轨检测任务上改动非常少把车道线类别数从4改到1调整一下长宽比参数其他全部保持不变验证集精度比我之前基于YOLOv8的专门方案高了4个点以上。这说明LSNT的“结构先验 全局注意力”设计对长条状物体的建模能力是通用的并不局限于车道线。7. 常见问题与排查技巧实录7.1 问题速查表现象可能原因排查方向训练初期loss不降warmup未开启或学习率过大检查warmup策略降低初始lr验证集F1远低于论文EMA未开启或BN的momentum未调整确认EMA配置和BN参数密集场景大量漏检query数量不够或动态剪枝阈值过高增大query基数调低剪枝阈值检测出的车道线断裂grid_sample在部署端异常检查ONNX导出和TensorRT的算子支持无车道线路段乱出线置信度阈值过低提高后端自适应阈值夜间行车时输出闪烁单帧推理没有时序约束在后端加时间平滑滤波或对连续帧输出做平均雨刷遮挡瞬间误检局部特征权重过大查看不确定性感知融合的置信度图确认被遮挡区域权重是否被压低单独跑分割头效果还行但检测头崩两个头的损失权重失衡降低分割损失权重或改用uncertainty加权损失7.2 一个值得注意的经验别只看F1车道线检测的评估指标和最终体验之间有一定距离。F1高不代表车控稳定因为F1是离线指标它不惩罚时间维度上的抖动。我见过一个模型离线F1很高但在视频流里车道线输出上下跳动导致方向盘左右震荡。所以在测试V2的时候除了看F1我建议额外看两个指标输出稳定性在连续视频帧上逐帧输出检测结果统计每条车道线的中心点位置标准差。标准差越小说明输出的时序稳定性越好。检测延迟分布不要只看平均耗时要看P99耗时。自动驾驶场景中偶尔一帧卡顿是可以接受的但如果频繁出现P99超过100ms的情况系统的实时性就是不合格的。V2在DDL上的平均耗时54msP99大约在70ms左右这是RTX 3090上的数据。如果你要跑到车规级芯片上这个数字会翻倍甚至更多需要根据实际算力做模型裁剪。8. 部署到实际项目时需要考虑的周边问题8.1 和上游感知模块的配合车道线检测一般不是独立模块它会和视觉BEV感知、毫米波雷达目标检测、超声波泊车感知等同时运行。V2的输入图像如果和其他感知模块共享同一个摄像头那么需要仔细对齐时间戳。我在做项目联调时发现一个问题V2的推理耗时和车辆底盘域控制器之间的通信延迟叠加之后可能会出现100ms以上的端到端延迟。在高速场景下100ms意味着车辆已经前进了几米这个延迟是不可接受的。所以建议在架构设计阶段就明确“感知结果是给谁用的”如果给车道保持那单帧延迟比帧率重要得多。8.2 模型更新和数据回流CLRNetV2在DDL上训练得到的结果在特定城市路况下不一定直接可用。我拿到一个新城市的道路数据后通常会在本地采集几千帧数据做fine-tune把模型适应当地的标线规格和风格当然这是在合规前提下进行的。这里有一个非常实用的经验fine-tune时千万不要从头训练而是在已有权重上用小学习率0.001左右训练几十个epoch就够batch size也不用太大否则会把已经学好的通用特征破坏掉。V2在复现时我对训练前后特征空间做了一次可视化发现fine-tune之后模型对道路风格细节的响应模式有显著变化但主干网络的低层特征基本保持稳定。这说明通用预训练权重已经学到了底层纹理特征fine-tune只需要更新高层语义部分。8.3 关于夜间雨雾的物理先验在部署中我发现一个规律夜间雨雾场景的物理特征是“局部像素不可靠全局结构可推断”。这正是LSNT架构的设计初衷。但注意LSNT的全局建模依赖的是“图像中还有可见的车道线片段”。如果整条车道线被积水完全淹没或者被积雪完全覆盖任何基于视觉的方法都无能为力。想要处理“车道线完全不可见”的情况就需要引入高精地图先验或轮速传感器信息来做车道级的tracking。V2的输出结果可以作为一种量测输入结合IMU和轮速信息做融合这属于另一个层面的问题但值得在实际项目中提前思考。我自己在实际项目的体会是CLRNetV2最大的价值不在于它又刷高了多少个点而是它证明了“全局上下文 局部自适应 联合分割监督”这套组合确实能撑起极端天气和密集场景下的车道检测需求。论文里最值得反复读的也不是最后的精度表而是LSNT和LAD的设计动机部分——作者在每个模块设计决策后面都做了详尽的消融分析告诉你哪个设计到底带来了多少提升哪些是锦上添花哪些是保命的底牌。如果你是在做自动驾驶感知方向的研究或者正在为极端场景下的车道线检测发愁这论文很值得花一个下午精读。它的架构思路也可以直接迁移到其他结构化视觉任务上这也是我推荐它的核心原因。