投雪球科技NFC方向的二面，上周刚面完，趁热把过程整理出来。这场一个多小时的面试，没有太多套路化的八股，聊的基本都是NFC原理、标签存储结构，还有简历里一个NFC音乐墙的小项目。面试官会顺着你的回答一直往下追问，直到确认你到底是“背过”还是“真做过”。我把自己遇到的问题、当时的回答思路、以及事后复盘补充的知识点都写在下面。如果你在准备NFC方向的技术岗，或者工作里要接触NFC模块选型、NTAG芯片调试、NFC标签读写这类事，这篇应该能帮你少走点弯路。
1. 面试流程与考察重点
1.1 二面整体节奏
整场面试大约持续了70分钟，节奏比一面紧凑不少。开头是常规的自我介绍，大概10分钟；核心部分是简历项目深挖，花了将近30分钟；中间穿插NFC原理和存储结构的技术问答，大概15分钟；安全方向的中继攻击讨论大约10分钟；最后5分钟留给我反问。
面试官是技术负责人，没有拿着简历一条一条念，而是让我自己挑一个项目讲。我特意选了NFC音乐墙这个项目，主要是因为“NFC + 实际场景落地”和岗位贴合度最高，而且我能往深处讲。这里有个经验：项目深挖阶段不要贪多，一个人深入讲透，效果好过三个人浮光掠影。
1.2 这轮面试到底想筛什么
一面问的多是Vue或Android基础二选一、网络、操作系统这类通用问题。二面则完全围绕NFC展开，考察的是“原理+实践+安全”三个维度的交叉能力。面试官不会直接问“NFC是什么”，而是通过场景化问题考察理解深度。
比如他原话问过：“如果你买的NFC标签，手机一贴就能弹网址，底层到底发生了什么？”这类问题看起来简单，但能拉开人和人的差距。只回答“手机读到了URL所以打开浏览器”是不够的，真正想听的至少包括：NDEF数据怎么被读出来、读出来之后怎么被解析成URI、系统怎么判断交给哪个App处理。这些细节在我后面文章里会展开说。
2. NFC原理问答：从通信基础到协议细节
2.1 工作频率与三种工作模式
面试一开始，面试官就问了一个基础题：“NFC为什么是13.56MHz？三种工作模式分别是什么？”
这个问题的价值在于，它能同时考察频率常识、概念边界和实际工程理解。我当时的回答是：
NFC工作在全球通用的13.56MHzISM频段，这个频段免申请、电磁特性适合近场通信。比它低频的125kHz RFID穿透力强但速率低，适合动物标号、门禁卡；比它高频的UHF（860-960MHz）读取距离远但容易被液体和金属干扰，更多用于物流、仓储盘点和ETC。13.56MHz刚好卡在速率和距离的平衡点上，典型读取距离在10厘米以内，支持106kbps、212kbps、424kbps几种速率，适合近距离交互和移动支付这种场景。
三种工作模式我回答得很清楚：
- 读写器模式（Reader/Writer）：NFC设备主动读取或写入标签，比如用手机给NTAG215标签写入音乐URL。
- 卡模拟模式（Card Emulation）：NFC设备模拟成一张非接触卡，比如Apple Pay、门禁卡的手机化。
- 点对点模式（P2P）：两个NFC设备直接交换数据，Android Beam用的就是这套，不过现在主流手机基本把这个功能弱化掉了。
面试官又补了一个追问：“这三种模式在物理层上有什么区别？”
这里要注意，P2P和读写器/卡模拟模式在编码方式上是有区别的。读写器和卡模拟模式用的是ISO/IEC 14443标准，速率固定为106kbps；P2P模式走的是ISO/IEC 18092（也称NFCIP-1），支持106/212/424kbps三档。简单理解就是，读写器/卡模式是“设备和卡片”之间的非对称通信，P2P是两个“设备”之间的对等通信，物理时序和帧格式不完全一样。
2.2 被动通信与主动通信
面试官第二个问题：“卡片被读的时候，卡里没有电池，能量从哪来？”
这就是近场通信的经典知识点——被动通信模式。读写器持续发射13.56MHz的载波，标签的天线线圈感应到交变磁场后，通过LC谐振产生感应电压，经过内部整流稳压后给芯片供电。标签不会主动发射信号，而是通过改变自身天线负载阻抗（也就是负载调制），反向散射来发送数据。
面试话术提示：这个点最好用“手机充电”的类比来解释——读写器像一个无线充电底座，标签像手机，既接收能量又通过反射方式“说话”。
我当时用了这个类比，面试官还追问了一句：“既然能供能，那NFC标签能不能做成传感器节点？”这其实是一个开放题，可以延伸出去：NFC标签的感应电压非常有限，一般只有几毫瓦甚至更少，低功耗方向确实有“NFC能量采集”的应用，比如无电池环境传感器，但受限于通信距离和生产成本，目前更适合做一次性或低频的读取场景。我当时没有展开太多，只是点到为止，面试官也接受了。
2.3 防碰撞机制
后面问到“两张卡同时靠近读卡器，会怎么处理”。这题听起来简单，但背后是ISO/IEC 14443-3里定义的防碰撞（Anti-collision）机制。
我回答的思路是：读卡器发起防碰撞循环（所谓“防碰撞轮询”）。卡片收到指令后，各自用自己的UID参与二进制搜索树算法。这里有个细节——UID长度为7字节时，协议分两阶段做级联（Cascade），先匹配UID0到UID3，匹配成功后继续往后。读卡器通过逐位比较，最终锁定唯一一张卡片完成通信。其余卡片保持静默，等当前会话结束再竞争。这个机制保证了多卡环境下不会互相干扰。
我在复盘时补充一个容易忽略的点：NFC标签的UID并不是绝对唯一的保证机制，因为UID可以被一些工具改写（虽然很多标签出厂锁定UID，但个别芯片允许修改，NTAG21X系列出厂UID通常是不可变的）。真正识别卡片是否合法，不能只看UID，还要看应用层的加密认证。这在门禁和支付场景里尤其关键，也为后面聊中继攻击埋了伏笔。
3. 标签存储结构：从Page 0x00到用户数据区的完整拆解
3.1 为什么面试官要问“Page 0到Page 3”里装的是什么
这里要特别提一下，我在简历上写过“熟悉NTAG21x系列标签存储结构”，面试官就直接开问：“NTAG215的Page 0到Page 3分别是什么？为什么不能随便往里面写数据？”这个追问非常细，但也是NFC标签读写中最容易踩坑的地方。
我当时是这么回答的：
NTAG213/215/216这类NXP标签，内部存储是以Page（页）为单位的，每一页固定4个字节。Page 0x00、0x01、0x02、0x03这四页属于系统区，各自承担不同职责：
- Page 0x00：存放厂商ID和UID前3个字节。厂商ID是NXP的厂商标识，UID则由厂商在生产时写入，全球唯一。
- Page 0x01：存放UID后续4个字节，凑成完整的7字节UID。
- Page 0x02：包含UID的校验字节（BCC0）以及锁定字节（Lock Bits）。锁定字节控制后续某些区域是否被永久写保护。
- Page 0x03：这是非常重要的CC区（Capability Container），默认值一般是E1 10 06 00，它声明了标签遵循NDEF格式、版本号、数据区大小等元信息。手机通过检查CC来判断“这张卡能不能存NDEF消息”，如果CC被破坏，标签基本就废了。
这里必须强调：这四页里面的UID、BCC、Lock Bits、CC都是系统关键数据。用NFC Tools这类工具正常写URL时，软件会自动从用户数据区的Page 0x04开始写，不会动系统区。但如果用底层读写工具（比如某些刷写软件）或者不小心勾选了“写起始页0x00”，就可能把系统区改掉，标签立刻不能被手机识别。这不是危言耸听，我在调试时真的因为写错过Page 0x02导致一张NTAG213直接报废。
注意：拿到新标签的第一步，一定是先全量备份原始Dump（把所有页数据读出来保存），再开始写数据。一旦写坏，至少还能通过对比Dump定位是被改到了哪一页。
3.2 用户数据区的容量和地址换算
NTAG215的用户数据区从Page 0x04开始，一直到Page 0x83左右（最后一个用户页随型号不同有差异）。总容量大约504字节可写用户数据。为什么我用“大约”？因为NDEF消息还要占用一部分额外开销。
面试官追问：“NTAG215能存多长的URL？”我现场算了一笔账：
- NTAG215用户区504字节。
- NDEF格式需要封装TLV结构：Type Tag（0x03）、Length、Value。其中NDEF消息本身的头部还有几个字节，比如URI Record头（一般5到7字节）。
- 实际能用来存URL的容量大约在490字节左右。
- 一个普通音乐链接，比如“https://m.kugou.com/song/#hash=xxxx”，通常不超过100字节，完全放得下。
- 如果想放更长的文本、通讯录VCard或者自定义Data，NTAG216（888字节用户区）会更稳妥。
记得回答时顺便提一下每页地址的换算逻辑：数据区从0x04开始，每页占4字节，字节偏移 = 页号 × 4。为什么强调这个？因为有些调试工具和规格书会把“页号”和“字节偏移”混着显示，比如某些工具里Page 1显示成0x10，Page 2显示成0x20，不是页号变成了16，而是它直接把“该页在完整存储空间中的起始字节偏移”算给你看了。规格书里如果写Page 0: 0x00, Page 1: 0x10, Page 2: 0x20，默认一页16字节，和我们说的NTAG每页4字节两码事。读规格书时先确认单位，不然地址算错，写入位置全乱套。
3.3 常见工具读写时的页偏移陷阱
面试官可能出于实际经验考了一题：“你用什么工具写音乐URL？写的时候怎么确定起始页？”
我自己常用的方案是：先用NFC Tools读取标签，确认它是NTAG215以及CC区默认值；然后在“Add a record”里选择URL类型，填入链接，软件会自动处理NDEF封装，从正确页开始写。因为NDEF标准对起始位置有约定，正规工具都会避开系统区。
但如果是自己写代码用底层指令（比如通过PN532模块发送WRITE命令），就需要手动指定起始页。这时最容易出问题的就是“页地址偏移”和“块地址”混淆。比如：
- RC522的块地址（Block）对应的是MIFARE Classic的体系，一Block也是16字节，不能用它直接写NTAG215。
- ISO14443-4和ISO14443-3的READ/WRITE命令粒度不一样。NTAG21x遵循ISO14443-3的READ/WRITE命令，按Page为单位，一次读写4字节。
如果面试官再深入，可以补充一句：“底层的READ binary和UPDATE binary命令并不是NTAG21x的原生指令，NTAG21x走的是仿MIFARE的READ和WRITE命令，这也是为什么很多开发板直接把NTAG当MIFARE操作，结果只能读到一半数据。”我当时讲了这点，面试官明显比较认可。
4. 项目深挖：NFC音乐墙的完整设计与踩坑记录
4.1 这个项目是怎么来的，以及为什么选NTAG215
简历上的NFC音乐墙项目，其实是家庭装修改出来的。起因是小孩房间一幅世界地图，想做一个“点哪儿放哪儿音乐”的互动墙：每个国家或城市背后贴一枚NFC标签，手机贴上去，自动播放对应国家的儿歌或标志性音乐。背景音乐通过酷狗音乐或酷我音乐的平台链接获取，这样不用自己存音频文件，也避开了版权存储问题。
面试官对项目背景问得不深，直接切入：“为什么选NTAG215？”我拆成三点讲：
- 容量足够：音乐URL一般几十字节，NTAG215的504字节用户区绰绰有余，甚至还能塞一个短文本描述。
- 可靠性和稳定性：NTAG21x系列是NXP原厂芯片，兼容性比杂牌NFC标签好很多，iPhone和Android主流机型都能正常识别。我测过一些低价标签，在部分手机上偶尔读不出来，而同一批标签反复贴在手机感应区几十次，NTAG215的读出成功率明显高。
- 泛用性和可写次数：NTAG215支持10万次以上擦写，后续换歌、换URL时不用换贴纸。这一点对实际使用很重要，毕竟墙上的标签一旦贴牢，再扣下来很麻烦。
4.2 写音乐链接时踩过的关键坑
这是面试官真正的深挖区。他问得很具体：“你写URL进去之后，手机贴上去一定就能打开？遇到打不开的情况怎么排查？”
我如实讲了整个过程，并按问题发生的环节分成几类。
第一类是NDEF封装问题。早期我用一个不知名小程序写URL，写进去之后手机贴上去什么反应都没有。后面用NFC Tools重新写，就好了。原因是那个小程序没有按NDEF标准构建TLV，只是把纯字符串塞进了数据区。手机读标签时会先检查CC区和NDEF结构，结构非法就直接忽略。排查方法很简单：用NFC Tools读取标签，看记录类型是否显示为“URL”而不是“未知/Text”。
第二类是链接类型的兼容性。音乐链接有两种，一种是网页链接（https开头），一种是App自定义Scheme（比如kugou://或kw://）。测试下来，网页链接兼容性最好，iPhone和Android都能打开浏览器或唤起App；自定义Scheme在Android上经常被拦，国内部分ROM还会弹“未允许打开该应用”的确认框，体验很差。所以最终方案是：统一写网页链接（Universal Link / App Link），而不是裸Scheme。
第三类是感应区域和标签天线的匹配。音乐墙上的标签是嵌在亚克力板后面的，如果手机没有贴在标签正上方，经常读不到。这里有硬件层面的规律：标签天线是一个平面线圈，最佳感应区域在线圈中心偏外一点。手机NFC天线一般在后盖摄像头附近，贴的时候让手机此区域对准标签中心，成功率最高。为了兼顾美观，我试过用铜版纸打印背景图把标签夹在里面，结果金属油墨的导电性影响识别率，后来全部改用普通哑光纸，问题消失。面试官追问金属干扰的原理，这个刚好呼应了NFC的“涡流损耗”——金属表面会产生反向涡流磁场，抵消标签磁场能量，所以标签不能直接贴在金属基材上，一般需要与金属隔离5到10毫米以上。
4.3 酷狗/酷我音乐链接选择与格式细节
面试官对“音乐平台链接”这部分特别感兴趣，追了一题：“你用的是哪个平台的链接？格式有什么坑？”
我讲的是通用方案。酷狗音乐App里点“分享”，复制链接，拿到的通常是m.kugou.com短链，这种短链适合放NFC标签，因为短链长度小，跳转也稳定。酷我音乐类似，复制“歌曲链接”会得到www.kuwo.cn的详情页地址。需要注意的是，不同平台网页版有时会强制跳转App首页，而不是直接播放指定歌曲，这与平台的Universal Link接入情况有关。实测中，酷狗m站链接在iPhone上更容易直接唤起App播放，Android上则要看手机是否装了对应App以及系统默认跳转策略。
写的时候，为了让音乐墙更稳定，我还会在URL后面加一个?from=nfc这样的参数，方便统计到底是哪面墙哪个国家的标签被扫了。这个细节其实是一种低成本埋点，面试官听到后微笑了一下，估计觉得我确实是在做工程而不是玩具项目。
4.4 写完标签后的锁定策略
等所有URL都验证通过后，我做了标签锁定操作。锁定位设置之后，用户数据区变成只读，不会因为熊孩子乱写或者手机误操作把内容冲掉。面试官追问“锁定之后还能再改吗”，答案是不能，至少不能通过常规的NFC工具改。所以锁定必须放在所有内容finalize之后，锁之前务必备份Dump。
这里我还分享了一个反面教训：第一次写音乐墙时，把属于“配置页”的某个字节当成普通数据区顺手改了，导致标签变成了不可写的半砖状态（能读不能写），而当时连原始Dump都没备份，只能报废重贴。所以“先备份再操作”这个习惯不是文档上说说而已，是真的用损失换回来的。
5. 安全视野：NFC中继攻击问答实录
5.1 面试官为什么聊中继攻击
走到这一节，面试官的问题明显从“你会不会做”转向了“你有没有安全边界意识”。他当时的原话是：“NFC门禁、NFC支付都声称安全，你怎么看中继攻击这类威胁？”
这是一个典型的安全方向开放题。我理解他考察的是：候选人除了能把业务做通，能不能意识到NFC射频链路本身存在的攻击面，以及产品设计里是不是只有单一认证因素。
我的回答思路是这样的：先定义中继攻击——不是破解NFC密钥，也不是重放一段固定数据，而是用两个攻击设备“延长通信链路”。一个设备贴近受害者卡片，另一个设备贴近目标读卡器，中间通过蓝牙、Wi-Fi甚至互联网把RF信号实时转发。读卡器端感受到的是“合法卡片就在眼前”，验证通过的还是受害者卡片的真实内容，全程没有破解任何密码学机制。
面试官补充了一个典型的“双继电器攻击”场景：一辆支持无钥匙进入的汽车停在路边，一个攻击者拿着设备靠近车主口袋里的钥匙，另一个攻击者靠近车门把手，两设备建立远程中继，车辆判断钥匙在附近，直接解锁并启动。这个场景不是学术推演，现实中已经有被盗案例。听他讲完，我马上接上了自己的理解：NFC的“近距离”假设本身在攻击模型下并不成立，因为攻击者可以伪造“近距离”。
5.2 有哪些有效的防御思路
面试官听完我的定义，接着问：“如果你是产品经理或系统架构师，怎么防中继？”
我给了四个层次的思考，也被他认可了：
- 时间约束。通过挑战-应答协议记录从发送Challenge到收到Response的往返时间（RTT），如果RTT明显超过近距离电磁波传输应有的时间窗口，判定为中继攻击。这个叫距离约束协议（Distance Bounding），但实现难度不低，需要物理层支持。
- 信号强度校验。读卡器读取RSSI，如果信号强度太弱或波动异常，直接拒绝。这个方案成本低，但不够精确，受环境干扰大，只能缓解。
- 多因子结合。NFC之外再加一个验证通道，比如手机上的NFC支付通常需要生物识别、密码或Face ID，门禁卡可以叠加动态口令或蓝牙辅助验证。就算RF链路被中继，第二因子依然能挡住攻击者。
- 交互式认证。后端下发动态token，要求NFC返回经过签名的随机挑战结果。如果挑战内容每秒钟变化，中继的“透明转发”就会因时延和内容不一致而暴露。
我强调了一个关键点：中继攻击的根源是“链路层的访问控制无法约束物理空间”，所以不能在NFC里加几行代码就解决，必须靠应用层的协议设计。面试官点头，这个问题就算过了。
5.3 给研发工程师的安全提醒
聊完中继攻击，我又顺着补了一点实际操作层面的建议。比如，开发NFC门禁或支付产品时，不要默认NFC链路本身是绝对可信的；手机端的NFC应用要开启危险操作确认；服务端要记录设备指纹和使用行为；如果涉及金额或权限变更，一定要做风控。这套思路放到任何鉴权产品里都成立。
面试官没有要求我现场设计一个距离约束算法，但我在准备阶段还真思考过“为什么手机NFC支付没有大规模被中继攻击利用”——主要原因之一就是支付机构在应用层有多重风控，比如小额免密限时限次、大额必须密码或生物识别、支付平台侧行为分析。所以在工程实践里，“安全”从来不是某一个协议的事，而是系统整体的纵深防御。
6. NFC模块选型与规格书阅读要点
6.1 面试官问“你怎么选NFC模块”
这轮面试的最后一段技术深挖，是关于NFC模块选型的。面试官说：“假如我要做一个量产型的NFC读写设备，让你选模块，你会看哪些东西？”
我没有直接报芯片型号，而是先讲选型方法论。NFC读写模块和标签芯片不一样，选型第一件事是定“用例”：是只做标签读写（比如配网、防伪查询），还是要做卡模拟（移动支付），还是要做P2P？不同用例对协议栈的要求差别很大。我列举了常见的几类方案：
- PN532：老牌NFC模块，支持ISO14443A/B、FeliCa、Mifare，接口有I2C/SPI/UART，开发资料多，适合原型验证和DIY。缺点是个头大、功耗偏高，不适合超薄或电池供电的产品。
- RC522：市面上最常见的低成本读卡芯片，只支持ISO14443A协议族，能读MIFARE和NTAG这类卡，但无法做P2P，也没有完整的NFC Forum协议栈。如果产品只做“读UID”或“读MIFARE卡”，它性价比很高；但只要需求里出现“NDEF解析”“卡模拟”，RC522基本不顶用。
- PN7150/PN7160：NXP的新一代NFC控制器，自带NFC Forum协议栈，驱动完善，支持多接口，功耗低，适合量产型嵌入式产品。它内部带有NCI（NFC Controller Interface）固件，应用层开发相对省心。
- ST25R系列：ST的NFC读卡器芯片，在射频前端性能和抗干扰方面做得不错，很多专业读卡器在用它。
选型不是“越贵越好”，而是“需求与芯片能力匹配”。一个高性价比的标签读取器用RC522就够了，没必要上PN7160；但如果是支持Apple Pay或Google Pay的POS终端，必须用支持NCI协议且过认证的完整方案。
6.2 NFC模块规格书怎么看
面试官追问：“拿到一份NFC模块规格书，你先翻哪一页？”
我的经验是先看这几项（按优先级排序）：
- Features / Key Features：确认协议标准（ISO14443A/B、ISO18092、FeliCa）、工作模式、最大读写距离、供电电压、功耗。这些决定了它能不能满足当前硬件形态。
- 天线设计与匹配：NFC读卡模块性能的一大半在天线。规格书里通常会给出推荐天线尺寸、线圈匝数、匹配电路参考值（比如并联电容、串联电阻），照抄参考设计是最稳的。自己乱改天线会导致谐振频率偏移、读卡距离骤降。
- 接口与时序：确认主控和模块之间是I2C还是SPI还是UART，支持的速率是多少，有没有中断脚、唤醒脚。硬件工程师做原理图时会直接看这些引脚。
- 寄存器与协议栈：模块如果自带固件，规格书会列出I2C/SPI的寄存器映射，或者NCI指令格式。这部分是驱动开发的核心。
- 认证与合规：CE、FCC、RoHS，是否满足目标市场准入要求。量产产品漏掉一个认证，后面就是返工和赔钱。
我还额外提到了一个“反向阅读”习惯：拿到规格书别只盯参数表，先看“参考设计电路”和“天线匹配建议”这两块。很多工程师读卡距离不达标，不是芯片不行，是天线设计和匹配电容没按规格书来。这个点其实也是我实际调试NFC模块时最深的体会，讲给面试官后他明显有共鸣。
6.3 从模块到产品：调试NFC读卡距离的实战经验
顺着规格书的话题，我又主动补充了一段调试经验。很多NFC读卡设备标称“读卡距离5cm”，实际做出来只有1cm，排查步骤基本是固定的：
- 检查天线尺寸是否在规格书推荐范围内，太大太小都会让磁场分布不对。
- 用网络分析仪测天线谐振频率，看是否落在13.56MHz附近，偏差超过几百kHz就要调整匹配电容。
- 测试标签位置和灵敏度：不同标签天线尺寸不同，有效读取范围差异很大，不要拿一个60mm防转移标签去对比25mm硬币标签的读卡距离。
- 检查周围有没有金属外壳、电池、螺丝柱，金属会影响天线Q值和磁场分布。如果产品必须含金属外壳，天线附近要预留净空区或加装吸波材料。
这段经验其实来自一次做NFC门锁模块调试的踩坑经历，虽然不是音乐墙项目里的，但面试官认可这种“从规格书到实际产品”的闭环思路。
7. 反问环节与复盘建议
7.1 我反问的几个问题
面试官问我有没有想问的，我没问“加班多不多”这种问题，而是问了三个更贴近岗位和团队实际情况的问题：
- “雪球科技这边NFC主要在什么产品里落地？是门禁类、支付类，还是智能硬件配网类？”这个问题能让面试官展开讲业务现状，也是我判断自己适不适合的重要依据。
- “团队现在做NFC相关开发，最大的技术难点是射频性能调优还是协议栈稳定性？”这个问题能让我了解团队的痛苦点在哪，是不是我擅长的方向。
- “应届生或新入职的人，前三个月最好补齐哪块能力？”这个问题既表达了学习意愿，也能从回答里捕捉团队对成员的期望。
面试官对这三个问题都做了比较详细的回答，还顺带介绍了团队目前的技术栈和协作节奏。整体感觉技术氛围不错，不是那种纯业务堆人力、没有技术积淀的团队。
7.2 二面下来，我最大的复盘心得
如果只从面试技巧角度复盘，我认为这次二面的核心胜点在三点：
第一，项目和岗位方向高度匹配。NFC音乐墙是典型“懂NFC原理、懂标签存储、懂端到端体验”的项目，既能展示动手能力，又能把面试话题引向自己准备的领域。如果你的项目里也有“小但有闭环”的经历，面试时不要觉得它low，怎么讲比做什么更重要。
第二，基础概念必须能“现推”。面试官问页面地址、问读卡距离、问中继攻击，都不是要你背结论，而是看你有没有能力从原理一步步推导。比如提到“Page 0x03是CC区”后，我会主动解释“为什么手机通过CC判断标签是否支持NDEF，如果CC被破坏会造成什么影响”，这样面试官就能顺着你的逻辑继续追问，而不是两个人各说各话。
第三，安全视野是加分项。NFC方向的中高级岗位，几乎必聊安全。懂中继攻击原理、能讲清防护思路，说明你不只是“写功能”的，而是能站在产品可靠性的角度想问题。这个能力靠临时背题不行，平时得积累。
7.3 给后来人的一点建议
如果距离面试还有两周以上，建议自己动手做一个小项目，比如“NFC名片”或“NFC音乐墙”，把写卡、读卡、NDEF解析、锁卡、备份Dump完整走一遍。这个过程中踩到的坑，比刷十道面试题更有价值。
如果时间不够，至少把NFC标签的存储结构、NDEF格式、ISO14443标准基础概念、常见模块差异和NFC安全威胁模型这五块内容准备扎实。这些是NFC方向面试的“基础盘”，不管面试官从哪个角度切入，你都能接得上。
我个人在实际操作里还有一个感受：面试时讲项目，节奏别太赶，重要节点停下来看看面试官反应。如果他对某个细节眼睛一亮，就多讲两步；如果他表情平淡，就赶紧切到下一个重点。这种“互动式讲述”比把全部细节倒出来更能抓住注意力。
最后再分享一个小技巧：准备NFC面试时，把手机里的NFC Tools、MIFARE Classic Tool和系统自带的“NFC标签读写”相关设置都过一遍，面试官问到实操细节时，你能说出具体软件名、操作路径和常见报错，这就是“真做过”和“看过教程”之间的分水岭。
