开头引导手里攒了不少面试必问的素材这是第三篇。上一篇聊完整体岗位画像这一篇直接上硬货——把汽车电子软件开发岗最常考的UDS诊断、OTA升级、CAN通信等 7 大模块一次性理清楚。不管你是准备校招、社招还是想系统梳理一遍自己的知识体系这篇文章都适合。我按面试官实际追问的深度来组织内容不讲虚的每一节都有“考点拆解—回答框架—追问应对—踩坑提醒”四个层次。你在面试前花一个周末过一遍这份清单效果基本等同于把同行五年的经验浓缩后灌进脑子里。强调一句面试官问技术细节不是为了考倒你而是想确认你有没有真正做过项目、踩过坑。所以这篇文章里所有内容我都按“项目里真的会碰到”的标准来写不是教科书式的名词堆砌。你背书能过一面但二面三面一定会有场景题那才是拉开差距的地方。1. 整体设计与模块拆解思路1.1 为什么是这 7 个模块车载软件开发岗位的 JD 上经常列着一堆关键词熟悉CAN通信、了解诊断协议、做过OTA、熟悉AUTOSAR、有功能安全经验……名字都认识但面试官真正想问什么很多人其实没厘清。我把常见的追问点做了归类最后落成这 7 个模块CAN通信与网络管理、UDS诊断协议、诊断测试功能与DTC、OTA升级与刷新流程、引导加载程序与信息安全、通信栈与AUTOSAR配置、刷写流程中的崩溃恢复与鲁棒性设计。这个划分不是随便拍的。它几乎覆盖了车载软件从底层通信到上层业务的完整链路CAN管数据怎么传网络管理管节点何时睡何时醒UDS管数据怎么被问出来DTC管故障怎么记录引导加载程序管刷写是怎么启动的OTA管远程怎么把新版本安全地送进控制器AUTOSAR配置管这些逻辑在下位机上怎么落地成代码。面试官不关心你会背多少名词他关心的是你知不知道这条链路每一环的职责边界。回答“整车架构中诊断和刷写的关系”这类开放题时你能把7个模块串成一张图讲出来面试官心里基本就给过了。1.2 面试官评判候选人的三个层次根据我这些年带人和被面的经验面试官对候选人的评估基本分三个层次第一个层次是“知道名词”——能说出UDS是ISO 14229CAN是ISO 11898但一追问细节就卡壳。这个层次只能勉强过电话面试。第二个层次是“懂原理”——能画出发送UDS请求到收到响应的完整时序图能解释为什么诊断仪要先进入扩展会话才能执行写操作能说清CAN波特率如何计算和验证。这个层次已经能过专业面。第三个层次是“有项目手感”——能说出刷写过程中如果突然断电自己的设计能不能保证控制器变砖的风险可控能讲清A/B分区方案对比单分区方案在OTA场景下的胜负手能指出诊断仪发负响应时自己如何根据NRC码反查软件逻辑缺陷。这篇文章的目标就是帮你从第二层次往第三层次走。每一章我都会故意把面试官的追问点列出来那些问题你答顺了面试状态基本就稳了。2. CAN通信与网络管理最基础也最容易翻车2.1 面试官最爱问的3个CAN问题第一个问题是“CAN报文是怎么发出去的”。这个问题看似简单但能完整答出来的人不多。标准回答框架应用层把信号映射到报文Signal与PDU的映射关系经过PDU路由到硬件发送邮箱控制器按优先级仲裁仲裁获胜后把SOF、仲裁段、控制段、数据段、CRC段、ACK段、EOF依次发到总线上接收方硬件过滤后存入接收邮箱软件通过中断或轮询把数据取走。面试官如果追问“如果你连续发两帧报文会怎样”你要能答出发送缓存机制——第二帧要么进队列排队要么直接丢帧取决于你用了几级缓存。末尾会附送一个加分的理解只要总线忙任何节点都得等总线空闲才能发。这个就是“多主”架构的现实约束很多人把它理解成“大家随便发”这是错的。第二个问题是“波特率怎么算”。这个问题规矩地问法是CAN时钟频率、预分频、位时间三段的计算公式是什么采样点为什么要放在60%~80%借用需求规范里的约束这个区间是行业惯例。你不仅要会算还要能解释为什么采样点靠前有利于抗干扰——因为CAN是电平采样采样点越靠后离信号边沿越远抗毛刺能力越强但延迟也越大。面试官真正想确认的是你有没有亲自配过寄存器还是只是复制过别人的初始化代码。答的时候可以补一句“我在项目里一般把采样点配在75%~80%波特率500Kbps总线负载控制在30%以下这是行业经验值多数OEM的线束和节点参数都按这个规格标定。”这一句话就展示了项目感和行业认知。第三个问题是“报文周期怎么设计”。直接照抄设计方案即可动力域的转矩、转速这类信号周期短10ms~20ms车身域的灯光、车窗这类信号周期长100ms~1000ms诊断报文只在有请求时发网络管理报文按唤醒/睡眠状态决定是否发。如果面试官追问“Why”你要答出负载率约束和实时性需求的平衡。我见过很多候选人在开放题上只会背“一般10ms、100ms”说不出为什么这样分级这样就缺少真正的系统观。2.2 网络管理节点睡不睡、谁能先说话网络管理是很多自认为会CAN的人最容易忽略的考点。它管的事很简单一条总线上多个ECU钥匙下电之后要不要全部立刻睡眠谁有权先发一帧报文把大家都叫醒。面试官常问三连BoolMaster接口和NM报文的关系是什么应用层的Sleep/Wake请求最终要映射到网络管理节点NM报文由网络管理状态机来控制发送。直接网络管理和间接网络管理的区别直接型靠专门的NM报文交互间接型靠应用报文来隐含表达活动状态——AUTOSAR的CanSM/CanNm就偏直接型OSEK直接网络管理更偏纯状态机模型。如果总线长时间无活动节点多久才能进睡眠这个问题没有统一答案但你必须讲清楚你会怎么定这个超时参数——通常是OEM的技术规范直接给出一般来说几十毫秒到几百毫秒之间目的是留够让所有节点完成挂起业务的时间。实操演练面试官给你一个场景钥匙下电后主节点要求所有节点在200ms内完成睡眠否则会产生静态电流超标问题。你的回答框架应该是“下电后主节点停止发送NM报文其他节点通过NM超时判断总线进入prepared sleep状态等待应用层业务结束后主动发最后一帧NM唤醒报文来declare自己准备睡眠然后进入sleep模式。”这里关键词是超时判断、状态迁跃、静态电流、主动宣告。2.3 面试高频追问表我整理了一个速查表面试前过一遍会很有底。面试官不一定会按顺序问但大概率绕不开这里面的内容。考点高频变体回答主干传输机制显性电平怎么被隐性电平覆盖多节点同时发送时显性位覆盖隐性位仲裁获胜者继续发送错误处理节点发现错误怎么处理错误计数器ECR逐级累计主动错误、被动错误、总线关闭三种状态唤醒机制报文唤醒和硬线唤醒有什么区别报文唤醒是总线上出现有效电平跳变硬线唤醒是KL15或IO信号翻转负载率负载率超标会怎样仲裁延迟上升低优先级报文可能发不出去甚至触发DLC错误发送周期为什么有的报文只在状态变化时发送事件型报文可以减少总线负载但接收方要配合超时监控逻辑这些细节能顺口答出来面试官对你的印象分就会拉满因为大多数候选人只能说到“知道”的层面。3. UDS诊断协议服务、会话、寻址一个都不能少3.1 UDS到底是什么和CAN啥关系UDSUnified Diagnostic Services是ISO 14229定义的一套应用层诊断协议底层可以跑在CAN、CAN FD、LIN甚至以太网上。这个“底层可换”的特性很多人没嚼透面试官喜欢拿它出题。在CAN上跑UDS时每个诊断请求/响应都装载在CAN帧的数据场里但协议栈还要处理CAN帧分片——因为UDS报文可能超过8个字节CAN FD是64字节以太网更大。这就是传输层和网络层的活。ISO 14229只定义了应用层的服务和数据格式ISO 15765DoCAN负责定义如何在CAN帧上传输UDS报文。面试官问你“UDS和CAN的关系”你如果能主动提到ISO 15765-2的4字节协议头帧类型、目标地址、源地址、扩展寻址信息面试官就会觉得你是真的看过协议文本的人。3.2 必背的10个诊断服务不是所有服务都等权重。面试考来考去就那几个我按“必须闭眼能写出来”和“了解功能即可”分个类。必须能默写出来的10个服务按功能归类会话控制10Diagnostic Session Control数据读取22Read Data By Identifier、19Read DTC Information数据写入2EWrite Data By Identifier、2FInput Output Control By Identifier例行程序31Routine Control刷写相关34Request Download、36Transfer Data、37Request Transfer Exit安全解锁27Security Access电控单元复位11ECU Reset每个服务必须能说清三个维度请求报文格式SID子功能DID、正响应格式SID40响应SID比如22读数据的正响应是62、负响应带NRC7FSIDNRC。面试官随便挑一个服务你都能按这个框架秒回答诊断这块的基本功就算过关了。3.3 会话管理为什么不能一上来就刷写UDS规定ECU里面有多个诊断会话默认、编程、扩展等。默认会话下很多写操作、刷写操作是被禁止的必须切到扩展或编程会话才能执行。这就是一层安全边界车载设备在正常行驶状态下绝不希望被诊断仪误操作写坏数据。面试官常见的进阶追问是“三分钟没收到诊断请求ECU会不会卡在编程会话”正确回答会话超时机制P2Server/P2*Server会触发会话返回默认但编程会话Programming Session比较特殊很多实现里它没有默认会话超时而是刷写引导加载程序退出时才跳回。这种细节只有真的调过诊断栈的人才能答出来。能主动提到P2Server/P2*Server以及S3Server超时定时器的贝叶斯计算方式10服务请求时带上SessionAndMethod可以指定超时参数直接加分。原因这是ISO 14229-1里特别容易踩的细节大多数教程不会讲。3.4 功能寻址和物理寻址别搞混诊断请求可以发给特定ECU物理寻址也可以发给总线上所有ECU功能寻址。两者不能在同一个请求里混用。功能寻址常见于刷写前的“整车进入编程模式”广播物理寻址是单点操作。实际项目中OEM会为每个ECU分配一组物理请求ID和功能请求ID响应ID是各自的。面试官如果让你画出诊断仪与ECU的通信逻辑你能把ID分配表列出来几乎就是标准答案。4. OTA升级从刷写流程到A/B分区方案4.1 整车OTA和传统刷写的本质区别传统刷写是诊断仪连到OBD口通过标定工具一个控制器一个控制器地刷OTA把这条路搬到了远程——云平台先把升级包推送到车端网关或中央计算单元再由车端触发诊断刷写流程。这个区别带来两个核心挑战升级包传输的安全性和刷写中断的恢复能力。传统刷写坏了可以重新连上诊断仪再刷一次OTA刷一半断网、断电、用户锁车走人了控制器要是因此变砖车就开不走了。面试官会问“如果是你怎么设计OTA方案来避免刷坏”这两个方向答出来基本就有分一是软件设计上做A/B分区备份和回滚机制二是整车上电策略上保证关键控制器刷写时有稳定的供电条件比如由网关确保低压蓄电池电量足够、高压系统不上高压电只依赖低压供电。4.2 A/B分区方案为什么它是OTA的保险栓A/B分区方案核心思想存储里准备两个独立的软件槽位A槽是当前运行版本B槽是备用版本。升级时把新版本写入B槽validate通过后切换启动标志下次启动从B槽启动如果启动失败或自检不通过回滚到A槽。面试追问会集中在三个点A/B槽切换的原子性怎么保证有专门标志位记录当前活动槽写入新槽位后是否需要交叉验证要不要CRC校验整个固件镜像两个槽位谁负责记录“当前启动次数”一般由一个独立的启动计数器记录每次启动1应用正常运行后清零。如果计数器连续几次都没被清零引导程序判定当前槽位有问题触发回滚。A/B方案的代价是什么Flash占用翻倍。在Flash容量受限的MCU上这代价是很昂贵的所以很多量产项目用双分区备份加差分升级的方式降低成本。能回答到这一层面试官基本就会认定你有真实OTA项目经验了。4.3 OTA升级包和差分包为什么只传差异OTA升级包不是每次都要传整个固件镜像。很多量产方案采用差分升级云端对比新旧版本算出差异块delta车端下载delta后在新槽位基于旧版本合成新镜像。好处是下载量小、更省流量、升级更快代价是合成过程需要校验完整性和做版本依赖判断不能跳版本。面试官在这个点上常问“如果你把升级包下载完了但ECU刷写发现版本不匹配怎么办”你该答先做版本检查比如校验Version和兼容性表不匹配就拒绝继续并上报云端内核镜像还有签名校验防止非法包写入。这些都是刷写流程里的常规把关点答上了就是“我有安全意识”。4.4 与热词关联OTA延迟升级与logo.bin处理细节这里要特别提一下强化备份在方案中的运用。我曾在一款信息娱乐控制器方案里做OTA升级包由多个分区镜像组成包含主系统、恢复系统和开机logo对应某些厂商方案里的logo.bin。细节是这样logo分区虽然小但一旦写坏开机画面卡死用户第一反应不是升级失败而是“车机坏了”——这种观感比功能故障更影响口碑。我在设计脚本时把logo.bin与主系统镜像放在同一个事务里做全量校验和事务性提交不允许单独重试这样就把“小的容易出大事”的组件也纳入一致性保障里了。顺带说一句OTA延迟升级delay update的机制很多项目也有。它指的是升级包下载完成后不立刻执行刷写而是等用户停车、锁车、整车处于安全空闲状态后再触发。这不是产品经理拍脑袋想出来的而是工程上为了避免行驶中刷写影响整车安全性能。面试官如果问“OTA什么时候可以做”答出“整车处于安全静止状态且电源条件满足且用户已同意”才完整还需识别网络延迟的方案确保在休眠前刷写完毕。4.5 刷写流程的崩溃恢复设计面试最硬核的问题是这个刷写中间断电ECU怎么保证自己不砖一个可靠的刷写流程至少要有以下环节引导加载程序Bootloader支持刷写时随时可中断断电后重新上电Bootloader发现应用区标志无效就停留在Boot模式等待重新刷写。如果Bootloader自身也是可更新的就需要独立的、不可被普通刷写流程覆盖的恢复区。真正的细节在于刷写过程中Flash的擦写顺序和标志状态机不能想当然地安排一定要把“所有标志先置为无效再逐块擦写最后全量校验通过再置为有效”作为标准流程。这个先后顺序一旦搞反就会出现刷写一半断电、重启后Bootloader觉得应用区有效然后跳进损坏代码的局面。这就是项目经验面试官问“你能不能说下刷写时序”时隐隐点出这里就够了。5. 引导加载程序与信息安全把好最后一道关5.1 Bootloader的工作流程Bootloader是控制器上电后最早执行的程序它的职责是硬件初始化、检查应用区标志、校验应用固件的完整性和签名如果都通过跳转到应用区如果有异常执行刷写流程或直接停留在Boot模式。面试官常从两个角度提问为什么Bootloader必须独立于应用因为应用可能崩溃、被误刷Bootloader不能被应用影响必须常驻在受保护的区域。Bootloader和应用的交互怎么设计有两种思路一是Bootloader里实现完整的诊断服务和Flash驱动应用只需要调用跳转指令二是Bootloader简化到只负责“带校验的跳转”刷写逻辑放应用层但应用层已经不能正常启动时就会陷入死局。所以量产方案多采用思路一的变体——Bootloader保留基本的UDS刷写服务这样即使应用区废了也能靠Bootloader救回来。5.2 安全启动链现代车载MCU基本都要求安全启动从Bootloader到应用每一级都要做签名校验。私钥在云端和产线公钥固死在芯片的信任根里不同的升级包用对应的私钥签名。面试官常问“如果攻击者把公钥替换成自己的怎么办”正确回答公钥通常放在一次性可编程区域或芯片安全存储里普通刷写流程根本无法触及。如果你的项目里用了Secure Boot和HSM硬件安全模块能画出从Boot ROM到应用的安全链基本就是面试里的高光时刻。5.3 密钥管理和防回滚安全模块另一个重要考点是防回滚攻击者拿到旧版本固件利用已知漏洞刷回去重新作恶。所以刷写流程里必须有版本回滚保护——要么在Bootloader里比较版本号要么用安全计数器限制只能升不能降。这个知识点很容易被忽略。面试官如果拿“你有信息安全经验吗”这种开放题聊你能主动提到防回滚和密钥管理会在众多候选人中一眼出挑。6. 通信栈与AUTOSAR配置从原理到落地的关键6.1 CanIf、CanTp、PduR三层关系不少非AUTOSAR项目也会用类似分层结构只是没有套AUTOSAR的名字。AUTOSAR通信栈从底到顶CanDriver硬件驱动→ CanIf接口层→ CanTp传输层负责ISO 15765分片→ PduRPDU路由层→ 上层模块如Dcm诊断管理。每一层职责单一层与层之间通过PDU ID做路由。面试官常问“UDS报文经过哪些模块才能到应用层”你要能画出来CanIf收到CAN帧 → 根据PDU ID识别是诊断报文 → 转CanTp做重组 → 完整报文交给PduR → 路由给Dcm → Dcm做UDS解析 → 调用应用层服务。这里每一跳的缓冲区和协议接口都有配置问题面试官如果让你设计一个扩展诊断会话下的读数据流程你能把这个链路讲清楚说明你真做过协议栈。6.2 Dcm模块和会话超时到底是谁在管AUTOSAR里会话超时是Dcm的S3Server定时器在管。如果你说自己用过AUTOSAR协议栈面试官一定会问你“Dcm里两类定时器是什么”——P2Server负责响应超时请求发出去多帧没回就要报超时S3Server负责会话超时这么久没有后续请求会话要退出。距离答案更近的表达是P2Server对应ECU处理诊断请求的时间上限超过它就得发负响应或等待S3Server对应两次诊断请求之间的最大间隔超了就默认回退。能主动提到这两个定时器的配置位置和默认值并且补充“当多帧传输时P2*Server会延长”你的AUTOSAR基础就立住了。6.3 CDD、DEXT和诊断配置的日常面试官有时会拿着OEM的CDD文件问你怎么配。CDD诊断数据字典是诊断配置的核心输入DEXT是协议栈供应商的工具负责把CDD导入生成Dcm、Dem、NvM的配置代码。你需要能回答CDD里哪些内容会影响代码生成——DID列表、DTC列表、会话映射、安全等级。实际操作中OEM的CDD格式可能不太规整你往往要手工补一点配置。能讲出“我在项目里遇到过OEM CDD里DID重复手工调整配置表的优先级”这种细节面试官就知道你不是纸上谈兵。7. 实测演练一套完整的刷写场景我这样答7.1 场景题拆解假设面试官给你一个场景整车OTA下发新版本到T-BoxT-Box要通过CAN把固件刷到IVI车载信息娱乐系统的MCU里。目标MCU只有一个Bootloader保护没有A/B分区。请问你会怎么做我的完整回答框架第一步T-Box先通过功能寻址广播进入编程会话10 03让IVI的Bootloader进入可刷写状态。第二步物理寻址为IVI发送27 01请求种子Bootloader根据种子算密钥返回完成安全解锁。第三步34 01指定下载地址和总字节数Bootloader根据剩余Flash空间判断是否允许下载返回块长度建议。第四步通过36循环发送数据块每个块的大小受CAN传输层MTU限制一般是4096字节或更小带序号校验。第五步全部数据传完后发37Bootloader对镜像做完整性校验和签名校验。第六步发11 01复位应用启动时还会做一次自校验。面试官紧接着一定会问“没有A/B分区万一刷写途中断了怎么办”我的回答“Bootloader里要设计以下保障Flash擦写顺序为先置应用区无效标志再擦写写完后没有立即设置有效标志而是做完整校验校验通过后才置有效此时才会跳转应用。如果途中断电Bootloader启动时发现有效标志失败就停留在Boot模式等待重刷。另外Bootloader本身要区分应用区与Boot区禁止刷写流程覆盖Boot区域。”这一条回答已经打败90%的候选人了。7.2 防止翻车现场写一个简单诊断流程面试中很多岗位会当场让你写一段伪代码。常见的是实现一个UDS读数据服务处理函数。虽然每个岗位代码语言不同但思路一致。我用C语言的pseudocode风格给你一套模板// 伪代码UDS 22服务处理 static uint8_t handle_22(const uint8_t *request, uint8_t req_len, uint8_t *response, uint8_t *resp_len) { uint16_t did (request[1] 8) | request[2]; if (req_len 3) { return NRC_INVALID_LENGTH; // 0x13 } if (!is_session_supported(CURRENT_SESSION, 0x22)) { return NRC_SERVICE_NOT_SUPPORTED; // 0x11 } if (!is_did_valid(did)) { return NRC_REQUEST_OUT_OF_RANGE; // 0x31 } response[0] 0x62; response[1] request[1]; response[2] request[2]; uint16_t data_len get_did_data(did, response[3]); *resp_len 3 data_len; return NRC_POSITIVE; // 0x00 }注意这里三段判断顺序长度→会话→DID有效性。实际项目里顺序会影响NRC报哪个面试官让你提“你能想到哪些负响应码”时你随口说出0x11、0x12、0x13、0x22、0x31、0x33等并且能说清各自触发条件就很有说服力。7.3 OTA升级脚本工程细节再给一个实际工程脚本的小例子描述即可不用全代码升级包下载完要解压、校验、合并差分。我在项目里用Python脚本做先是遍历差分块清单计算每个块的CRC和整体镜像的签名校验通过后用脚本通过CAN/UDS接口模拟刷写时序。脚本的关键点不是刷写本身而是日志和断点恢复——每次36传输结束后记录已经完成的块序号中断后从断点续传而不是从头再刷。这个“断点续传”和“日志排查”的细节面试官问到“如果刷写失败你怎么定位”时用得上。8. 常见问题与排查技巧实录8.1 实测排查诊断请求发出去没有响应怎么查这是工作中最高频的问题。我的排查顺序固定如下:第一步看物理层示波器抓CAN波形确认有报文且电平正常排除总线短路和终端电阻缺失。第二步看链路层CANoe Trace里能不能看到诊断报文ID发出来ID是否符合OEM规范。第三步看传输层如果报文是多帧看Flow Control有没有正确响应CTSContinue To Send是否被对方正确解析。第四步看应用层请求SID对不对参数长度对不对子功能在当前会话是否可用。第五步查软件代码逻辑Dcm是否把请求路由到了正确的处理模块。这套排查逻辑不仅面试要用实际工作中也要靠它救命。面试官问你“怎么Debug”你能把这五级链路说出来说明你具备系统性解决问题的能力。8.2 高频Bug清单现象常见根因处置要点诊断请求无响应对方处于默认会话且服务被禁止先切扩展会话再发请求响应时序超时多帧传输里P2*Server计时没配好拉长首帧后的等待超时刷写一半失败传输块过大导致缓冲区溢出按MTU分块每块加序号校验OTA下载失败差分块版本匹配检查失败先校验版本号再合并27服务解锁总是失败种子算法用错确认产线烧录的密钥与算法路径一致8.3 根治问题的思路光是会背Bug清单还不行面试官喜欢问“为什么会出现这类问题你怎么防止再犯”。比如你说“刷写一半失败”就要能继续讲我会在代码里加一个刷写状态机每个阶段有明确的状态迁移条件任何异常都落日志方便事后分析。这个思路比“我失败了就重刷一次”要高级得多。我在实际项目中踩过最大的坑是没有把“擦除Flash”和“写Flash”做成两个独立步骤导致在自动化测试中连续触发擦写时偶尔出现擦除未完成就写入的竞态。后来写了一套Flash操作队列每次擦和写之间加状态确认问题彻底消失。这个故事讲出来比背十条协议规范更有说服力。9. 总结下我个人连续带过三届新人后的一些习惯这里没有标准答案就想分享一下自己在面试和带人过程中积累的几个习惯。第一个习惯每个协议名词都要能讲出“它解决什么问题”。面试官问“CAN和CAN FD有什么区别”你说“CAN FD数据场更长、速率更高”是及格线能补充“CAN FD在仲裁段和实际数据段可以用不同比特率而且CRC更强更适合大数据块传输”就非常加分。这个习惯也适用于网络管理、UDS所有服务。第二个习惯多画时序图尤其是诊断请求、刷写请求、网络管理状态迁移这三类图。面试时如果候选人主动在白板上画图我的印象分会直接往上走。因为车载逻辑大多是并行的异步事件画图比说一百句话更有条理。第三个习惯把“遇到问题怎么查”的日志思路带进面试答案。比如“如果功能寻址刷写时有一个节点没有进入编程模式你怎么查”你如果能说“先Trace该节点有没有收到功能寻址请求再看它是不是在监听错误的ID最后看它当前会话状态”就已经展示出实际操作能力了。最后一个提醒面试考的是工程思维不是死记硬背。把上面这些模块当成线索用“为什么这样做、不这样做会怎样”的思维串起来比背一百条知识点有效得多。祝各位面试顺利能扛住追问也能在写满一白板之后跟面试官相视一笑——那种“这东西你确实干过”的感觉才是稳稳的offer信号。
