金蝶软件开发（AI）一面：后端基础与项目深挖

《面试题目》

1. 自我介绍。
2. 个人情况、绩点排名？项目是课程设计还是实战项目？
3. 项目深挖：技术栈是什么？业务背景与要解决的问题是什么？业务流程怎么走？效果怎么评测？
4. 进程与线程的区别是什么？
5. TCP 与 UDP 的区别是什么？TCP 的三次握手过程是怎样的？
6. 数据库的事务隔离级别有哪些？

《参考解析》

项目深挖要按「背景 — 问题 — 方案 — 评测」四段讲，且必须能划清自己的贡献。 业务背景一句话说清这个系统给谁解决什么问题；方案部分讲技术栈与关键取舍，重点是「为什么这么选、替代方案是什么、踩过什么坑」；业务流程要说得出数据从哪来、经过哪些环节、最终落到哪张表或哪个接口；评测则是离线指标加线上指标（准确率、时延、成本、任务成功率），最好带一个「改前改后」的对照。面试官一定会追问「哪一部分是你做的」，含糊其辞会被继续深挖到答不上来，提前把团队既有能力与个人产出分清楚，既显得诚实也能控制被问的边界。评测方式说不清楚是这类面试里最常见的减分点——没有度量就等于没有验证过。

进程与线程的差别要从「资源与调度」两个维度答。 进程是资源分配的基本单位，有独立的虚拟地址空间、页表和文件描述符表；线程是调度的基本单位，同一进程内的线程共享地址空间与堆，只各自持有栈和寄存器上下文。由此推出三个常见结论：切换开销上，进程切换要换页表并可能刷新 TLB，线程切换只换栈与寄存器，因此线程更轻；隔离性上，一个线程的野指针会搞崩整个进程，进程之间互不影响；通信上，进程要靠管道、共享内存、信号、套接字，线程可直接读写共享内存但必须自己做同步。追问一般落在协程与线程的区别（用户态调度、无内核态切换、适合高并发 IO）、以及 CPU 密集用多进程、IO 密集用多线程这类选型判断。

TCP 与 UDP 的区别是特性集合，三次握手的目的不是「打招呼」。 TCP 面向连接、提供可靠有序的字节流，有流量控制与拥塞控制，首部至少 20 字节；UDP 无连接、不保证顺序与到达、保留报文边界，首部 8 字节，支持广播组播，因此实时音视频、DNS、游戏状态同步这类「宁可丢也不要等」的场景用它。三次握手（SYN、SYN+ACK、ACK）真正在做的是双向确认收发能力、并同步双方的初始序列号，从而让历史连接里延迟到达的旧报文不会被当成新连接的数据；只握两次的问题在于服务端无法确认客户端收到了自己的 SYN，也无法确认客户端的接收能力。四次挥手是因为 TCP 全双工，两个方向要各自关闭，被动方收到 FIN 后可能还有数据要发，所以 ACK 与 FIN 不能合并；TIME_WAIT 等 2MSL 是为了保证最后一个 ACK 能到达对端、并让本次连接的旧报文在网络中过期。继续追问会到粘包拆包（TCP 是字节流没有边界，应用层要用定长、分隔符或长度前缀）、以及 SYN Flood 与 SYN Cookie。

事务隔离级别背下来不难，值钱的是讲清定义与实现之间的差。 四个级别依次是读未提交、读已提交（解决脏读）、可重复读（解决不可重复读）、串行化（解决幻读）。MySQL 默认可重复读，普通查询走 MVCC 快照读，同一个事务里多次读到的结果一致；但当前读（select ... for update、update、delete）读的是最新已提交版本，会看到别的事务新插入的行，所以要靠间隙锁（next-key lock）来挡幻读——代价是并发插入受阻、死锁概率上升，这也是不少互联网业务把隔离级别降到读已提交换并发的原因。可以再补两点：ReadView 在读已提交下每次查询都重建、在可重复读下只在首次查询时建立，这是两个级别行为差异的直接原因；以及主从复制下语句格式的 binlog 在读已提交级别更容易出现主从不一致，所以通常配行格式。最后主动提一句 undo 版本链与长事务的危害（版本链过长、purge 被阻塞），会把答案从背题拉到工程理解。

最后一点关于岗位的认知差异值得提前问清。 名字里的「AI」不等于只做大模型应用，这类 ERP 厂商的主营业务仍是财务、供应链、单据流转这类强一致、强审计的传统业务系统，Java 技术栈与后端基础是面试主线；纯 Agent 方向往往在专门的 AI 部门，具体做什么取决于入职分到哪个组。反问环节把「分到哪个部门、业务方向是什么、团队在用哪套技术栈」问清楚，比问「能不能做大模型」更有信息量。