
简介面向汽车电子 AUTOSAR 开发者的实操型 PDF 教程聚焦 EB Tresos 与 SystemDesk 协同工作中的高频环节如何把 SystemDesk 新生成的 .arxml 系统描述文件正确导入 EB Tresos 工程并完成 DBC 更新、ECU Extract 创建与 BSWM 描述更新等后续配置动作适合已具备基础 ECU 配置经验、需要打通工具链衔接的在职工程师与项目新人参阅。压缩包内仅含 1 个 PDF 文件体积约 674KB篇幅精炼、随查随用正文覆盖启动 tresos_gui.exe、导入 workspace 工程、在 Project Explorer 中打开 ECU 配置、替换同名 arxml、在 Im- and Exporters 对话框中运行 SysDes 与 DBC 导入器、创建 ECU Extract、更新服务组件与 BSWM 描述以及编译生成代码等环节均标注了对话框名称与操作位置并给出无错误时点击 OK、有错误时查看 Error Log 的判定方法。已有 3535 人学习下载对需要在多个工具间切换的 AUTOSAR 项目而言这份文档能减少因文件替换或导入器设置不当造成的返工。1. 先别急着点导入这份 PDF 解决的是一次 arxml 替换与配置刷新手里拿到一份 SystemDesk 新生成的 arxml很多人第一反应是直接拖进 EB Tresos 工程结果导入器读到的还是旧模型编译时服务组件对不上。这个 PDF 记录的是另一条路径在 EB_Tresos 工程里先替换 system 目录下的同名 arxml再通过 SysDes Importer、DBC Importer、EcuExtractCreator 和 SwdUpdater_Trigger 把 AUTOSAR 配置逐层刷新最后生成代码。它适合已经能打开工程、但不确定导入顺序和检查点的 ECU 配置工程师新手可以照步骤走熟手重点看目录落点和 Error Log 的判读。下面按工程结构、替换导入、后段动作链和避坑顺序拆开。2. 工程目录与 arxml 落点先认清 system 目录、ECU 配置和导入器的关系2.1 EB Tresos 工程里哪些文件会被 SystemDesk 覆盖这套流程的核心不是“导入一个文件”而是让 EB Tresos 重新认识一份系统描述。SystemDesk 生成的是***.arxml它最终要落到workspace\***_Project\system目录下并且文件名要和工程里原有的那个 arxml 保持一致。很多人翻车不是因为导入器不会用而是替换时改了文件名或者把文件放到了另一个同名工程的 system 目录里。EB 的 SysDes Importer 按System\*.arxml这种通配符去抓输入文件通配符不认你的意图只认路径和文件名。先把几个固定落点记住后面每一步都能对上号。下面的表不是让你背目录而是替换前逐项核对尤其是***_Project这种占位符实际工程里要换成真实目录名。位置内容替换前检查什么bin\tresos_gui.exeEB Tresos 启动程序确认启动的是当前工程所在的 workspace不是旧版本快捷方式workspace\***_Project\system\***.arxmlSystemDesk 生成的系统描述文件文件名是否与工程原文件同名时间戳是否为新生成Project Explorer根文件夹工程导入导出入口右键菜单里是否有Im- and ExportersECU(TRICORE,TC23XL)ECU 配置节点节点名是否与当前芯片型号、工程配置一致Error Log导入和代码生成错误日志弹窗说无错误时也要看这里的第一条记录ECU(TRICORE,TC23XL)里的 TRICORE 是内核架构TC23XL 是芯片系列不同工程节点名可能不同。节点名对不上时不要硬套按实际工程的 ECU 节点走但导入器读取 system 目录下 arxml 的逻辑是一样的。常见做法是先把 Project Explorer 展开确认 system 目录下只有一个目标 arxml避免通配符一次匹配到旧文件和新文件两个输入。2.2 为什么用 SysDes Importer 而不是手工改 arxmlarxml 不是普通 XML里面短名、引用路径、服务接口、ECU 资源约束彼此牵连。手工改一个信号名看起来只是改文本导入器解析时可能报引用找不到更麻烦的是有些错误不会在保存时暴露等到 EcuExtractCreator 或 SwdUpdater_Trigger 阶段才冒出来。SysDes Importer 的价值在于按模型解析系统描述把 SystemDesk 的变更转成 EB Tresos 工程能识别的配置并在ImporterRun Finished里集中抛错误。它不保证你的模型一定对但至少把“文件替换”变成了“配置刷新”。选型理由也在这里如果只是查字段用文本编辑器打开 arxml 看短名没问题如果是正式更新主流程应该走 SysDes Importer。手工改适合定位问题不适合作为交付路径。尤其在通信矩阵、服务组件、BSWM 描述一起变化时手工改很容易留下半新半旧的配置后面生成代码时 Error Log 会像黑匣子一样只给你一个缺失引用。血泪经验是能回退的替换才叫替换不能回退的手工改叫赌博。导入器也不是万能的。它读的是当前工程 system 目录下的输入文件替换错位置它不会提醒你“你放错了工程”。所以第 3 章会先让你确认路径再点 Run Importer。另一个常见误用是替换后不备份原 arxml导入失败时想回退只能从版本库重新拉工程。备份这件事不复杂但它是后面所有排错动作的后悔药。2.3 替换前的备份、命名与版本对齐检查替换前先做工程级备份再做文件级备份。工程级备份是整个***_Project目录复制一份文件级备份是只复制 system 目录下的目标 arxml。工程级备份占空间但回退干净文件级备份快适合只换一个文件的小步更新。我一般会两个都做工程目录复制到同级的备份目录目标 arxml 再加时间戳后缀。这样导入器报错时先恢复文件级备份重跑如果配置树已经被改乱再回退工程级备份。命名上只有一个原则新生成的 arxml 替换后必须和原文件同名。不要为了区分版本改成***_new.arxml或***_v2.arxml否则System\*.arxml可能匹配不到或者匹配到多个文件让导入器选择困难。版本对齐要检查三件事SystemDesk 导出时选的 AUTOSAR 版本与 EB 工程配置是否匹配导出的 ECU 是否就是当前ECU(TRICORE,TC23XL)节点对应的 ECUDBC 文件是否和 arxml 来自同一版通信矩阵。三件事里任何一件对不上后面都可能以 warning 或 error 的形式出现。提示替换前把整个工程目录复制一份回退时比逐文件恢复省事。路径也要注意。工程放在中文目录、带空格的长路径下某些导入器弹窗检测文件时容易出玄学问题。不是绝对不能用而是排错时多一个变量。常见做法是把 workspace 放在短路径、纯英文目录下至少保证 system 目录路径里没有空格。替换时关闭正在占用 arxml 的文本编辑器、对比工具和另一个 EB 实例避免文件被锁住后导入器读到旧缓存。3. 从替换到 SysDes Importer十三条步骤里的前九步怎么走稳3.1 启动、导入工程与打开 ECU(TRICORE,TC23XL) 配置第一步是启动。到工程bin文件夹下找到tresos_gui.exe双击打开。这里不要图省事用桌面快捷方式尤其当机器上装过多个版本或多个 workspace 时快捷方式可能指到另一个工作空间。启动后先看窗口标题或 workspace 路径确认当前打开的是workspace\***_Project所在的那一层。导入工程时在 workspace 文件夹下选中需要修改的工程导入不要在导入过程里勾选覆盖原工程除非你已经在第 2 章做好了完整备份。工程导入后在Project Explorer中双击ECU(TRICORE,TC23XL)让 ECU 配置信息加载出来。这个动作相当于告诉 EB Tresos接下来要改的是这个 ECU 的配置不是旁边另一个节点。双击后先别急着操作导入器花半分钟看配置树是否正常展开ECU 名称、芯片系列、工程引用有没有明显异常。如果这里已经报错先解决工程打开问题不要带着错误往下跑否则后面ImporterRun Finished报的错可能只是前面问题的余波。这一步的检查点很朴素Project Explorer 里能看到工程根文件夹能看到ECU(TRICORE,TC23XL)节点双击后配置界面能正常显示。看不到节点时先确认导入的是不是完整工程而不是只复制了 system 目录。工程目录不完整时SysDes Importer 可能仍能打开但导入后会缺配置容器错误信息反而更难读。3.2 替换 system 目录下的同名 arxml路径、命名与占用检查第三步做完回到电脑工程路径workspace\***_Project\system找到同名的***.arxml文件用 SystemDesk 新生成的文件替换它。替换时保持文件名一致不要改扩展名不要在新文件旁边再留一个旧文件。替换完用文件管理器看一眼时间戳和大小确认新文件确实覆盖成功。下面这段命令只是把“看路径、看文件、做备份”三个动作固定下来避免在错误目录里操作。# 先确认当前工程 system 目录避免在另一个 workspace 里做替换 cd /workspace/***_Project/system ls -l *.arxml # 备份原文件时间戳后缀方便回退 cp ***.arxml ***.arxml.bak_$(date %Y%m%d_%H%M%S)这段命令的逻辑是先进入实际工程的 system 目录再用ls -l看 arxml 的时间戳和大小最后用cp给原文件加时间戳后缀备份。参数上***_Project和***.arxml都是占位符要换成真实目录名和文件名路径里有空格时引号不能省date %Y%m%d_%H%M%S生成备份后缀方便按时间回退。备份完成后再把 SystemDesk 新生成的文件复制进来覆盖顺序不要反。替换后不要用文本编辑器“顺手改两个字段”。这一步的边界是文件级替换字段级修改应该回 SystemDesk 改模型再重新导出。替换完回到 EB 配置界面如果 Project Explorer 没有自动刷新手动刷新一下根文件夹。然后右键根文件夹在弹出的下拉菜单里单击Im- and Exporters进入导入导出对话框。此时先不要点任何 Run下一步是确认输入文件选择。3.3 跑 SysDes ImporterAll Models、System*.arxml 与 Edit 对话框Im- and Exporters打开后会弹出Creat, manage and run im- and exporters对话框原文拼写就是 Creat界面上看到同名窗口就对了。在对话框右侧选择SysDes(System Description Importer)然后鼠标左击All Models表单依次单击System\*.arxml和Edit按钮。这里的All Models是模型选择区System\*.arxml是输入文件通配符*代表 system 目录下任意文件名。Edit不是编辑 arxml 内容而是编辑输入文件选择让你确认导入器到底要读哪个文件。点开Edit后会弹出Edit input file selection, Supports variables and filename wildc对话框界面会自动检测当前描述文件。这个自动检测结果要重点看路径是不是当前工程的system目录文件名是不是刚替换的那个检测到的是不是一个文件而不是一串旧文件。确认无误后单击OK回到导入导出对话框。如果这里检测到旧路径说明 EB 启动的 workspace 或工程根目录不对先退出去核对不要硬点 Run Importer。确认输入文件后单击Run Importer开始更新描述文件。更新完毕会弹出ImporterRun Finished对话框并提示错误信息没有错误就单击OK关闭有错误就先别关把错误详情和 Error Log 里的第一条记录一起看。常见错误包括文件解析失败、引用找不到、ECU 型号不匹配。处理顺序是先看错误指向的文件和节点再决定是恢复备份重来还是回 SystemDesk 修模型重新导出。不要连续重复点 Run Importer重复导入可能让配置树出现重复条目后面更难判断。动作界面/参数检查点选择导入器SysDes(System Description Importer)右侧列表选中后下方输入选择区可用选择模型All Models表单能看到System\*.arxml条目编辑输入Edit按钮弹出输入文件选择对话框确认文件自动检测结果路径指向当前工程 system 目录只匹配目标 arxml执行导入Run ImporterImporterRun Finished无错误Error Log 无新增红色记录完成这一步系统描述文件才算真正被 EB Tresos 读进工程。接下来不是马上生成代码而是继续跑 DBC Importer、EcuExtractCreator 和 SwdUpdater_Trigger。很多人在这里看到弹窗无错误就以为结束结果 Generate code 时才发现通信或服务组件没更新。导入链是有顺序的SysDes 只是第一环。4. DBC 导入、ECU Extract 与 SWC/BSWM 更新后四步的动作链4.1 DBC Importer 不是可选装饰通信矩阵变化时先跑它SysDes Importer 完成后回到Creat, manage and run im- and exporters对话框在右侧选择dbc (DBC Importer)单击Run Importer开始更新。更新完毕会弹出Warnings During Importer Run对话框没有错误就单击OK关闭最后关闭整个导入导出窗口。这里要注意DBC Importer 的弹窗名字叫 Warnings不叫 Finished所以它天然可能带警告。警告不是让你练心态的通信信号缺失、节点名不一致、报文重复这类问题都会在这里露头。DBC 和 arxml 的关系可以这样理解arxml 描述系统架构和服务接口DBC 描述 CAN 通信矩阵。SystemDesk 更新了系统描述后如果通信矩阵也跟着变了DBC 文件必须同步更新如果只改了应用层 SWCDBC 可能没有变化但按流程跑一遍能确认没有新增 warning。常见误用是只替换 arxml、不更新 DBC结果 SysDes 导入成功通信相关配置却还是旧矩阵Generate code 后编译能过但信号对不上。通信相关工程里这一步不要省。DBC Importer 之前要确认 DBC 文件路径和版本。工程里通常有固定的 DBC 输入位置或者导入器配置里指向某个 DBC 文件如果 SystemDesk 导出的通信矩阵换了文件名DBC Importer 可能仍读旧文件。警告要逐条记录不要只看最后一句“无错误”。有些警告是历史遗留有些是新替换引入的区分方法是看警告里的节点名、报文名是否落在这次变更范围内。落在变更范围内的警告不要带进 Generate code。4.2 EcuExtractCreator 与 SwdUpdater_Trigger 的先后关系DBC 导入关闭窗口后在工具栏中找到Run all unattended wizards marked with a *下拉选择create an ECU Extract(EcuExtractCreator)弹出Results对话框说明 arxml 文件更新完成。EcuExtractCreator 的作用是从系统描述里抽取当前 ECU 相关的部分生成 ECU Extract供后续配置和代码生成使用。它不是“再导一次 arxml”而是把系统级描述收敛到当前 ECU 的边界内。SysDes Importer 成功但 EcuExtractCreator 失败通常说明系统描述里有当前 ECU 不支持的引用或资源冲突。EcuExtractCreator 成功后继续在同一个工具栏菜单下选择Update Service Component and BSWM Descriptions(SwdUpdater_Trigger)弹出Code Generater Run Finished和Results对话框单击OK依次关闭。这一步更新服务组件和 BSWM 描述依赖上一步 ECU Extract 的结果。顺序不能反先 Extract 再 SwdUpdater因为 SwdUpdater 要基于抽取后的 ECU 视图更新服务组件和 BSWM。反过来跑可能读到旧的 Extract 结果弹窗看似成功实际配置没变。这两步的失败后果不一样。EcuExtractCreator 失败后面的 SwdUpdater 不要硬跑硬跑只会把错误往后传SwdUpdater_Trigger 失败Generate code 也不要继续因为服务组件描述没更新生成出来的代码可能缺接口。Error Log 里如果有错误先看第一条不要从最后一条往前猜。第一条通常指向根因后面的错误可能是连锁反应。表格里把动作链和依赖关系列清楚排错时按顺序回退。顺序动作依赖失败后的处理1SysDes Importersystem 目录下目标 arxml恢复备份核对文件路径和版本2DBC Importer通信矩阵 DBC 文件记录 warning核对 DBC 版本和节点名3EcuExtractCreatorSysDes 导入结果不跳过先修系统描述引用4SwdUpdater_TriggerECU Extract 结果回看 Extract 的 Results再决定是否重跑5Generate code前四步成功且 Error Log 干净先 Save All再生成最后看编译输出4.3 Generate code 之前看 Error Log而不是只看弹窗前四步完成后单击小锤子Generate code for the currently selected projects按钮编译工程更新工程文件。Generate code 是基于最新配置生成代码不是“点一下碰运气”。生成前先执行 Save All把配置保存到工程文件生成前再看一眼 Error Log如果前面 SwdUpdater 已经留下错误这里生成只会把错误带进代码目录。生成后不要只看弹窗是否关闭要看编译输出和生成目录时间戳。常见误区是弹窗点了 OK 就认为成功。Code Generater Run Finished和Results只是向导执行结果Error Log 才是汇总入口。Error Log 里如果有红色错误先处理第一条如果是 warning要判断是否在本次变更范围内。生成代码后对应模块的生成文件时间戳应该更新如果没有更新说明生成范围或工程选择不对。此时不要手工去改生成目录里的文件下一次生成会覆盖正确做法是回配置层修。Generate code 之后如果编译报错优先怀疑三件事SwdUpdater 没跑成功、DBC 和 arxml 版本不一致、生成前没有保存配置。排错顺序是回看 Error Log 第一条、检查 EcuExtract 的 Results、确认 SysDes Importer 的输入文件路径。不要一上来就清理整个工程目录配置目录和生成目录要分开看。只清理生成输出目录是常规操作动配置目录之前必须有备份。5. 避坑与排查五条现场记录按现象、原因、解决拆开5.1 现象ImporterRun Finished 报错但工程树没变化现象是点完Run Importer后弹出ImporterRun Finished里面有错误信息但 Project Explorer 看起来和之前一样配置树没有明显变化。原因通常有三类替换的 arxml 与当前工程版本或 ECU 型号不匹配文件被其他程序占用导致导入器读到旧内容或者System\*.arxml通配符匹配到了多个文件导入器不知道以哪个为准。工程树没变化不代表导入没执行可能是执行到一半失败回滚了。解决时先看 Error Log 第一条不要从弹窗最后一行开始读。第一条如果指向解析失败回 SystemDesk 确认导出设置如果指向引用找不到检查替换的文件是不是当前 ECU 的系统描述如果指向文件占用关闭文本编辑器、对比工具和另一个 EB 实例恢复备份后重跑。通配符匹配多个文件时system 目录下只保留目标 arxml 和备份文件备份文件不要用.arxml后缀避免被通配符抓进去。还有一个容易忽略的点备份文件如果命名为***_bak.arxml它仍然会被System\*.arxml匹配。正确做法是备份成.bak或放到 system 目录外面。这个坑不复杂但翻车时很浪费时间因为导入器不会告诉你“你多了一个备份文件”。5.2 现象替换 arxml 后 SysDes Importer 仍读到旧模型现象是明明已经替换了 system 目录下的 arxmlEdit input file selection对话框里检测到的还是旧文件或者导入后配置还是旧信号。原因常见于三种替换到了另一个同名工程的 system 目录EB 启动的 workspace 不是当前工程所在 workspaceEdit对话框里保留的是旧路径自动检测没有刷新。尤其机器上有多份***_Project时路径长得几乎一样只看文件名很容易看错。解决时在Edit对话框里看绝对路径不要只看文件名。路径里应该出现当前 workspace 和当前工程目录。然后确认tresos_gui.exe启动的是哪个 workspace窗口标题或最近工程列表能看出来。Project Explorer 可以手动刷新但刷新只影响显示不会改变导入器输入路径。输入路径错了刷新多少次都没用。如果路径确认无误但导入结果仍是旧模型检查是否同时开了两个 EB 实例。两个实例可能各自持有工程缓存后启动的实例不一定读到前一个实例替换后的文件。关闭多余实例保留一个重新打开工程再跑 SysDes Importer。这个场景下不要连续点 Run Importer重复导入会让配置树出现重复条目后面更难判断哪条是新的。5.3 现象DBC Importer 报 Warnings通信信号对不上现象是Warnings During Importer Run里出现信号缺失、报文重复或节点名不一致Generate code 后通信信号和预期对不上。原因通常是 DBC 与 arxml 不是同一版通信矩阵或者 DBC 文件路径仍指向旧文件或者 SystemDesk 导出时节点名变了但 DBC 没同步。DBC Importer 的 warning 有时候不影响编译但会影响通信配置不能因为弹窗能关掉就忽略。解决时先把 warning 逐条抄出来按节点名、报文名、信号名分类。落在本次变更范围内的 warning 必须处理历史遗留 warning 可以记录后再继续。然后核对 DBC 文件路径和版本确认它和 arxml 来自同一轮通信矩阵更新。如果只改应用层DBC 没变化warning 仍是旧问题可以在记录后继续但不要把“旧 warning”当成“这次没问题”的证据。通信信号对不上还有一类原因是 DBC Importer 跑在 SysDes Importer 之前。这个顺序错了DBC 可能基于旧系统描述更新后面 SysDes 再改一次通信配置就错位了。按流程走SysDes 先DBC 后EcuExtract 再后。顺序不是形式是依赖关系。5.4 现象EcuExtractCreator 成功但 SwdUpdater_Trigger 失败现象是create an ECU Extract(EcuExtractCreator)弹出Results看起来成功紧接着Update Service Component and BSWM Descriptions(SwdUpdater_Trigger)报错。原因可能是 ECU Extract 没有真正更新Results 里存在被忽略的条目也可能是系统描述里服务组件引用缺失或者 BSWM 描述与 Extract 结果不匹配。EcuExtract 成功只代表抽取动作完成不代表抽取结果一定完整。解决时先回看 EcuExtract 的Results不要只看弹窗标题。然后看 Error Log 第一条定位缺失引用指向哪个服务组件或哪个 BSWM 描述。如果是引用缺失回 SystemDesk 修模型重新导出 arxml再从头跑 SysDes Importer不要跳过 Extract 直接重跑 SwdUpdater那样只会重复报错。如果 Extract 结果为空检查当前 ECU 是否选对ECU(TRICORE,TC23XL)节点是否与 SystemDesk 导出的 ECU 一致。还有一种情况是 SwdUpdater 失败后工程里留下了半更新状态。此时不要直接 Generate code先恢复备份重跑导入链或者至少从 SysDes Importer 开始重跑一遍。半更新状态下的代码生成Error Log 可能指向不存在的服务组件排错成本更高。5.5 现象Generate code 后编译报错Error Log 指向不存在的服务组件现象是小锤子生成代码后编译报错Error Log 指向某个服务组件不存在或接口不匹配。原因通常是 SwdUpdater_Trigger 没跑成功或者生成前没有 Save All或者旧生成物残留导致编译器读到旧接口。还有一种原因是 SysDes Importer 导入成功后DBC Importer 的 warning 被忽略通信相关服务组件没有按新矩阵更新。解决时先确认 SwdUpdater 的Results没有错误再执行 Save All然后重新 Generate code。Error Log 看第一条不要从最后一条往前猜。如果第一条指向服务组件缺失回看 EcuExtract 结果和 SysDes 输入文件如果指向接口不匹配核对 DBC 和 arxml 版本。旧生成物残留时只清理工程生成输出目录不要动配置目录清理前先确认目录用途拿不准就整工程备份后再操作。这类错误最容易让人误以为是编译器问题实际根因在导入链。导入链每一步都有弹窗但弹窗只告诉你动作完成没完成不告诉你配置是否一致。Error Log 和 Results 才是判断依据。把这条记住后面增量更新会省很多时间。6. 验证导入结果三个检查点和一个增量更新习惯6.1 用 ECU Extract 和 Error Log 做交叉验证导入链跑完后不要只凭弹窗判断成功。我一般做三个检查点Project Explorer 里 ECU 配置节点下能看到本次变更相关的系统描述或服务组件更新Error Log 没有新增红色错误warning 能对应到已知历史问题生成代码目录里对应模块的时间戳确实更新。三个检查点里Error Log 和 ECU Extract 的Results要交叉看一个说没错误一个说抽取结果完整才算比较稳。检查点看什么通过标准ECU 配置树本次变更的 SWC、服务组件、BSWM 描述能看到新增或更新条目没有重复条目Error Log第一条错误和本次新增 warning无红色错误warning 有记录和解释生成目录对应模块文件时间戳本次 Generate code 后确实更新ECU Extract Results抽取结果是否为空、是否有缺失引用结果完整缺失引用已处理验证时不要只看一个弹窗。ImporterRun Finished、Warnings During Importer Run、Results、Code Generater Run Finished是四个不同阶段的反馈任何一个阶段有异常都要在进入下一阶段前处理。尤其是 warning如果它落在本次变更范围内不要带进 Generate code。6.2 增量更新时先锁版本再替换文件增量更新最怕三样东西同时变arxml、DBC、工程配置。一次只动一个变量跑完导入链、验证通过再动下一个。替换前把 SystemDesk 导出配置、EB 工程、DBC 文件版本记在一个文本里时间戳和文件名都写上。下次出问题至少知道回退到哪一版。这个习惯看起来笨但比在 Error Log 里猜要快。替换文件时保持同名备份文件不要用.arxml后缀避免被System\*.arxml匹配。跑完 SysDes Importer 后先看Edit对话框里的检测路径再跑 DBC ImporterEcuExtractCreator 成功后再跑 SwdUpdater_Trigger最后 Save All 再 Generate code。这条顺序不要图快跳过跳过哪一步后面就用 Error Log 补课。从那以后我每次替换 arxml 前都先把工程复制一份、把路径念一遍再点 Run Importer弹窗说无错误也只当参考最终以 Error Log 和 ECU Extract 的结果为准。这份 PDF 的原始步骤截图和检查表我放在资料包里按目录取用先对着第 5 章排一遍再决定要不要在你的工程上动手。希望帮到你。本文还有配套的精品资源点击获取