1.Qt 只想接收特定对象发来的信号，过滤其他来源信号怎么做到？
在槽函数内部调用QObject::sender()获取发出信号的对象指针，判断是否为期望的发送对象；如果不是，直接 return 不做业务处理，实现信号来源过滤。
注意：
eventFilter是用于拦截 QWidget 的窗口事件（鼠标、键盘事件），不能过滤信号槽。 Qt::UniqueConnection 只能避免重复建立相同的信号槽连接，不能过滤信号来源。
2.你有两个实习项目，哪个项目你做的比较久，参与的比较深，给我介绍一下？
我参与比较深的是频谱监测上位机的 IQ 数据接收模块。接手的时候项目已经有一部分代码。 最开始开发我将 UDP 数据接收解析和 UI 绘图全部放在 Qt 主线程，大数据量下界面卡顿。之后我做线程拆分，子线程负责 UDP 接收、解析，UI 线程负责波形渲染。 因为万兆 UDP 数据流很大，存在乱序丢包，我在 UDP 自定义包头增加包序号，应用层实现环形缓冲区，做数据包的排序重组，数据完整率达到 95% 以上。 同时使用 setsockopt 调大 socket 内核接收缓冲区，防止高速数据下内核层面丢包。 还有一次硬件联调，波形一直不显示，我花了一天排查，最后通过抓包确认本机没有收到有效数据，定位到是 FPGA 硬件参数未配置，也让我积累了软硬件协同调试的经验。
3.你是怎么发现是硬件问题？是调试出来的？
一开始我不能确定是软件还是硬件问题，我使用抓包工具查看网卡报文，确认本机并没有收到 FPGA 下发的 IQ 数据包。硬件同事坚持硬件没问题。我把抓包的客观证据整理出来，最后定位是 FPGA 侧参数配置错误。AI 只是给我提供调试思路，核心定位还是依靠抓包、控制台调试。
4.AI 工具怎么使用？
平时会使用 DeepSeek。遇到 bug 我会先自己定位，卡壳的时候，我只描述 bug 现象，不会粘贴业务代码，用来获取排查思路；Shell 命令不熟悉的时候也会参考。像之前实习的国防保密项目，代码不能对外，不会把业务代码直接丢给 AI。
5.那像多线程同步这些技术你大概都了解吧，都有哪些？
多线程同步方面了解互斥锁、条件变量，用来处理临界资源的线程安全。IO 多路复用我熟悉 epoll，epoll 内部用红黑树管理 fd，单线程就可以监控大量文件描述符，配合非阻塞 socket，减少上下文切换开销。epoll 分水平触发 LT 和边缘触发 ET 两种模式，ET 模式需要注意循环读写直到 EAGAIN。
6.团队开发，遇到事情大家都有自己想法，你确定你的想法是对的，另一个同事坚持他是对的，沟通僵持甚至快要闹掰，你怎么处理？
如果和同事在技术方案上产生分歧，我不会单纯口头争辩谁对谁错。我会优先拿出日志、抓包、可复现的测试结果这类客观证据，来支撑我的观点，一起分析两种方案的利弊。 如果多次沟通仍然无法达成共识，并且已经阻碍工作推进，我会把两种方案的优缺点客观同步给领导，请领导做决策，就事论事，避免把工作矛盾转化为人际矛盾。就像实习中和硬件同事排查问题，我也是拿出抓包证据来定位问题，而不是口头争论。
7.有没有遇到那种特别难解决的问题，讲讲你解决掉的经验。
在手写仿 muduo 服务器实现 HTTP 模块的时候，客户端连接上来服务器一直返回 400，预期返回 200。 我打印缓冲区日志，发现是 TCP 字节流的问题：我没有等待接收完整的 HTTP 请求头部（没有读到\r\n\r\n结束标记），就直接拿部分收到的数据去做解析 ，残缺报文导致解析失败返回 400。 借助 gdb bt 和日志排查，修改逻辑：必须等 buffer 读到完整的\r\n\r\n头部结束标识之后，再交给 HTTP 解析函数处理。修复之后，正常返回 200。
8.那你解决疑难问题的思路是什么，有哪些依据支撑？
遇到疑难问题，我一般会按照「定位现象、缩小范围、验证假设、沉淀结论」的思路来推进。
第一步是定位现象。先明确问题表现是什么，比如波形不显示、数据丢包、界面卡顿，把现象描述清楚，避免在模糊的问题上盲目猜测。
第二步是缩小范围。我会用抓包、日志、控制台输出等手段，把问题边界逐步收窄。比如之前排查波形不显示的问题，我先用抓包工具确认本机是否收到 FPGA 下发的数据包，发现网卡根本没有收到有效报文，就把问题从软件侧排除，定位到硬件侧。崩溃就用 gdb bt 拿到调用栈
第三步是验证假设。针对缩小后的范围提出可能的根因，再用可复现的实验去验证。比如怀疑是内核缓冲区太小导致丢包，就通过 setsockopt 调大缓冲区后对比数据完整率；怀疑是 UDP 乱序，就在包头加序号、用环形缓冲区排序重组，观察完整率是否提升。
第四步是沉淀结论。问题解决后，我会把根因、排查过程和有效手段记录下来，形成自己的调试经验，下次遇到类似问题可以更快定位。
依据支撑方面，我主要依赖三类客观证据：一是抓包数据，能直接反映网络层是否收到报文；二是日志和断点输出，能反映程序运行到哪一步、状态如何；三是可复现的测试结果，通过控制变量对比，验证修改是否真正生效。这些客观依据比主观猜测更有说服力，也能在团队协作中让结论站得住脚。
9.你这边有什么想问我的？
想了解咱们这边 C++ 开发实习生，更多偏向网络底层开发还是业务逻辑开发？如果有幸入职，我现在技术栈还需要补充哪些知识点？另外想问实习生是否有导师带教。
10.引起段错误的几种形式？
| 类型 | 指针里面的值 | 解引用后果 |
|---|---|---|
| 未初始化局部指针 | 栈上随机垃圾数字 → 野指针 | 段错误 / 随机崩溃 |
| delete 之后不置空的指针 | 已经释放的堆地址 → 野指针 | 段错误、莫名其妙乱值 |
| 指向已经销毁局部变量的指针 | 已回收栈地址 → 野指针 | 段错误、乱值 |
空指针 nullptr |
明确为 0 | 解引用一定段错误，但不是野指针 |
11.总结
我现在觉得我的问题就是①没有仔细听懂面试官的问题，有时候回答的有些答非所问。②对于一些比较基础的问题，表述不清楚，可以选择直接背会。 ③ 回答问题语气词太多，应该有条例一些，先总结再分点回答。