CAN与CAN-FD总线深度解析：从物理层到工程实战的硬实时通信之道

1. 为什么我说CAN总线是沙子到车辙系列里最扎实的一章从沙子到车辙这个系列写到第4章前面几章我聊了芯片怎么从硅砂变成逻辑门、软件怎么从汇编跑成实时任务但说实话真正让我觉得这玩意儿总算能跟机械硬碰硬了的是我们今天要聊的CAN / CAN-FD总线。如果你在汽车电子、工业控制、机器人或者任何跟多节点实时通信沾边的行业待过你大概率已经跟CAN打过照面。不管你是刚入行的嵌入式工程师、做域控制器的软件负责人还是被总线信号折磨的测试工程师搞清楚CAN和CAN-FD的底层逻辑比背一百个寄存器有意义得多。CAN总线之所以值得单独拿出一章原因在于它解决了一个非常朴素但极其棘手的问题在一条共享的物理线路上让几十个节点以确定性的方式交换短帧数据同时保证实时性、可靠性和成本可控。它不像以太网那样追求大带宽和复杂拓扑而是把够用、够快、够稳做到了极致。过去三十年从门窗控制器到制动系统从动力总成到自动驾驶域控CAN家族几乎统治了车内通信的半壁江山。而现在CAN-FD的出现又把这条老总线的生命周期至少延长了十年。这一章的内容我原本打算写得跟前面几章一样偏原理党但想了想如果只讲协议到头来还是没解决实际问题。所以这篇文章我会从物理层讲起一直讲到控制器配置、采样点计算、总线仲裁、错误处理、CAN-FD布线与兼容性最后把我在实际项目里踩过的坑整理成一份排查清单。你可以把它当作从协议到量产的完整参考也可以只挑你关心的部分直接抄作业。2. 先从物理层说起CAN总线到底在传输什么2.1 一对差分线怎么就能传那么多信号CAN的物理层基础是差分信号一根CAN_H、一根CAN_L两根线绞在一起以差分电压的形式表达逻辑电平。所谓显性域dominant和隐性域recessive简单理解就是两根线电压差大于阈值时总线被拉成一个确定的电平这就是显性两根线几乎同电位时总线处于隐性。显性优先于隐性这是CAN协议所有仲裁、应答、错误机制的基石。你可以把这条总线想象成一条单向的、多人共用的窄巷子凡是有人要喊话整条巷子都会被听到先喊的人优先后喊的人自动退回。我经常用弱上拉这个词跟新人解释隐性电平总线空闲时所有节点都不驱动靠终端电阻和收发器内部电路把两根线拉到大致相等的电平而任何一个节点要发送显性位就直接把CAN_H拉高、CAN_L拉低产生一个大约1.5V到2.5V的差分电压。这种平时没人说话一说话全车都听见的设计天然避免了以太网那种需要复杂交换逻辑的冲突检测而是用电气层面的线与完成了优先级仲裁——这就是CAN能够做到硬实时的第一个秘密。2.2 终端电阻不是摆设少了它总线就会反光两根线端各接一个120欧姆的终端电阻这个在很多新手看来是照着手册画的但你不理解它后面遇到信号反射、CRC错误暴增的时候就会头疼。CAN收发器在总线上输出的是一个电流型差分信号需要终端电阻把这个电流转换成电压供接收端判断。传输线理论告诉我们当信号到达阻抗不匹配的线路末端时会产生反射反射波叠加在原信号上可能导致采样点误判。两根120欧姆电阻并联后正好是60欧姆这跟标准CAN收发器的输出阻抗匹配能最大程度减少反射。实际项目里我见过不少终端电阻只装一端或者两个节点都装了可是并联值不对的情况。尤其在开发阶段有人用一截短导线把收发器输出直接连到CAN分析仪上忘了挂120欧姆结果波形看起来还行采样点偶尔出错。你真要较真用示波器看上升沿就能看到明显的振铃。所以我的建议是至少保证总线两端各有一个终端电阻并且总等效阻抗在你线缆特征阻抗的90%到110%之间。低速短链小于1米偶尔省略终端电阻不至于立刻出问题但一旦节点数增多、线长超过半米该挂的就老老实实挂上。2.3 收发器的选型从PCA82C250到TJA1044差别不只是封装很多入门资料把CAN收发器当成无脑选一个芯片接上就行但你在不同电压域、不同速率、不同休眠需求下会发现自己以前太乐观了。经典的PCA82C250只支持5V逻辑电平而现代控制器的IO口很多是3.3V这时候你需要选带VIO引脚的收发器比如TJA1044、TJA1051来匹配逻辑电平否则你得加额外的电平转换电路。另一个容易被忽略的点是待机电流和总线唤醒能力在整车静态电流要求从毫安级别压到微安级别的今天一个不支持待机唤醒的老收发器可能直接让整车的台架测试歇菜。我自己做域控制器样机时偏好带显性位超时保护的收发器。原因是车辆在复杂电磁环境下总线偶尔出现应力脉冲会把某个节点误锁在发送状态如果收发器不能检测到连续显性超时并自动释放总线整个网络就会因为一个故障节点被拖死。这个特性在协议层很难快速恢复放在物理层做保护就是最硬核的兜底。3. 协议核心帧结构、仲裁与错误处理的为什么3.1 标准帧和扩展帧别只记得ID长度不一样CAN 2.0A标准帧的标识符是11位CAN 2.0B则是29位扩展帧。表面上看只是ID位数的区别但你是做系统设计的必须理解扩展帧的意义在标识符空间扩大之后的优先级规划和兼容性处理。11位最多2048个不同ID在实际多控制器项目里尤其遇到联合调试、需要给多个ECU保留ID池时扩展帧能提供更多规划余量。但扩展帧不是免费的多出的18位标识符会让整个帧更长意味着在同样的仲裁机制下扩展帧在跟标准帧竞争总线时因为优先级比较发生得更晚要等标准帧的11位ID比较完之后才轮到扩展帧的高ID位反而可能输给优先级较低的标准帧。所以很多OEM的通信矩阵里关键报文刻意选用标准帧以换得更靠前的仲裁窗口。你在做报文矩阵时如果对CAN-FD的相同ID标准帧优先于扩展帧规则不熟悉很容易在实际联调时发现为什么某个扩展帧ID明明设得很小却抢不过一个ID很大的标准帧。3.2 仲裁机制一条总线同时发消息到底谁赢CAN总线是多主架构任何节点只要有发送请求都可以在总线空闲时开始发送。但如果多个节点同时开始发送怎么办答案是逐位仲裁bit-wise arbitration发送节点每发送一个位同时监测总线电平如果一个节点想发送隐性位却检测到总线上是显性位它就知道有更高优先级的节点也在发送立刻退出竞争直到下个总线空闲窗口再重新尝试。这个机制的实现成本极低却能保证高优先级报文的最大延迟有一个严格上界。我在给学生讲实时性时喜欢举这个例子假设总线波特率是500kbps一条标准帧最多128个位周期那么最高优先级报文的最坏响应时间就限定在一帧的总线占用时间加上调度间隔内不需要像以太网那样依赖交换机缓冲。对于制动、转向、气囊这类功能安全相关的报文最坏延迟可计算比平均带宽高重要得多。所以哪怕以太网带宽是CAN的上千倍车规级安全域通信到现在仍然大量使用CAN和CAN-FD。3.3 错误帧、CRC与错误计数器CAN怎么做到自己治自己任何一个工业总线如果不具备错误检测和错误隔离能力都无法做到大批量量产。CAN设计了5种错误检测机制位错误、填充错误、CRC错误、形式错误、应答错误。其中CRC循环冗余校验覆盖从SOF到Data字段的全部内容15位CRC的检错能力对短帧而言相当强。真正让我觉得CAN聪明的地方是错误计数器。每个节点都维护着发送错误计数TEC和接收错误计数REC每遇到一个错误计数按规则增减。当某个节点的TEC超过127它会进入错误被动状态只能接收、不能主动发送而且必须等到总线空闲后才能尝试恢复如果TEC再超过255节点直接进入总线关闭状态彻底断开。这个机制相当于让总线自己把病节点隔离出来不让一粒老鼠屎坏了一锅汤。我在排查波动率很高的CAN节点时第一个动作就是抓错误计数器。有一次某台样机运行十几分钟就出现一堆紧急故障码我一度怀疑是报文设计的问题后来通过诊断接口读出该节点的TEC发现它每隔几分钟就跳到100以上。顺藤摸瓜找到是某条线束的屏蔽层破损在发动机运转时不断耦合进共模噪声导致收发器采样错误。如果没有错误计数器这个抓手这个排查周期可能要多出两三天。4. CAN-FD变的是帧不变的是灵魂4.1 CAN-FD到底改了哪三件事CAN-FDCAN with Flexible Data-rate是在经典CAN 2.0基础上演进出来的它最直观的改动有三个可变速率、更长数据字段、新的CRC算法。经典CAN的固定波特率在整个帧传输过程中是不能变的而CAN-FD允许整个帧在仲裁段和数据段分别使用不同的速率。仲裁段继续用经典波特率比如500kbps数据段可以切到2Mbps甚至5Mbps以上这样既保证了多节点仲裁时的兼容性又提高了有效数据吞吐。数据字段从8字节扩展到最大64字节意味着同样数量的报文可以携带更多信息对需要传输高精度地图、环境感知数据、电池状态块等大数据的域控制器来说特别解渴。很多人以为CAN-FD只是把速率调高、把数据加长实际上它的帧格式调整引发了一连串连锁反应更长的数据段导致位填充开销变小但CRC覆盖范围变大因此引入了更强的17位或21位CRC同时为了跟经典CAN兼容CAN-FD帧在仲裁段有特定的保留位重组方式。你对这些细节不敏感直接拿经典CAN的时序分析工具去量CAN-FD的速率切换边沿十有八九会误报错误。4.2 兼容性陷阱什么时候能混用什么时候必须隔离CAN-FD控制器向下兼容经典CAN但总线上的收发器不一定支持。所谓的兼容分两层一是控制器能不能配置成只发经典CAN帧二是收发器带宽能不能支持数据段高速率。如果你的节点既想跟老ECU通信又想利用CAN-FD的高速数据段你需要把收发器换成支持CAN-FD的型号信号上升沿更陡支持更高翻转速率否则即便协议栈配置了CAN-FD帧物理层也发不出去。实际项目里最坑的不是全都用CAN-FD而是一部分节点用CAN-FD一部分节点用经典CAN还挂在同一条总线上。经典CAN节点不认识CAN-FD帧的新格式会把它当作错误帧处理。所以要么整个网络切换成CAN-FD模式要么在网关或者路由层面做经典CAN与CAN-FD的协议转换。设计通信矩阵时一定要提前确认你规划的CAN-FD报文占用的标识符区间不能让老节点看到否则老节点会把所有CAN-FD帧都当成总线错误。4.3 什么时候需要上CAN-FD什么时候其实没必要我在跟同行聊天时经常听到一个错觉只要数据量变大就该换CAN-FD。说实话CAN-FD的最主要收益在于把多个小报文合并成一个长报文从而减少总线仲裁次数和帧头部开销。如果你的系统只是节点多、但每个节点每次就传8字节以内的状态量那经典CAN已经够用强行上CAN-FD除了增加开发成本对可靠性没有任何帮助。反过来如果你的域控制器需要向多个执行器下发一大块参数曲线比如转向系统的助力曲线、电池管理系统的温度补偿表或者要给OTA刷写传输固件镜像那么CAN-FD带来的单帧64字节数据段高速率就是实打实的效率提升。我做过一个模拟项目X原本用经典CAN传一张覆盖400个点的标定表每帧8字节、每字节一个点加上协议开销一个完整的标定表更新要分五十多帧走耗时几十毫秒换成CAN-FD一帧直接塞下64个点整张表五六帧就传输完毕用户体验完全不一样。这个场景下CAN-FD的价值不是快了一点点而是把不可能变成了可能。5. 实际项目从零配置CAN/CAN-FD的实操步骤5.1 先定波特率和采样点别急着写代码一个常见错误是拿到开发板先配代码把寄存器填好跑起来才发现波形不对。我的习惯恰恰相反先花十分钟算波特率和采样点再用示波器或总线分析仪确认波形然后才动软件。波特率的选择取决于你的晶振频率、外设时钟和总线负载。假设外设时钟是80MHz你希望经典CAN段跑500kbps那需要把分频后的时间片Time Quantum, TQ设置成一个TQ 1/(80MHz / 分频系数)。通常总线时间由若干个TQ组成一个位周期比如一个位周期 16个TQ那么所需分频系数 80MHz / (500kbps * 16) 10。也就是说APB总线分频后每个TQ是125ns16个TQ恰好构成一个2微秒的位周期也就是500kbps。接下来是采样点。采样点决定了接收端在什么时刻去读总线电平它通常是一个位周期的百分之多少。经典CAN建议采样点落在70%到85%之间我习惯放在80%左右。还是拿16TQ位周期举例假设把采样点设为80%那么同步段为1TQ传播段相位缓冲段1合计约为12TQ相位缓冲段2为3TQ。这样配置的物理意义是发送节点也是靠这个采样点去读总线的如果采样点太靠前容易在信号建立不完整时误判太靠后又可能赶上下一位的起始边沿。CAN-FD的采样点设置更讲究因为数据段速率升高后位时间更短采样窗口更窄。通常做法是仲裁段沿用经典CAN采样点比如80%数据段可以稍微提前70%到75%因为高速率下信号建立时间占比更大采样太靠后容易受振铃影响。做量产项目务必用总线分析仪抓真实波形反复微调相位缓冲段的配置。5.2 滤波器配置不是所有ID都得进你的中断CAN控制器一般都有硬件滤波功能可以只让你想处理的ID通过其余帧直接丢弃不产生中断。很多新手初学时不配置滤波器每收到一帧都进中断帧率一高CPU满负荷跑在中断里反而丢失重要报文。配置滤波器前你先要明确我这个节点需要接收哪些ID需要接收标准帧还是扩展帧。以常见MCU为例滤波器通常有两种模式掩码模式和列表模式。掩码模式适合按ID段过滤比如只接收所有ID高字节为0x18的报文列表模式适合精确指定两个或者多个特定ID。实际ECU开发里优先用列表模式把每个需要接收的ID明确列出配合位宽检查能最大程度避免过滤过头把关键报文丢了或者过滤不足导致中断泛滥。我在某个跨平台系统的调试中遇到过网关收到很多明明不需要的报文的问题后来排查发现是滤波器配置在初始化时被覆盖了——某个流程里先配置了寄存器后面执行了某个驱动库的回调又把滤波器恢复成默认的全接收模式。所以我的建议是滤波器配置应该在所有驱动初始化的最后执行并且在主循环里定期用诊断命令回读滤波器寄存器防止被其他中间件改写。这个问题看起来小但排查过程极其折磨人因为它只在特定调用序列下出现正常跑根本不报错。5.3 波特率切换和速率的二次握手CAN-FD工程化的关键CAN-FD的速率切换不是简单地在帧中间变个时钟就可以它需要接收端能准确识别从仲裁段到数据段的切换点。这个切换点通过BRSBit Rate Switch位来指示当发送节点置位BRS总线上数据段位的时长就按照数据段计时规则来算。如果接收节点的控制器不支持CAN-FD或者它的收发器带宽不够它无法识别这种切换就会产生错误帧。所以在CAN-FD网络联调前必须逐一确认所有节点的CAN控制器和外收发器型号是否明确声称支持CAN-FD并检查数据段最高速率是否覆盖你预期的速率。还有一个工程细节CAN-FD允许数据段速率是仲裁段的整数倍或非整数倍但不同控制器的相位缓冲段、传播延迟补偿能力各不相同。我在实际项目里见过两块不同厂商的控制器一个数据段最高支持2Mbps另一个最高支持5Mbps当我以5Mbps跑数据段时低速节点的采样窗口不够频繁出错。最后我把数据段速率降到2Mbps才达到稳定跑通。速率不是越高越好是整条总线所有节点的收发器、控制器、线缆物理特性都能扛住才好。6. 从GI节点到分布式控制总线负载与拓扑设计经验6.1 用总线负载率公式判断是不是快满了总线负载率说白了就是在一定时间内总线上实际传输的数据位数量与理论最大位数量之比。公式很简单负载率 (所有报文帧长度之和 × 发送频率) / 总线速率。假设你总线上有10条周期报文每条周期10ms每条报文平均120位那么每秒总位数是 10条 × 100帧/秒 × 120位 120,000位。如果总线速率是500kbps那么负载率是 120000 / 500000 24%。这个数值看起来不高但你要记得除了周期报文还有事件触发报文、诊断请求/应答、网络管理报文、错误重发等实际峰值负载往往比平均值高出很多。工业界一条经验准则是经典CAN总线的平均负载建议控制在50%以下峰值控制在80%以下CAN-FD由于数据段速率更高平均负载可以相对放宽但仲裁段的负载依然要按照经典规则控制。为什么这么保守因为一旦总线负载过高低优先级报文的等待时间就会变长触发的错误重发可能进一步占用总线形成恶性循环。你可以想象成一条高速匝道正常流量下每辆车都能顺利汇入但流量接近饱和时一辆车堵住后面积压越来越大最终整条匝道瘫痪。6.2 星型、线型、菊花链不同拓扑的取舍CAN在物理拓扑上最常见的是线型总线两端端接终端电阻节点通过短支线接入主干的T型或V型连接。因为信号反射与支线长度直接相关每个节点的支线越短越好布线时尽量做成主干贯穿节点就近挂接而不是把每根传感器线都悠长地拉到控制器旁边再合并。CAN-FD受速率提升的影响对支线长度和连接器寄生电容更敏感。我见过一个测试环境所有设备都摆在一张桌子上线束只有三四十厘米跑1Mbps数据段毫无问题但转成实车线束同样配置却频繁报错。后来发现问题出在连接器本身的寄生电容和线束屏蔽层接地方式。当数据段速率超过2Mbps时即使很小的寄生电容也会在信号边沿形成明显的圆角导致采样误判。所以你在设计CAN-FD网络时必须把连接器型号、线束绞合节距、屏蔽层接地方式都考虑进去不能拿着实验室短线的经验直接上实车。6.3 网关与路由不同速率网络之间的消息搬运在多域控制器的架构里车身域、动力域、底盘域往往使用不同的CAN/CAN-FD网络它们之间通过网关或域控制器完成报文路由。网关转发报文的两个核心问题一个是速率匹配一个是周期同步。从CAN-FD高速网络转发到经典CAN低速网络时如果一条CAN-FD报文的64字节数据无法塞进经典CAN的8字节帧里你就得设计分包策略分包后还需要考虑接收端能不能组装回原始语义以及分包报文如果中间丢了一包接收端该怎么判断超时并丢弃不完整的集合。我做某跨平台系统时写过一套简单的网关路由矩阵核心思想是接收即缓存、发送按周期调度。具体来说每一个需要转发的报文先在网关侧建立一个数据副本然后按照目标网络的周期安排发送而不是收到一帧立刻转发一帧。这样做的原因在于如果两个网络波特率不同收到帧的节奏跟目标网络的发送节奏不一致立刻转发会导致目标总线负载出现锯齿状抖动甚至造成低优先级报文被饿死。7. 常见问题与排查技巧实录7.1 总线上全是错误帧该怎么下手遇到错误帧暴增我第一件事不是改代码而是先看错误帧的错误类型。CAN错误帧在分析仪上通常会被标记成错误帧或者给出具体的错误码。你要分辨是CRC错误、位错误、填充错误还是应答错误。CRC错误多半出现在总线干扰或者某节点时钟漂移严重的时候位错误通常跟某个节点超距发送、又将总线拉低有关填充错误说明发送端和接收端的位填充规则不一致这常常发生在CAN-FD速率切换点附近应答错误一般说明总线上没有节点正确接收这个帧——要么是一个孤立节点在自说自话要么是终端电阻缺失导致接收端无法正常采样。我在排障时还会做一件事把总线上的节点逐个摘除或者逐个上电观察错误帧数量是否随之消失。这个方法虽然笨但对于哪个节点是问题源的判断极其有效。先完全断开所有节点用总线分析仪挂上总线发送测试报文如果没有任何节点应答错误帧就只剩应答错误然后一个个把节点接回总线看哪个节点一接上错误类型就变化问题节点就被锁定了。7.2 同一套代码在这块板子上正常、在那块板子上乱跳这种问题十有八九出在晶振或时钟精度上。CAN总线对位时间的容忍度非常高但对两个节点的时钟相对误差很敏感。如果两个节点的系统时钟来源一个是陶瓷谐振器、一个是高精度晶振或者一个用了外设分频器、一个用了PLL锁相环它们的位时间误差可能正好叠加导致采样点错位。还有一个常被忽略的因素收发器供电电压。不同节点如果供的是不同电压轨比如一个12V、一个5V转换速率不同的收发器会在总线边沿产生不同的延迟在高速率下就可能超出相位缓冲区的容忍范围。遇到同代码不同表现不要急着重新编译先用示波器对比两块板子上总线的波形的上升沿和下降沿看边沿位置差是否超过了1个TQ。如果超了优先检查时钟源和收发器供电是否一致。7.3 CAN-FD报文长数据段传得飞快但偶尔丢包CAN-FD的64字节报文虽然带宽效率高但丢包的概率也随帧长增加而上升。原因是数据段越长遭受干扰的位窗口越多一旦某一位被翻转CRC校验失败整帧作废。应对策略有两个方向一是在应用层做帧计数和超时重传把可靠性交给上层适合非安全关键的载荷传输二是把大块数据切成多帧并使用序列号标识类似传输层的分片重组协议。我个人做OTA刷写时习惯把固件镜像按64字节分块每块带一个16位的块序号和一个16位的CRC。接收端收到一个块后先校验CRC正确则写入临时区错误则直接丢弃并记录缺失块列表等全部发完后接收端会发送缺失块列表给发送端发送端只重传丢失的块。这个机制比TCP轻量得多但在CAN-FD上表现稳定。CAN/CAN-FD常见问题速查表现象可能原因排查方向总线完全无波形终端电阻缺失/短路、收发器供电异常、TX/RX接反万用表测差分电压示波器看CAN_H/CAN_L错误帧周期性出现某节点的时钟漂移、总线负载、报文ID冲突抓错误类型逐个断电排查高速率数据段误码率高收发器带宽不够、支线过长、连接器寄生电容大降速对比测试检查换用CAN-FD收发器滤波器不起作用中断频繁滤波器被后续初始化覆盖、掩码配置错误回读滤波器寄存器逐ID验证同一节点时而正常时而掉线电缆屏蔽层接地不良、接触电阻漂移、端子氧化重做线束端接测量总线上每个节点的电压范围CAN-FD帧被老节点当错误帧总线混用经典CAN与CAN-FD节点隔离老节点或改用网关做协议转换低优先级报文长时间无法发出总线负载率过高、高优先级报文触发过于密集降低周期或改用CAN-FD提高单帧信息量7.4 排查工具不光是分析仪示波器也得会看市面上CAN总线分析仪种类很多但很多人只会用隐性和显性的界面真出了问题又不知道怎么看波形。我的建议是把分析仪和示波器同时挂到总线上。用分析仪看协议层用示波器看物理层。分析仪能告诉你哪帧出错了但物理层问题的根源只能靠波形找。尤其当你怀疑边沿太缓、幅值不足、过冲振铃时示波器的单次触发抓取SOF上升沿并且测量上升时间、差分电压幅值、振铃幅度这些数据比任何协议层的统计都更有说服力。在干扰排查中还可以利用示波器的FFT功能。如果总线波形叠加了某个频率的噪声FFT能看到噪声频点这时再去看是电机换向脉冲、DC-DC开关频率还是线束天线的耦合路径。靠感觉排查电磁兼容问题效率太低让数据和波形替你说话。8. 写在从沙子到车辙第4.3章之后的一点心得做CAN/CAN-FD的项目做得多了我越来越觉得这个总线协议的经典之处不在于它有多快、多高级而在于它在三十年前就定义了怎么用最少的资源实现车规级的多点可靠通信。很多新总线协议想取代CAN但CAN用一套极其优雅的线与仲裁错误自愈机制硬抗了无数恶劣工况直到今天依然是汽车电子里当之无愧的骨干网络。我个人的一个体会是如果你能把CAN的物理层、数据链路层和应用层的设计逻辑打通再去看其他任何总线无论是LIN、FlexRay还是车载以太网你的理解深度都会不一样。因为CAN教会你的不是某一个具体协议而是一套在约束条件下做取舍的思维方式实时性优先容忍开销确定性优先牺牲灵活性可靠性优先杜绝单点故障。这套思维放在任何嵌入式控制系统里都是通用的。最后再分享一个小技巧在做新项目的CAN/CAN-FD网络规划时别急着写代码先在纸面上把报文矩阵、周期、负载率、ID优先级、拓扑和节点收发器型号列一张表然后逐项推敲。这个习惯帮我避开了无数个本来以为很简单实际联调时炸出一堆问题的坑。希望这篇文章也能帮你少踩几条。