先交代项目背景#

一句话：「自动驾驶数据闭环平台——从车端数据采集、轨迹回传、质检、标注到重新下发车辆的全链路。」后端 Spring Cloud 微服务，按业务域拆了十来个模块（需求、采集、车辆、标定、标注、发布……），前端是 qiankun 微前端子应用，React 19 + Umi Max，负责数据管线、点云预览、轨迹可视化、批采标注。

记住这句开场，后面每个技术点都往这个背景上挂。

一、HikariCP 连接池事故：数据库深度的王牌#

面试官怎么问：「你做过最复杂的一次线上故障排查是什么？」

真实案例：生产间歇性 Connection is not available，白天流量小没事，夜里和周末连接长时间空闲后，早高峰一来批量超时。特征是「重启就好、过几小时又犯」。

根因链是这样的——部署在 四层负载均衡器后面，连接是 TCP 转发，连接的死活应用层感知不到；MySQL 的 wait_timeout 会异步杀空闲连接；而 Spring Boot 2.3.12 默认带的 HikariCP 3.4.5 不支持 keepaliveTime（3.5.0 才引入），只能靠 maxLifetime 被动到点重建。连接在 maxLifetime 之前被对端杀了，池子不知道，下次借出就是僵尸。

怎么答（这就是 5 分钟的故事）：

「根因是 HikariCP 3.4.5 没有 keepaliveTime，不能主动探活。我在 四层负载均衡器 + MySQL wait_timeout 异步杀连接的组合下，池子里会积累僵尸连接。我没有顺带升 Spring Boot——那是大动作、要全量回归。我选了最小爆炸半径的修复：单独把 HikariCP 升到 4.0.3，这个版本兼容 Spring Boot 2.3-2.5、Java 11+、JDBC 4.2，已在生产 2.5 项目大规模验证。开了 keepaliveTime 后，池子周期性发探活查询，僵尸连接在借出前就被剔出。配套的 maximum-pool-size=20 是为了防 stop 操作卡死调出来的，不是随手填的。」

这个答案之所以得分，是因为它讲了取舍（只升一个组件而非升框架）、版本依据（为什么是 4.0.3）、配套参数的来历（20 不是拍脑袋）——每一层都证明你真的干过，不是背的。

追问防御：

• 「keepaliveTime 和 maxLifetime 区别？」→ 前者是主动探活周期，后者是被动寿命上限。
• 「为什么不换 Druid？」→ HikariCP 性能更好、Spring Boot 默认集成，监控用 Prometheus 补，没必要为监控换池子。

二、漏斗状态机：业务建模复杂度#

面试官怎么问：「你做过业务流程最复杂的一块状态机是怎么设计的？」

真实案例：需求漏斗 6 个联动节点——需求 → issue → 采集 → 质检 → 回传 → 完成。它有一条恒等约束：质检成功 ⟹ 采集成功，质检失败 ⟹ 采集一定失败，所以 回传 ⊆ 质检 == 采集，「采集成功但质检失败」这种状态在系统里不存在。

怎么答：

「状态机两个核心设计。第一，status 记的是『已完成的哪一步』，当前要做的下一步是 status+1——这样查询『卡在哪一步』很直接，代价是写留痕节点时要顺推一环，容易绕。第二，节点联动收拢在一个 Service 里用单判据驱动，质检和采集共享一个判据、百分比恒等，只让展示时间不同——避免两套判据漂移。

有两个坑是踩过才懂的：枚举 RequirementStatusEnum 和 FlowNodeEnum 的 code 3/4 含义互换，写流转记录必须照抄现有同类动作的取值，不能按名字推；还有一个叫 partial 的中间态，它照常写时间放行后续节点，但最终完成额外要求『无一节点为 partial』。」

讲出「恒等约束」「顺推一环」「partial 放行但不完成」这三层，业务建模能力就立住了。

追问防御：

• 「为什么不上状态机引擎（cola-statemachine）？」→ 节点有限、流转强约束，硬编码更可读好测；引擎是节点多、流转灵活才值得上。
• 「parent status=5 / 子 issue status=4 是 bug 吗？」→ 不是，刻意设计，父走流转、子靠漏斗推导，两条线不耦合，别修。

三、点云预览的请求调度：前端工程深度#

面试官怎么问：「你做过最复杂的前端可视化是什么？性能怎么优化？」

这是自动驾驶领域差异化弹药——互联网背景的候选人讲不出来。

真实案例：点云预览支持 pcd / drc / potree 三种格式。渲染层的优化是常规的——POTREE_POINT_BUDGET=2_000_000 限点数、像素比限制在 [1,2] 防 retina 拉爆、DRACO 解码器全局单例 + worker 限制 2、自适应点大小按包围球半径算。真正难的是请求调度。

