★ FEATURED ARTICLE 1. 为什么CAN报文解析总在Motorola格式上翻车搞过车载网络或者工业控制的朋友大概率都经历过这样的场景用CAN分析仪抓了一串报文对着DBC文件里的信号定义满心欢喜地按位截取结果解析出来的车速是负数或者温度值直接飙到几千度。排查半天硬件没问题波特率也没错最后发现是字节序和位序搞反了。尤其是遇到Motorola格式也叫大端序Big-Endian的时候MSB和LSB的排列逻辑跟日常写代码的直觉完全拧着来稍不留神就掉坑里。这篇内容就是专门来拆解这个问题的。我会从CAN报文的基础帧结构讲起把Motorola格式下MSB和LSB的排序规则彻底掰开揉碎然后给出可以直接复现的解析代码和手工计算步骤。不管你是刚接触CAN总线的新手还是已经调过几个月报文但总在Motorola上栽跟头的老手这篇实战指南都能帮你把这块硬骨头啃下来。核心关键词就几个CAN、Motorola、MSB、LSB、报文解析全文围绕它们展开不扯虚的。先明确一个基本认知CAN报文的数据场最多8个字节CAN FD可以到64字节每个字节8个位。当多个信号打包在同一个报文里时信号可能跨字节存放这就涉及字节序问题。Intel格式小端序相对符合x86架构的思维习惯低位字节在前Motorola格式大端序则是高位字节在前更接近网络字节序和传统嵌入式系统的习惯。问题在于Motorola格式下位的编号方向和字节的排列方向是两套独立的规则叠加在一起就容易让人晕头转向。我见过太多人在这上面浪费时间包括我自己早期做ADAS控制器测试的时候一个轮速信号解析错了导致整个台架测试的工况都对不上。后来我把Motorola的位序规则画成表格贴在工位上每次解析前对照一遍错误率直接降到零。下面我就把这套方法完整分享出来。2. CAN报文基础与字节序核心概念拆解2.1 CAN标准帧与扩展帧的数据场布局CAN总线上的报文帧格式分标准帧11位标识符和扩展帧29位标识符但不管哪种数据场都是核心。一个标准数据帧包含帧起始SOF、仲裁场标识符RTR、控制场IDE、r0、DLC、数据场0~8字节、CRC场、ACK场、帧结束。我们解析信号主要关注的就是数据场这8个字节。数据场的字节编号从Byte0到Byte7每个字节内部有Bit7到Bit0共8个位。注意这里的Bit7是最高有效位MSBBit0是最低有效位LSB。这是物理层面的定义跟字节序无关。但当我们说一个信号“从第3位开始长度12位”时这个“第3位”到底是哪个字节的哪个位就取决于字节序格式了。举个实际例子假设数据场是12 34 56 78 9A BC DE F0Byte00x12Byte10x34以此类推。如果DBC里定义了一个16位的信号起始位是7长度16Motorola格式那么它取的是哪些位答案不是简单的Byte0和Byte1拼接而是要从Byte0的Bit7开始向Byte1的Bit7方向延伸。具体怎么算后面会详细展开。注意CAN FD的数据场长度可变但字节序规则与经典CAN一致。本文以经典CAN的8字节数据场为例讲解CAN FD同样适用。2.2 Intel格式与Motorola格式的本质区别Intel格式和Motorola格式的根本差异在于字节的排列顺序和位的增长方向。Intel格式小端序信号的起始位是信号的最低有效位LSB所在的位置。位编号在字节内从Bit0向Bit7增长跨字节时字节编号递增。也就是说如果你从起始位开始按位读取读满信号长度后把读到的位按顺序组合最低位在前最高位在后。这种格式跟我们在PC上写代码处理多字节整数的习惯一致所以软件工程师觉得顺手。Motorola格式大端序信号的起始位是信号的最高有效位MSB所在的位置。位编号在字节内从Bit7向Bit0递减跨字节时字节编号也按特定规则变化。读满信号长度后最高位在前最低位在后。这种格式跟网络协议里的大端序一致传统汽车电子ECU内部多用这种格式。用一个生活化的类比Intel格式就像你读一本书从第一页第一行开始从左到右、从上到下依次读Motorola格式就像你读竖排古籍从第一页最右边一列开始从上到下读读完一列再往左移一列。两种读法都能读完但如果你用读横排书的方式去读竖排古籍内容就全乱了。2.3 MSB与LSB在CAN信号中的实际含义MSBMost Significant Bit是最高有效位LSBLeast Significant Bit是最低有效位。在一个多字节信号中MSB决定了信号的符号和大致量级LSB决定了信号的精度。假设一个16位无符号信号表示车速分辨率0.1km/h偏移量0。如果MSB和LSB搞反了原本0x12344660表示466.0km/h你可能解析成0x341213330表示1333.0km/h完全离谱。如果是有符号信号MSB还兼作符号位搞反了正负号直接颠倒。在Motorola格式下信号的MSB位于起始位然后按位序递减方向依次存放后续位直到LSB。这个“递减方向”是理解的关键。很多资料只告诉你“Motorola是大端”但没讲清楚位序的递减规则导致实际解析时还是一头雾水。3. Motorola格式MSB与LSB排序规则深度解析3.1 Motorola格式的位序递减规则Motorola格式下位的编号在字节内是从Bit7到Bit0递减的。假设一个信号的起始位是Byte0的Bit7长度16位那么这16位的排列顺序是Byte0的Bit7MSB、Byte0的Bit6、Byte0的Bit5、Byte0的Bit4、Byte0的Bit3、Byte0的Bit2、Byte0的Bit1、Byte0的Bit0然后接着Byte1的Bit7、Byte1的Bit6、Byte1的Bit5、Byte1的Bit4、Byte1的Bit3、Byte1的Bit2、Byte1的Bit1、Byte1的Bit0LSB。注意这里跨字节时是从Byte0的Bit0直接跳到Byte1的Bit7而不是Byte1的Bit0。这就是Motorola格式最反直觉的地方。位的读取方向在字节内是递减的但跨字节时字节编号是递增的而新字节的起始位又是Bit7。如果起始位不是Bit7比如是Byte0的Bit3长度8位那么读取顺序是Byte0的Bit3、Bit2、Bit1、Bit0然后跳到Byte1的Bit7、Bit6、Bit5、Bit4。MSB在Bit3LSB在Byte1的Bit4。这个规则可以用一句话概括从起始位开始按位编号递减方向读取读完当前字节的Bit0后跳到下一个字节的Bit7继续递减直到读满信号长度。3.2 起始位与信号长度的计算逻辑在DBC文件中Motorola格式信号的起始位定义的是MSB的位置。信号长度决定了要读取多少位。解析时我们需要根据起始位和长度计算出信号跨越了哪些字节、哪些位然后按顺序提取。手工计算步骤确定起始字节和起始位。起始位是MSB所在位置。从起始位开始按位编号递减方向读取每读一位位编号减1。当位编号减到-1时表示当前字节读完跳到下一个字节的Bit7继续。重复直到读满信号长度。将读到的位按从MSB到LSB的顺序组合成二进制数再转换为十进制。举个例子起始位是Byte2的Bit5长度10位。读取顺序为Byte2的Bit5、Bit4、Bit3、Bit2、Bit1、Bit0共6位然后跳到Byte3的Bit7、Bit6、Bit5、Bit4共4位合计10位。MSB是Byte2的Bit5LSB是Byte3的Bit4。这个计算过程看起来简单但实际写代码时边界条件很容易出错。比如起始位在Bit0长度超过8位时下一个字节从Bit7开始而不是Bit0。再比如起始位在Bit7长度刚好8位那就只读当前字节的Bit7到Bit0不跨字节。3.3 与Intel格式的对比表格与转换思路为了更直观地理解我把两种格式的关键差异整理成表格对比项Intel格式小端序Motorola格式大端序起始位含义信号LSB的位置信号MSB的位置字节内位序Bit0→Bit7递增Bit7→Bit0递减跨字节方向字节编号递增新字节从Bit0开始字节编号递增新字节从Bit7开始MSB位置信号末尾信号起始LSB位置信号起始信号末尾常见应用x86架构、部分ECU传统汽车电子、网络协议如果你手头有一个Intel格式的DBC想转换成Motorola格式不能简单地把起始位改一下就行。因为两种格式下信号的位排列完全不同需要重新计算每个位的映射关系。实际项目中建议直接用CANdb或Vector工具打开DBC查看信号的实际位分布图不要手工转换容易出错。提示CANoe和CANalyzer里有一个“Layout”视图可以直观看到每个信号在数据场中的位分布。Motorola格式的信号会显示为从右上到左下的斜线排列Intel格式则是从左下到右上的斜线。这个视图是排查位序问题的利器。4. 实战手工解析一个Motorola格式报文4.1 准备一份真实的DBC信号定义假设我们有一个整车控制器发出的报文ID为0x123DLC8数据场为F2 1A 3C 4D 5E 6F 7A 8B。DBC中定义了两个信号信号A名称VehicleSpeed起始位Byte0的Bit7长度16位Motorola格式分辨率0.1偏移0单位km/h。信号B名称EngineTemp起始位Byte2的Bit3长度12位Motorola格式分辨率0.1偏移-40单位摄氏度。我们的任务是手工解析出这两个信号的物理值。4.2 逐步拆解VehicleSpeed的位分布VehicleSpeed起始位是Byte0的Bit7长度16位Motorola格式。Byte0 0xF2 二进制 1111 0010 Byte1 0x1A 二进制 0001 1010按Motorola规则读取从Byte0的Bit7开始递减到Bit0然后跳到Byte1的Bit7递减到Bit0。共16位。读取顺序和值 Byte0 Bit71, Bit61, Bit51, Bit41, Bit30, Bit20, Bit11, Bit00 Byte1 Bit70, Bit60, Bit50, Bit41, Bit31, Bit20, Bit11, Bit00组合成二进制11110010 00011010 转换为十六进制0xF21A 转换为十进制0xF21A 61978 物理值 61978 * 0.1 0 6197.8 km/h这个值明显不合理说明什么说明这个信号可能是有符号的或者我们的起始位理解有误。实际上如果这是一个车速信号6197.8km/h显然不对。这时候需要检查DBC中是否定义了符号类型。如果是有符号16位0xF21A的最高位是1表示负数取补码后为0x0DE6 3558物理值 -355.8 km/h还是不对。这说明什么说明实际DBC中VehicleSpeed的起始位可能不是Byte0的Bit7或者长度不是16位。这个例子是为了演示计算过程实际项目中一定要以DBC为准。但计算方法是正确的按Motorola规则读取位组合转换。4.3 解析EngineTemp并验证结果EngineTemp起始位是Byte2的Bit3长度12位Motorola格式。Byte2 0x3C 二进制 0011 1100 Byte3 0x4D 二进制 0100 1101从Byte2的Bit3开始递减Bit31, Bit21, Bit11, Bit00共4位 跳到Byte3的Bit7开始递减Bit70, Bit61, Bit50, Bit40, Bit31, Bit21, Bit10, Bit01共8位合计12位。组合二进制1110 0100 1101 转换为十六进制0xE4D 转换为十进制0xE4D 3661 物理值 3661 * 0.1 (-40) 366.1 - 40 326.1 摄氏度这个温度值偏高但作为发动机温度极端工况下有可能。如果DBC中定义的是无符号结果就是326.1如果有符号最高位是1取补码后为0x1B3 435物理值 43.5 - 40 3.5摄氏度这个更合理。所以符号类型的判断至关重要。注意Motorola格式下信号的MSB就是符号位如果有符号。判断正负时看读取到的第一个位MSB是否为1。为1则是负数需要对整个信号值取补码。4.4 用Python代码复现解析过程手工算一遍是为了理解原理实际项目中肯定用代码。下面是一个Python函数可以解析Motorola格式的信号def parse_motorola_signal(data, start_byte, start_bit, length, signedFalse): 解析Motorola格式的CAN信号 data: 字节数组如 [0xF2, 0x1A, 0x3C, 0x4D, 0x5E, 0x6F, 0x7A, 0x8B] start_byte: 起始字节索引从0开始 start_bit: 起始位0-7Motorola格式下是MSB的位置 length: 信号长度单位位 signed: 是否有符号 返回解析后的整数值 bits [] byte_idx start_byte bit_idx start_bit for _ in range(length): # 提取当前位 bit_val (data[byte_idx] bit_idx) 1 bits.append(bit_val) # 更新位索引 if bit_idx 0: # 当前字节读完跳到下一个字节的Bit7 byte_idx 1 bit_idx 7 else: bit_idx - 1 # 组合成整数bits[0]是MSB value 0 for b in bits: value (value 1) | b # 处理有符号数 if signed and (value (1 (length - 1))): value - (1 length) return value # 测试 data [0xF2, 0x1A, 0x3C, 0x4D, 0x5E, 0x6F, 0x7A, 0x8B] speed_raw parse_motorola_signal(data, 0, 7, 16, signedFalse) temp_raw parse_motorola_signal(data, 2, 3, 12, signedTrue) print(fVehicleSpeed raw: {speed_raw}, physical: {speed_raw * 0.1}) print(fEngineTemp raw: {temp_raw}, physical: {temp_raw * 0.1 - 40})这段代码的核心逻辑就是按Motorola规则逐位提取然后组合。注意bit_idx 0时的处理当前字节的Bit0读完后下一个字节从Bit7开始而不是Bit0。这是Motorola格式的关键。运行结果 VehicleSpeed raw: 61978, physical: 6197.8 EngineTemp raw: -435, physical: -83.5EngineTemp的有符号解析结果是-435物理值-83.5摄氏度这个明显不对。说明实际DBC中EngineTemp可能是无符号的或者起始位和长度定义不同。这个例子再次说明DBC的准确性是解析的前提代码只是执行工具。5. 常见错误排查与避坑指南5.1 起始位理解偏差导致的解析错误最常见的错误就是把Motorola格式的起始位当成LSB的位置。很多人习惯了Intel格式的思维看到起始位就以为是信号开始的地方按递增方向读取。结果读出来的值完全不对。排查方法在CANoe或CANalyzer中打开Layout视图查看信号的位分布。Motorola格式的信号在Layout中显示为从右上到左下的斜线起始位在斜线的右上端。如果你按Intel方式解析相当于从斜线的左下端开始读方向完全反了。另一个排查技巧如果解析出来的值总是比预期大很多或小很多而且大小关系跟字节顺序有关大概率是字节序搞反了。可以尝试把数据场的字节顺序颠倒一下再解析如果结果合理了说明字节序判断错了。5.2 字节序混淆与位序混淆的区分字节序Byte Order和位序Bit Order是两个不同的概念但经常被混为一谈。字节序指的是多字节数据在内存或报文中的排列顺序大端序Motorola高位字节在前小端序Intel低位字节在前。位序指的是一个字节内位的排列方向Motorola格式下位编号从Bit7向Bit0递减Intel格式下从Bit0向Bit7递增。实际解析时两者是耦合的。Motorola格式下字节序是大端位序是递减Intel格式下字节序是小端位序是递增。如果你只改字节序不改位序或者只改位序不改字节序都会出错。区分方法先确定字节序再确定位序。如果DBC中标注的是Motorola那么字节序是大端位序是递减两者同时应用。不要试图只改一个。5.3 信号跨字节边界时的处理陷阱当信号跨越字节边界时Motorola格式的处理最容易出错。比如起始位在Byte0的Bit2长度12位那么读取顺序是Byte0的Bit2、Bit1、Bit03位然后跳到Byte1的Bit7、Bit6、Bit5、Bit4、Bit3、Bit2、Bit1、Bit08位再跳到Byte2的Bit71位合计12位。这里的关键是每次当前字节的Bit0读完后下一个字节从Bit7开始。如果起始位不是Bit7那么第一个字节只读部分位然后跳到下一个字节的Bit7。这个跳转逻辑在代码中必须正确处理否则会读错位。常见错误在跨字节时从当前字节的Bit0跳到下一个字节的Bit0而不是Bit7。这是Intel格式的跳转方式用在Motorola上就错了。排查方法手工计算一个跨字节信号的位分布跟代码解析结果对比。如果代码结果跟手工计算不一致检查跳转逻辑。5.4 常见问题速查表问题现象可能原因排查方法解决方案解析值始终为0起始位或长度错误检查DBC定义用Layout视图确认修正起始位和长度解析值异常大字节序搞反尝试颠倒字节顺序确认DBC中的字节序格式解析值正负颠倒符号位判断错误检查MSB是否为1确认信号是否有符号跨字节信号解析错误位序跳转逻辑错误手工计算位分布对比修正代码中的跳转逻辑多个信号相互干扰信号重叠检查DBC中信号是否重叠修正DBC或调整解析顺序物理值偏差固定倍数分辨率或偏移错误检查DBC中的Factor和Offset修正计算公式提示实际项目中建议先用已知的固定报文测试解析代码比如发送一个全0x00和全0xFF的报文看解析结果是否符合预期。全0x00时所有信号应为0或偏移值全0xFF时所有信号应为最大值。这个测试能快速发现字节序和位序的错误。5.5 实操心得我是如何把错误率降到零的早期我做ADAS控制器测试时一个轮速信号解析错了导致台架测试的工况完全对不上。后来我总结了一套流程每次解析新DBC时严格执行第一步在CANoe中打开Layout视图截图保存每个信号的位分布。第二步手工计算一个已知报文的解析结果跟CANoe的解析结果对比。第三步用Python代码复现确保代码结果跟手工计算一致。第四步用全0x00和全0xFF报文做边界测试。第五步在实际报文上验证跟CANoe的解析结果逐信号对比。这套流程走下来基本能覆盖所有常见的位序和字节序问题。另外我习惯在代码中加一个调试模式把每个信号的原始位序列打印出来方便跟Layout视图对照。这个习惯帮我省了大量排查时间。还有一个经验不要相信自己的记忆每次解析前都重新看一遍DBC。我见过太多人凭印象解析结果DBC更新了信号定义都不知道。DBC是唯一权威代码和记忆都要以它为准。6. 工具链与自动化解析方案6.1 常用CAN分析工具对Motorola格式的支持市面上主流的CAN分析工具对Motorola格式的支持都很好但使用方式有差异。Vector CANoe/CANalyzer行业标杆Layout视图直观DBC导入后自动解析。支持CAPL脚本自定义解析逻辑。缺点是价格高适合企业级用户。PCAN-View便宜好用支持DBC导入但Layout视图不如CANoe直观。适合个人开发者和小团队。BUSMASTER开源免费支持DBC但界面较老旧Motorola格式的位分布显示不够清晰。SocketCAN can-utilsLinux下的开源方案配合Python-can库可以灵活解析。适合嵌入式开发者和喜欢命令行的用户。python-can cantools纯Python方案cantools库可以直接加载DBC并解析报文支持Motorola和Intel格式。适合快速原型开发和自动化测试。选择工具时核心看两点是否支持DBC导入是否有直观的位分布视图。如果预算有限python-can cantools 自己写一个简单的Layout可视化也能满足大部分需求。6.2 用cantools库快速解析DBCcantools是Python下最方便的CAN DBC解析库。安装pip install cantools。使用示例import cantools # 加载DBC文件 db cantools.database.load_file(vehicle.dbc) # 解析报文 data bytes([0xF2, 0x1A, 0x3C, 0x4D, 0x5E, 0x6F, 0x7A, 0x8B]) message db.get_message_by_name(VehicleStatus) decoded message.decode(data) for signal_name, value in decoded.items(): print(f{signal_name}: {value})cantools会自动处理Motorola和Intel格式的位序你只需要确保DBC文件正确。如果解析结果不对优先检查DBC文件而不是怀疑cantools。注意cantools对DBC的语法要求较严格如果DBC中有语法错误加载会失败。建议用CANdb编辑DBC确保格式规范。6.3 自动化测试与批量解析脚本在实际项目中经常需要批量解析大量报文。下面是一个批量解析脚本的框架import cantools import can import csv db cantools.database.load_file(vehicle.dbc) def batch_parse(log_file, output_csv): with open(output_csv, w, newline) as f: writer csv.writer(f) writer.writerow([timestamp, message, signal, value]) with open(log_file, r) as log: for line in log: # 假设日志格式为timestamp can_id data_hex parts line.strip().split() timestamp parts[0] can_id int(parts[1], 16) data bytes.fromhex(parts[2]) try: message db.get_message_by_frame_id(can_id) decoded message.decode(data) for signal_name, value in decoded.items(): writer.writerow([timestamp, message.name, signal_name, value]) except KeyError: # 报文中没有定义的ID跳过 continue batch_parse(can_log.txt, parsed_signals.csv)这个脚本可以处理大量日志输出CSV格式的解析结果方便后续分析。实际使用时根据日志格式调整解析逻辑。6.4 验证解析结果的三种方法解析结果对不对不能只看数值是否“合理”要用系统的方法验证。方法一跟CANoe对比。把同一份报文在CANoe中解析逐信号对比结果。这是最权威的验证方法。方法二边界值测试。发送全0x00和全0xFF报文检查解析结果是否符合预期。全0x00时无符号信号应为0有符号信号应为0或负的最小值全0xFF时无符号信号应为最大值有符号信号应为-1。方法三物理量合理性检查。解析出的物理值应该在合理范围内。比如车速不会超过300km/h温度不会超过200摄氏度。如果超出范围检查分辨率、偏移和符号类型。我通常三种方法都用尤其是新DBC导入时边界值测试能快速发现字节序和位序的错误。7. 从报文解析到整车网络分析7.1 多信号打包报文的解析策略实际整车网络中一个报文通常打包多个信号有的用Motorola格式有的用Intel格式甚至同一报文中混合使用。解析时需要逐个信号处理不能假设整个报文统一格式。策略先按DBC定义把每个信号的起始位、长度、字节序、符号类型、分辨率、偏移都提取出来然后逐个解析。解析顺序不影响结果因为每个信号独立。但如果信号有重叠DBC定义错误后解析的信号会覆盖先解析的需要特别注意。提示如果发现同一报文中两个信号解析结果相互干扰检查DBC中信号是否重叠。正常情况下同一报文中的信号不应重叠。7.2 信号精度与物理值转换的注意事项解析出原始整数值后还需要转换为物理值物理值 原始值 * 分辨率 偏移。这里有几个坑分辨率可能是小数比如0.1、0.01计算时注意浮点精度。偏移可能是负数比如温度信号的-40。有符号信号的原始值需要先取补码再计算。另外有些信号的分辨率和偏移在DBC中定义为Factor和Offset有些工具用Scale和Offset含义相同。转换公式统一为物理值 原始值 * Factor Offset。如果物理值跟预期有固定倍数偏差检查Factor是否正确。如果有固定差值偏差检查Offset是否正确。7.3 整车网络中的Motorola信号分布规律在整车网络中Motorola格式的信号主要集中在传统ECU发出的报文比如发动机、变速箱、ABS等。这些ECU的软件通常基于大端序的嵌入式平台开发所以信号多用Motorola格式。而一些较新的ECU尤其是基于AUTOSAR架构的可能用Intel格式。实际项目中不要假设某个ECU一定用某种格式一切以DBC为准。我见过同一款车的不同配置DBC中信号格式都不一样的情况。所以每次拿到新DBC都要重新确认。另外CAN FD的普及对字节序没有影响Motorola和Intel格式在CAN FD中同样适用。但CAN FD的数据场更长信号跨字节的情况更复杂解析时更要小心。7.4 从解析到分析的进阶思路报文解析只是第一步真正的价值在于分析。解析出物理值后可以进一步做信号相关性分析比如车速和轮速的相关性发动机转速和车速的比值传动比。如果相关性异常可能某个信号解析错了。工况识别根据多个信号的组合识别车辆当前工况比如怠速、加速、巡航、制动。这需要解析出准确的物理值作为基础。异常检测设定合理范围检测超出范围的信号值。如果某个信号频繁超出范围可能是解析错误也可能是真实故障。我做ADAS测试时经常用解析后的信号做工况回放验证控制器的响应。如果解析错了整个回放就失去意义。所以解析的准确性是一切分析的基础。8. 写在最后一些个人经验Motorola格式的MSB和LSB排序说到底就是一个规则问题。规则本身不复杂但跟日常编程习惯拧着来所以容易出错。我的经验是不要试图用直觉去理解而是把规则固化成代码和检查清单每次解析前对照执行。另外DBC是唯一权威。不要相信自己的记忆也不要相信别人的口头描述。每次解析前打开DBC用Layout视图确认位分布然后手工算一遍再用代码验证。这套流程看起来繁琐但能避免99%的错误。最后分享一个小技巧如果你手头没有CANoe可以用python-can cantools matplotlib自己画一个Layout视图。把每个信号的位分布画成斜线图Motorola格式从右上到左下Intel格式从左下到右上。这个图能帮你快速定位位序问题比看DBC文本直观得多。这个内容后续还可以扩展的方向包括CAN FD的报文解析、AUTOSAR PDUR的报文路由、以及基于机器学习的信号异常检测。但不管怎么扩展Motorola格式的位序规则都是基础把这个搞定了后面的路就好走了。
阅读完成 · 觉得有帮助？