potree-core 原生 fetch 不带鉴权，对象存储又要签名 URL，还有 Range 分片和大小降级。我写了个签名请求管理器：

「我把 potree 内部请求重写到一个不存在的逻辑源，在请求管理器里识别出是哪个资源（metadata.json / hierarchy.bin / octree.bin），换成真实签名 URL，注入 token、X-Request-ID、X-User-Name——不改 potree 源码就注入了鉴权。签名 URL 用 Promise Map 复用，同一资源只签一次。对象存储的 Range 支持不稳定，我缓存完整响应、后续 Range 请求本地切片构造 206。octree 超 50MB 抛降级错误，不让一个文件把浏览器内存打爆。重试只对 429/5xx，线性退避。」

追问防御：

• 「为什么重写到逻辑源不直接改 potree？」→ potree 的 URL 构造无法改，但能拦截 fetch。逻辑源是个不存在的占位，靠它识别资源类型再换签名 URL，是对第三方库「不侵入、只包裹」的扩展模式。
• 「为什么不直接让对象存储支持 Range？」→ 签名 URL 的 Range 支持取决于 provider，不可控。客户端缓存完整 octree（几十 MB 可控）换 Range 行为可预期，50MB 以上才降级。

四、JPA 防 N+1：持久层的正面教材#

面试官怎么问：「JPA 的 N+1 问题你遇到过吗？怎么解决？」

大部分人这题只能背「N+1 是懒加载在循环里触发的，用 join fetch 解决」。这不够。

真实案例：我们用 JPA，但实体之间不建对象关联，全部逻辑外键——对象图 N+1 从根上就不存在。真正的活是手动 N+1：列表装配里循环按 id 逐条查子数据。需求列表要带进展、子 issue、漏斗、权限，八个子查询，我全走批量。

「统一模式是：先 stream().map(::getId) 收集 id → findByIn(ids) 一次查回 → 转 Map<id, entity> 索引 → 装配时 map.get(id)，O(1)。代码注释里显式标注『避免逐行查库造成 N+1』。

真实修过一个：建任务人姓名的快照列是后加的、没回填存量，详情页逐条回落查共库就是 N+1。我改成收集空快照的 taskId 一次性批量查，还加了短路——全是新数据时根本不发这条 SQL。共库查询失败只 warn 不抛，姓名留空，不让详情页挂掉。」

这个答案的含金量在于：你不只会背 N+1，你知道N+1 有两种（对象图懒加载 vs 手动逐条查），知道每种怎么防，还能拿出一个真实修复案例。

追问防御：

• 「为什么不用 @EntityGraph？」→ 我们没建关联注解，join fetch 无从 fetch；批量 IN 是等价手写 join fetch 的效果，但 SQL 自己控、不依赖 JPA 关联图生成。
• 「真有隐患吗？」→ 诚实说：组织树实体有个 @OneToMany(fetch=EAGER)，一次性渲染才这么选，层级深了要改 LAZY + EntityGraph。能指出自己代码的待优化点，比假装全无破绽加分。

五、架构判断力：共库直读 vs Feign，以及车端下发#

这两块单独拎出来，因为它们考的是判断力，不是技术广度。

共库直读 vs Feign。collection 和 requirement 两个服务之间不走 Feign/MQ，走共库直读/直写。面试官会问「这不违反微服务数据隔离吗？」——

「严格微服务要求每服务独占数据，但我们是平台内强内部服务，数据所有权清晰（requirement 拥有 requirement 表，collection 只读），共库直读是务实选择。写侧失败只告警不抛，因为 task_ref 是跨服务快照，不能让它打断采集主流程。这叫『该共库时不用 Feign』——知道什么时候不该教条，比无脑套微服务规范更值钱。」

SSH 下发车端。采集任务要 SSH 到车端执行 shell。两个硬坑：车端 bash 要求 LF 行尾，Windows 的 CRLF 会让车端报 command not found，.gitattributes 强制 LF；车端外挂盘按 carId 解析（不同车型是 /dev/sda 或 /dev/nvme0n1），写死会格式化错误设备。还有业务红线：停止采集绝不「只改库不通知车」——历史上造成过「库里已结束、车端仍在录」的幽灵录制。

这种软硬结合的经验，是互联网背景候选人讲不出来的差异化。

收束：方法论 × 真实素材怎么组合#

回到上一篇的方法论。系统设计题答得好，靠的不是知道多少名词，而是主动说出每一层的取舍和坑。这篇给的是「取舍和坑」的具体弹药：

最后一句给进场前的你：每个技术点都绑一个项目里的具体类/文件——不绑具体代码的答案都是背的。面试官每追问一层，你早一步说「这里有个坑，我们是这么填的」。这就够了。