刘鑫 .net 全栈 面试官：李恺 已完成
百分制得分： 86.7 分
可托付度 权重 0.4
4.25

核心考察：出问题时的行为模式。决定你能不能放心把事情交给他。

Q1：你有没有遇到过做到一半发现做不完或做错了的情况？你怎么处理的？
关键看点：关键看：是否主动暴露问题 + 是否带着方案去沟通 + 是否有事后改进追问路径：回答得浅 →"当时 leader 的反应是什么？" 回答得好 →"后来你做了什么调整来避免类似情况？"
分数 回答特征
5分 有具体案例，第一时间主动同步leader，给出了替代方案和时间评估，事后还做了复盘
4分 有具体案例，主动同步了，但替代方案不够完整，或者没有复盘
3分 有案例但比较模糊，说"会跟leader说"但没有具体细节，没有替代方案
2分 说"没遇到过"或者"加班赶出来了"，没有沟通意识
1分 说"先做完再说"或者"等别人发现再处理"，藏问题的倾向
Q2：讲一个你在线上出过的事故，你当时怎么处理的？后来做了什么防止再发生？
关键看点：关键看：是否诚实面对错误 + 处理是否有章法 + 是否有闭环（不只是灭火，还要防火）追问路径：回答得浅 →"影响范围有多大？持续了多久？" 回答得好 →"复盘文档里写了什么？后来团队流程有什么变化？"
分数 回答特征
5分 讲得很细（时间线、影响范围、排查过程、修复方案），主动承担责任，事后有复盘文档和防重犯机制（加监控/加测试/改流程）
4分 过程讲得清楚，主动承担，有防重犯措施但不够系统
3分 能讲出事故和处理过程，但细节不够，防重犯措施比较泛（"以后注意"）
2分 讲得含糊，有甩锅倾向（"测试没测出来"、"产品需求不清楚"），没有防重犯措施
1分 说"没出过事故"（不可信）或者明显在推卸责任
Q3：你有没有在 code review 的时候发现过别人代码里的问题？能讲一个具体的例子吗？你当时怎么处理的？
关键看点：关键看：是否有真实的 review 经历 + 沟通方式是否成熟 + 是否以团队利益为先追问路径：回答得浅 →"如果对方不接受你的意见，你会怎么办？" 回答得好 →"你觉得 code review 最容易发现什么类型的问题？最不容易发现什么？"
分数 回答特征
5分 有具体案例（如发现了性能隐患、安全漏洞、逻辑错误等），先私下沟通说清楚问题和影响，如果对方不改会在 review 里正式提出，必要时升级给 leader，态度是对事不对人
4分 有案例，会私下沟通或在 review 里提，但没有考虑到升级路径
3分 说"会在 review 里提"但举不出具体案例，比较被动
2分 说"不太好意思说"或"看情况"，回避冲突
1分 说"不关我事"或"他的代码他负责"，完全没有团队意识
Q4：需求做到一半产品改了方向，你怎么应对？
关键看点：关键看：情绪是否稳定 + 是否有成本意识 + 是否主动管理变化而不是被动接受追问路径：回答得浅 →"你当时跟产品怎么沟通的？" 回答得好 →"有没有遇到过你觉得不合理但还是得做的需求变更？你怎么处理的？"
分数 回答特征
5分 先评估已做工作的复用性，给出改方向的成本和时间评估，主动跟产品和leader对齐优先级，必要时推回不合理的变更
4分 会评估影响和沟通，但缺少推回不合理需求的意识
3分 说"那就改呗"，能接受变化但没有评估和沟通的习惯
2分 表现出明显的抱怨情绪，或者说"产品老改需求很烦"
1分 说"直接重写"不做任何评估，或者情绪化地拒绝
取四个问题得分的平均值，再结合整体面试中的感受微调。重点关注： 他讲的是真实经历还是编的？（真实经历有细节、有情绪、有反思；编的通常很笼统、结构完美但没有个人痕迹） 他的第一反应是什么？（第一反应最真实，后面补充的可能是"正确答案"） 整场面试中他有没有说过"我不知道"或"我当时做得不好"？（敢承认不足的人更可信） 警惕"完美答案"：如果每个问题都回答得滴水不漏，反而要怀疑真实性
技术原理认知 权重 1.5
3.73

核心考察：是否理解技术原理，而不是只会调用 API。决定了他的天花板。

【.NET 核心与异步编程】
Q1：你写过的代码里，有没有遇到过异步相关的坑？比如死锁、线程问题、或者性能不符合预期的情况？
关键看点：关键看：是否有真实踩坑经历 + 是否理解背后的原理（状态机、SynchronizationContext）+ 是否形成了避坑习惯追问路径：回答得浅 →"你知道 async/await 编译后变成了什么吗？" 回答得好 →"ConfigureAwait(false) 在 ASP.NET Core 里还有必要吗？为什么？"
分数 回答特征
5分 能讲出具体的踩坑经历（如 .Result/.Wait() 导致死锁、忘了 ConfigureAwait(false) 在库代码中引发问题、async void 导致异常丢失等），并且能解释背后的原理（状态机、SynchronizationContext），说明后来怎么解决和避免的
4分 有踩坑经历，能解释原因，但对底层机制（状态机、线程调度）的理解不够完整
3分 知道"不能用 .Result 会死锁"，但说不清为什么，没有具体的踩坑案例
2分 只会用 async/await 语法，没遇到过问题（或者遇到了但不知道是异步导致的）
1分 对异步编程的理解停留在"加个 await 就行"，说不出任何原理
Q2：Task.Run 和直接 async 方法有什么区别？什么场景下该用 Task.Run？
关键看点：关键看：是否理解线程调度的区别 + 是否知道适用场景 + 是否了解在 Web 应用中的注意事项
分数 回答特征
5分 能讲清楚 Task.Run 是把工作调度到线程池线程执行，而直接 async 方法在当前线程开始执行直到遇到第一个 await。知道 Task.Run 适合 CPU 密集型工作，不应该在 ASP.NET Core 中滥用（因为请求本身已经在线程池线程上），能举出具体的正确和错误使用场景
4分 区别讲得清楚，知道 CPU 密集型场景该用 Task.Run，但对 ASP.NET Core 中的使用注意事项不够了解
3分 知道 Task.Run 会用线程池，但对"什么时候该用什么时候不该用"说不清楚
2分 混淆两者的区别，或者说"都差不多"
1分 不了解 Task.Run 的作用
Q3：假设你要批量调 100 个第三方接口拿数据，你会怎么写？一个一个 await 还是有别的办法？
关键看点：关键看：是否能区分 I/O 并发和 CPU 并行 + 是否有并发度控制意识 + 是否考虑了异常和超时追问路径：回答得浅 →"Parallel.ForEach 和 Task.WhenAll 有什么区别？" 回答得好 →"如果 100 个里面有 3 个超时了，你怎么处理？其他 97 个的结果还要不要？"
分数 回答特征
5分 直接说用 Task.WhenAll 做异步并发，并且会控制并发度（SemaphoreSlim），知道不能无限制并发（会打爆对方接口或耗尽连接池）。能区分这个场景和 CPU 密集型场景的区别（后者用 Parallel.ForEach），还会考虑超时、重试、部分失败的处理
4分 知道用 Task.WhenAll，提到了并发度控制，但对超时和部分失败的处理考虑不够
3分 知道不该一个一个 await，但对 Task.WhenAll 和 Parallel 的区别说不清，并发度控制没概念
2分 说"用 Parallel.ForEach"（I/O 场景用错了），或者说"一个一个调也行"
1分 不了解批量异步调用的方式
Q4：.NET 8 或最近的 .NET 版本里，有没有哪个新特性你在项目里实际用过？用了之后效果怎么样？
关键看点：关键看：是否持续关注技术演进 + 是否有实际升级/使用经验 + 是否能评估新特性的实际价值（而不是只背特性列表）
分数 回答特征
5分 能说出实际用过的新特性并讲清楚使用场景和效果（如用 Native AOT 减少启动时间和内存占用、用 Frozen collections 优化热路径性能、用 Identity API endpoints 简化认证开发、用 Time abstraction 提升可测试性等），能对比用之前和用之后的差异
4分 能说出用过的新特性且理解正确，但对效果的量化或对比不够具体
3分 知道一两个新特性（如"性能更好了"），但没有实际使用经验，停留在"看过文章"
2分 只知道版本号升级了，说不出具体改进
1分 不了解 .NET 版本演进，一直用旧版本没关注过
【数据访问与 SQL 优化】
Q5：假设你有一个页面要展示订单列表，数据从数据库查出来只是展示用，不需要修改。你用 EF Core 查的时候会注意什么？
关键看点：关键看：是否本能地想到 AsNoTracking + 是否理解变更追踪的性能影响 + 是否有查询优化的整体意识追问路径：回答得浅 →"你知道 EF Core 的变更追踪是怎么工作的吗？" 回答得好 →"AsNoTracking 和 AsNoTrackingWithIdentityResolution 有什么区别？什么时候用后者？"
分数 回答特征
5分 第一反应就是用 AsNoTracking（只读场景不需要变更追踪），能解释为什么（跳过快照创建，减少内存开销），还会考虑只查需要的字段（Select 投影）、分页、避免 N+1 查询。能提到 ChangeTracker 的工作机制（快照对比检测变更）
4分 知道用 AsNoTracking，能解释原因，但对 Select 投影或 N+1 问题没主动提到
3分 知道 AsNoTracking 是"只读时用"，但说不清内部机制，也没考虑其他优化点
2分 直接 ToList 查出来，没想过 AsNoTracking，对变更追踪没概念
1分 不了解 EF Core 的查询优化
Q6：100 万条数据要导出，你用 EF Core 怎么做？直接 ToList 行不行？
关键看点：关键看：是否有大数据量处理意识 + 方案是否考虑了内存和数据库压力 + 是否有实际经验
分数 回答特征
5分 明确说不能直接 ToList（内存会爆），给出分批方案：分页查询（Skip/Take）或使用 AsNoTracking + 流式读取（AsAsyncEnumerable / IAsyncEnumerable），每批处理后释放 DbContext 避免内存膨胀。还会考虑导出格式（CSV 流式写入而非全部加载到内存），以及数据库端的压力（避免长事务、考虑快照隔离）
4分 知道不能 ToList，给出分批方案，但没考虑 DbContext 内存膨胀或导出格式优化
3分 知道"数据量大不能一次加载"，但方案不够具体，只说"分页查"
2分 说"直接 ToList 应该可以"或"加大内存"，对大数据量处理没概念
1分 没有处理大数据量的经验，说不出方案
Q7：联合索引 (A, B, C)，WHERE B=1 AND A=2 能走索引吗？WHERE A=1 ORDER BY C 呢？
关键看点：关键看：是否理解最左前缀匹配 + 是否知道优化器会重排条件 + 是否能分析复杂场景
分数 回答特征
5分 知道数据库优化器会重排条件顺序，WHERE B=1 AND A=2 能走索引（优化器重排为 A=2 AND B=1 匹配最左前缀）。WHERE A=1 ORDER BY C 只能用到索引的 A 部分，ORDER BY C 无法利用索引（中间跳过了 B），需要额外排序。能分析更多场景（如 WHERE A=1 AND B>5 ORDER BY C 的情况）
4分 两个场景分析正确，知道最左前缀原则和优化器重排，但对更复杂场景分析不够
3分 知道"有顺序要求"（最左前缀），但具体分析有误，比如认为 WHERE B=1 AND A=2 不能走索引
2分 概念模糊，分不清联合索引和单列索引的区别
1分 不了解联合索引原理
Q8：给你一条慢 SQL，你怎么分析？说说你看执行计划的思路。
关键看点：关键看：是否有结构化的分析思路 + 是否能读懂执行计划的关键指标 + 是否知道常见的索引失效场景
分数 回答特征
5分 有系统的分析流程：先用 EXPLAIN / EXPLAIN ANALYZE 看执行计划，关注扫描方式（全表扫描 vs 索引扫描）、预估行数 vs 实际行数、是否有排序/临时表/文件排序。能根据执行计划判断是缺索引、索引失效（函数操作、隐式转换、LIKE '%xx'）、还是统计信息过期。会结合实际场景给出优化建议（加索引、改写SQL、分表等）
4分 知道看执行计划，能分析扫描方式和索引使用情况，但对统计信息、隐式转换等细节不够了解
3分 知道"看执行计划"和"加索引"，但具体怎么看、看什么说不清楚
2分 只会说"加索引"或"优化SQL"，没有分析思路
1分 没有 SQL 调优经验
【后台任务与消息驱动】
Q9：BackgroundService 和 Hangfire/Quartz 你怎么选？各自适合什么场景？
关键看点：关键看：是否理解轻量级 vs 持久化调度的区别 + 是否能根据场景做选择 + 是否考虑了可靠性
分数 回答特征
5分 能讲清楚 BackgroundService 是进程内轻量级后台任务（随应用启停，适合简单的定时轮询、队列消费），Hangfire/Quartz 是持久化的任务调度框架（支持 Cron 表达式、任务重试、Dashboard 监控、分布式调度）。知道 BackgroundService 不适合需要持久化和可靠性的场景（应用重启任务丢失），能根据具体需求选择
4分 区别和适用场景基本正确，但对持久化、分布式调度等细节不够深入
3分 知道两者都能做后台任务，但说不清具体区别和选择依据
2分 只用过其中一个，对另一个不了解
1分 不了解后台任务的实现方式
Q10：Kafka 和 RabbitMQ 的核心区别是什么？你们项目里用的哪个？为什么？
关键看点：关键看：是否理解两者的架构差异 + 是否有实际使用经验 + 选型是否有依据
分数 回答特征
5分 能讲清楚核心区别：Kafka 是分布式日志系统（高吞吐、消息持久化、分区有序、消费者组、适合事件流和大数据场景），RabbitMQ 是传统消息代理（灵活路由、多种交换机类型、消息确认机制成熟、适合业务解耦和任务队列）。能结合项目实际说出选型理由，知道各自的局限性
4分 核心区别讲得清楚，有项目使用经验，但对比分析不够全面
3分 知道"Kafka 吞吐量大"、"RabbitMQ 更灵活"，但说不清具体区别
2分 只用过其中一个，对另一个只是听说过
1分 不了解消息队列
Q11：假设你们的订单消费服务处理太慢，消息开始积压了，你怎么办？
关键看点：关键看：是否有止血+根治的分层思路 + 是否理解不同消息队列的扩展机制 + 是否考虑了顺序性追问路径：回答得浅 →"Kafka 的消费者数量和分区数有什么关系？" 回答得好 →"如果必须保证同一个订单的消息按顺序处理，你怎么设计？"
分数 回答特征
5分 先止血（临时扩消费者实例），然后分析慢的原因（是消费逻辑慢还是下游依赖慢）。知道 Kafka 通过增加分区+消费者来扩展（但消费者数不能超过分区数），RabbitMQ 通过竞争消费直接加消费者。会考虑消息顺序性问题（扩展后同一订单的消息可能被不同消费者处理），以及积压消息的监控告警
4分 知道加消费者，了解分区和竞争消费的区别，但对顺序性或扩展上限考虑不够
3分 说"加消费者"，但不清楚 Kafka 和 RabbitMQ 扩展机制的区别
2分 只知道"加机器"，不了解消费者扩展的具体机制
1分 没有处理消息积压的经验和思路
Q12：一个订单创建后要通知库存、支付、物流三个服务，你怎么设计？
关键看点：关键看：是否有事件驱动思维 + 是否考虑了可靠性（发布可靠、消费幂等、失败补偿）+ 是否能做 trade-off 分析
分数 回答特征
5分 首选事件驱动架构：订单服务发布"订单已创建"事件到消息队列，三个服务各自订阅消费。能考虑到：事件发布的可靠性（Outbox Pattern / 事务性发件箱），消费端的幂等性，部分服务失败的补偿机制（Saga 模式），以及监控和告警。还能对比同步调用 vs 异步事件的 trade-off
4分 选择事件驱动，方案基本合理，但缺少 Outbox Pattern 或 Saga 等可靠性设计
3分 知道用消息队列解耦，但方案比较粗糙，没考虑失败处理和一致性
2分 说"依次调用三个服务的接口"，同步调用思维，没有解耦意识
1分 没有设计思路
【可靠性设计】
Q13：两个请求同时修改同一条数据，你怎么处理？乐观锁还是悲观锁？
关键看点：关键看：是否理解两种锁的原理和适用场景 + 是否知道 EF Core 中的实现方式 + 冲突处理策略是否完整
分数 回答特征
5分 能区分乐观锁（版本号/RowVersion/ConcurrencyToken，适合读多写少、冲突概率低的场景）和悲观锁（SELECT FOR UPDATE / 数据库行锁，适合写多冲突高的场景）。知道 EF Core 中通过 [ConcurrencyCheck] 或 [Timestamp] 实现乐观锁，能说出冲突时的处理策略（重试、合并、提示用户）。还能提到分布式锁（Redis / 数据库）的适用场景
4分 乐观锁和悲观锁的原理和场景都清楚，但缺少 EF Core 具体实现或分布式锁的补充
3分 知道乐观锁和悲观锁的概念，但具体实现和场景选择说不清
2分 只知道"加锁"，分不清乐观锁和悲观锁
1分 没有并发处理的概念
Q14：重试策略你怎么设计？指数退避听说过吗？Polly 用过吗？
关键看点：关键看：是否区分可重试和不可重试异常 + 是否了解指数退避和抖动 + 是否熟悉 Polly 的实际使用
分数 回答特征
5分 能讲清楚重试策略的设计要点：区分可重试异常（网络超时、503）和不可重试异常（400、业务逻辑错误），使用指数退避（Exponential Backoff）+ 抖动（Jitter）避免重试风暴。熟悉 Polly 的使用（Retry、CircuitBreaker、Timeout、Bulkhead），知道如何组合策略（PolicyWrap），能结合 HttpClientFactory 使用
4分 知道指数退避和 Polly，使用场景正确，但对策略组合或抖动等细节不够了解
3分 知道"失败了重试几次"，听说过 Polly 但没深入用过，指数退避概念模糊
2分 只会写 for 循环重试，不了解退避策略和 Polly
1分 没有重试设计的概念
Q15：你在项目里遇到过跨服务数据不一致的情况吗？比如这边扣了钱那边没发货，或者订单状态对不上。当时怎么处理的？
关键看点：关键看：是否有真实的不一致处理经历 + 是否理解分布式事务的 trade-off + 是否倾向最终一致性而非强一致追问路径：回答得浅 →"Saga 模式你了解吗？编排式和协调式有什么区别？" 回答得好 →"事件发布本身怎么保证可靠？如果发事件的时候应用挂了呢？"
分数 回答特征
5分 有真实案例，能讲清楚不一致是怎么发生的、当时怎么修复的。在方案层面倾向最终一致性（Saga 模式、事务性发件箱 Outbox Pattern、补偿机制），知道分布式事务的问题（性能差、可用性低），能根据业务场景选择一致性级别
4分 有案例或清晰的方案思路，了解 Saga 或最终一致性，但缺少实际落地细节
3分 知道"分布式事务很难"，提到过 Saga 或 TCC 但说不清具体怎么做
2分 说"用分布式事务框架"或"两阶段提交就行"，没有深入理解 trade-off
1分 不了解跨服务一致性问题
Q16：Redis 缓存和数据库数据不一致了怎么办？你们怎么处理的？
关键看点：关键看：是否理解缓存策略的 trade-off + 是否知道常见异常场景的防护 + 是否有实际经验
分数 回答特征
5分 能讲清楚常见的缓存策略（Cache Aside / Read Through / Write Through / Write Behind）和各自的一致性问题。知道"先更新数据库再删缓存"的方案及其延迟双删的改进，能分析缓存击穿（热点key过期）、缓存穿透（查不存在的数据）、缓存雪崩（大量key同时过期）的防护方案。有实际项目中的处理经验
4分 知道主要的缓存策略和一致性处理方案，但对击穿/穿透/雪崩的防护不够全面
3分 知道"先更新数据库再删缓存"，但对其他策略和异常场景了解不多
2分 只知道"设过期时间"，对缓存一致性问题没有系统认识
1分 不了解缓存一致性问题
【性能调优】
Q17：你们系统的 QPS 大概多少？做过哪些性能优化？效果怎么样？
关键看点：关键看：是否有实际的性能数据 + 优化手段是否有层次 + 是否能量化效果
分数 回答特征
5分 能说出具体的 QPS 数据和优化前后的对比，优化手段有层次（代码层面：减少不必要的查询、异步化；数据库层面：索引优化、读写分离、分库分表；缓存层面：热点数据缓存、本地缓存+分布式缓存多级架构；架构层面：限流、降级、CDN）。能量化优化效果（如"P99 从 500ms 降到 50ms"）
4分 有实际优化经验，能说出具体手段和效果，但优化层次不够全面
3分 做过一些优化（如"加了索引"、"加了缓存"），但缺少量化数据和系统性思路
2分 说不出具体的 QPS 和优化经验，只有泛泛的概念
1分 没有性能优化经验
Q18：你们项目里有用 APM 工具吗？怎么通过日志和指标定位瓶颈？
关键看点：关键看：是否有 APM 工具的实际使用经验 + 定位流程是否系统 + 是否了解分布式追踪
分数 回答特征
5分 有实际使用 APM 工具的经验（如 Application Insights、SkyWalking、Jaeger、Prometheus+Grafana），能讲清楚定位流程：先看整体指标（QPS、P99、错误率）发现异常 → 通过 traceId 追踪具体请求链路 → 定位慢的环节（数据库、外部调用、代码逻辑）→ 结合日志看具体原因。知道结构化日志（Serilog）和分布式追踪的价值
4分 用过 APM 工具，定位流程基本正确，但对分布式追踪或结构化日志的理解不够深入
3分 知道 APM 工具的概念，但实际使用经验有限，定位瓶颈主要靠看日志
2分 只靠 Console.WriteLine 或简单日志排查，没用过 APM 工具
1分 没有性能监控和定位的经验
Q19：你们项目里为什么用 Redis 而不是 MemoryCache？反过来呢？
关键看点：关键看：是否理解进程内缓存 vs 分布式缓存的 trade-off + 是否能根据场景选择 + 是否了解多级缓存
分数 回答特征
5分 能讲清楚核心区别：MemoryCache 是进程内缓存（速度快、无网络开销，但不能跨实例共享、应用重启丢失、占用应用内存），Redis 是分布式缓存（跨实例共享、持久化、丰富的数据结构，但有网络开销）。能根据场景选择：单实例+数据量小用 MemoryCache，多实例/需要共享/数据量大用 Redis。还能提到多级缓存架构（MemoryCache 做 L1 + Redis 做 L2）
4分 区别和选择依据正确，但没提到多级缓存或内存压力等细节
3分 知道"Redis 是分布式的，MemoryCache 是本地的"，但选择依据不够清晰
2分 只用过其中一个，说不清区别
1分 不了解缓存方案的选择
【架构设计】
Q20：你们项目的分层结构是怎样的？Controller 里该不该写业务逻辑？为什么？
关键看点：关键看：是否理解各层职责 + 是否能说出分层的好处和不分层的坏处 + 是否有实际经验
分数 回答特征
5分 清晰的分层理解：Controller 只做参数校验、请求转发和响应封装，业务逻辑在 Service 层，数据访问在 Repository 层。能说出为什么（关注点分离、可测试性、可复用性），能举出 Controller 写业务逻辑导致的实际问题（如代码膨胀、难以测试、逻辑重复）。还能讨论是否需要 Repository 层的 trade-off
4分 分层正确，知道 Controller 不该写业务逻辑，但对"为什么"解释不够深入
3分 知道要分层，但职责划分不够清晰，比如 Service 和 Repository 的边界模糊
2分 分层概念模糊，Controller 里写业务逻辑觉得"也可以"
1分 不了解分层架构
Q21：DI 容器里 Singleton、Scoped、Transient 分别什么时候用？用错了会出什么问题？
关键看点：关键看：是否理解三种生命周期的适用场景 + 是否知道 Captive Dependency 问题 + 是否有实际踩坑经验
分数 回答特征
5分 能讲清楚三种生命周期：Singleton（全局单例，适合无状态服务、配置、HttpClient 工厂），Scoped（每个请求一个实例，适合 DbContext、UnitOfWork），Transient（每次注入新实例，适合轻量无状态服务）。知道经典错误：Singleton 依赖 Scoped 会导致 Captive Dependency（Scoped 服务被提升为 Singleton 生命周期，DbContext 不会被释放导致内存泄漏和数据过期）。知道 ValidateScopes 开发环境检测
4分 三种生命周期和适用场景正确，知道 Captive Dependency 问题，但细节不够完整
3分 知道三种生命周期的基本含义，但对"用错了会怎样"说不清楚
2分 只知道名称，不清楚具体区别和适用场景
1分 不了解依赖注入的生命周期
Q22：假设你要给所有 API 请求加一个统一的耗时日志，记录每个请求花了多长时间，你会怎么做？
关键看点：关键看：是否本能想到中间件 + 是否理解洋葱模型 + 是否知道中间件顺序的重要性追问路径：回答得浅 →"中间件和 Filter 有什么区别？各自适合什么场景？" 回答得好 →"如果只想给某些路径加日志，不是所有请求都加，你怎么做？"
分数 回答特征
5分 第一反应就是写一个自定义中间件，能讲清楚中间件的洋葱模型（请求进来 → next() → 响应出去，在 next 前后记录时间差）。知道中间件注册顺序很重要（这个日志中间件要放在靠外层），能说出常见中间件的顺序（异常处理 → 日志 → 路由 → 认证 → 授权 → 端点），知道 Use/Map/Run 的区别
4分 知道用中间件，洋葱模型理解正确，但对中间件顺序的重要性或 Use/Map/Run 的区别不够清楚
3分 知道"用中间件"，但对洋葱模型和执行顺序理解不够，可能说"用 Filter 也行"但分不清两者的区别
2分 说"在每个 Controller 里加日志"或"用 AOP"，没想到中间件
1分 不了解中间件的概念
Q23：你们项目现在是单体还是微服务？有没有遇到过'这个功能到底该放哪个服务'的纠结？最后怎么决定的？
关键看点：关键看：是否有真实的架构决策经历 + 是否按业务域而非技术层思考 + 是否了解拆分成本追问路径：回答得浅 →"你觉得什么时候该从单体拆出微服务？有什么信号？" 回答得好 →"拆完之后遇到过什么新问题吗？"
分数 回答特征
5分 有真实的纠结案例，能讲清楚最终按什么依据决定的（按业务领域边界 / DDD 限界上下文，而不是按技术层拆）。知道拆分的成本（分布式事务、服务间通信、运维复杂度），有"不要过早拆分"的意识，能说出什么时候该拆什么时候不该拆
4分 拆分思路正确（按业务域），知道拆分的成本，但缺少实际纠结和决策的经历
3分 知道"按功能拆"，但对拆分边界和成本的理解不够深入
2分 说"每个功能一个服务"，过度拆分倾向，不了解成本
1分 不了解微服务拆分的考量
Q24：你在项目里用过哪些设计模式？举个实际例子说说为什么用它而不是别的方案。
关键看点：关键看：是否有实际应用经验 + 是否能做 trade-off 分析 + 是否有避免过度设计的意识
分数 回答特征
5分 能举出实际项目中的例子（如用策略模式处理多种支付渠道、用工厂模式创建不同类型的通知服务、用中介者模式解耦模块间通信），说清楚为什么选这个模式而不是别的（trade-off 分析），知道过度设计的问题
4分 有实际例子，选择理由合理，但对比分析不够深入
3分 能说出几个模式名称和基本概念，但举不出实际应用的例子
2分 只知道名称（"单例模式"、"工厂模式"），不知道怎么在项目中用
1分 不了解设计模式
Q25：你在项目里有没有用过聚合根、领域事件这类 DDD 的东西？在什么场景下用的？觉得值不值？
关键看点：关键看：是否有实际应用经验 + 是否知道 DDD 的适用场景和局限性 + 是否有"不过度设计"的意识追问路径：回答得浅 →"聚合根和普通实体有什么区别？为什么要有这个概念？" 回答得好 →"你们的领域事件是怎么发布和消费的？进程内还是跨服务？"
分数 回答特征
5分 有实际使用经验，能讲清楚在什么业务场景下引入的（如复杂的订单状态流转、多实体一致性保证），用了之后的效果和代价。理解聚合根的核心价值（一致性边界），知道 DDD 不是银弹，简单 CRUD 场景用 DDD 是过度设计
4分 概念理解正确，有一定实践经验，但对"什么时候该用什么时候不该用"的判断不够清晰
3分 知道 DDD 的基本概念（实体、值对象、聚合根），但没有实际应用经验
2分 只听说过 DDD，说不清具体概念
1分 不了解 DDD
不需要每个问题都问，根据候选人简历和岗位侧重选择即可。重点关注： 他是"背答案"还是真理解？（追问实现细节不会卡壳的是真理解，回答得很"漂亮"但追问就露馅的是背的） 深度比广度重要：一个方向能讲透比每个都知道皮毛更有价值 有没有实际踩坑经验？（踩过坑的人讲出来有血有肉） 不要因为一道题答不上来就否定：看他答不上来时的反应，坦然说"没接触过"比硬编一个答案更可信
AI 工具提效能力 权重 2.5
4.75

核心考察：是否拥抱 AI 工具，能否用 AI 大幅提升开发效率。技术基础 + AI 是团队的硬性要求，敷衍的就算了。

Q1：你平时写代码用 AI 工具吗？用的哪些？怎么用的？
关键看点：关键看：是否已经形成使用习惯 + 使用场景是否多样 + 是主动探索还是被动接触
分数 回答特征
5分 日常深度使用（Copilot/Cursor/Kiro 等），能说出具体使用场景（写业务代码、生成模型映射、写SQL、排查问题、写文档），已经形成了自己的工作流，AI 是开发流程的一部分而不是偶尔用用
4分 日常在用，能举出具体场景，但使用范围偏窄（比如只用来补全代码，没用来排查问题或写测试）
3分 用过，但不是日常习惯，偶尔遇到问题会问 ChatGPT，没有深度集成到开发流程里
2分 只是听说过或简单试过，没有实际使用经验，说"还没来得及学"
1分 完全没用过，或者明确表示排斥（"AI 写的代码不靠谱，不如自己写"）
Q2：举个例子，AI 工具帮你解决过什么实际问题？省了多少时间？
关键看点：关键看：例子是否具体且有业务价值 + 是否能感知到效率提升 + 是否在复杂场景下也能用好
分数 回答特征
5分 能举出具体且有价值的例子（如用 AI 快速理解陌生代码库、批量生成数据迁移脚本、辅助设计复杂业务逻辑的方案），能量化效率提升（"原来要半天，现在一小时"），并且不止一个例子
4分 有具体例子且有说服力，但量化不够精确，或者只有一个例子
3分 例子比较泛（"帮我写过一些代码"、"查过一些报错"），看不出实际提效幅度
2分 举不出具体例子，或者例子很简单（"帮我写了个 for 循环"）
1分 没有任何使用经历可以分享
Q3：AI 生成的代码你会直接用吗？你怎么判断它生成的代码靠不靠谱？
关键看点：关键看：是否有审查意识 + 审查方法是否具体 + 是否踩过坑并从中学到了什么（这其实也在考技术判断力）
分数 回答特征
5分 明确说不会直接用，有系统的审查方法：先看逻辑是否正确、再看边界情况、检查安全隐患（SQL注入、资源泄漏）、确认是否符合项目规范。能举出 AI 生成的代码有问题的具体例子（如没加 AsNoTracking、没处理空值、过度设计等）
4分 知道要审查，能说出几个审查维度，有踩过坑的经历，但审查方法不够系统
3分 说"会看一下再用"，但说不清楚具体看什么，审查意识有但方法模糊
2分 说"大部分时候直接用，有问题再改"，审查意识薄弱
1分 完全不审查直接用，或者因为"不信任"所以完全不用
Q4：你用 AI 生成代码的时候，有没有遇到过它生成的东西看着对但其实有坑的情况？能举个例子吗？
关键看点：关键看：是否有真实的踩坑经历 + 是否形成了审查习惯 + 认知是否理性客观追问路径：回答得浅 →"你一般怎么判断 AI 生成的代码靠不靠谱？会检查哪些方面？" 回答得好 →"有没有什么场景你觉得完全不应该让 AI 来写？"
分数 回答特征
5分 能举出具体的踩坑案例（如 AI 生成的代码没处理空值、用了过时的 API、没加 AsNoTracking、SQL 注入风险、过度设计等），并且能说出自己的审查方法和应对策略。对 AI 既不盲信也不排斥，态度理性务实
4分 有踩坑经历，态度理性，但审查方法不够系统
3分 说"有时候不太准"，但举不出具体例子，对 AI 的局限性认知比较模糊
2分 说不出具体问题，要么过度信任（"AI 生成的基本都对"），要么过度否定（"AI 都不靠谱"）
1分 对 AI 完全没有使用经验，说不出任何看法
Q5：假设你入职后发现团队要求所有人日常开发必须用 AI Coding 工具，你会怎么融入这个工作方式？
关键看点：关键看：态度是主动拥抱还是被动接受 + 是否有推动团队提效的意识 + 是否把 AI 当作长期趋势追问路径：回答得浅 →"你觉得团队用 AI 工具最容易踩什么坑？怎么避免？" 回答得好 →"如果让你给团队制定一个 AI 使用规范，你会包含哪些内容？"
分数 回答特征
5分 非常积极，自己已经在用了，能说出具体怎么融入（如先了解团队用的工具和规范，分享自己的使用经验，主动探索新的提效场景）。还能提出建设性想法（如团队共享 prompt 模板、建立 AI 代码审查规范）
4分 积极接受，愿意学习和适应，但没有额外的建设性想法
3分 接受但不主动，说"团队要求就用"，态度是配合而非主动拥抱
2分 有顾虑或抵触，说"担心代码质量"或"不太习惯"，需要较多推动
1分 明确抵触，认为 AI 是噱头或者会降低代码质量
取五个问题得分的平均值，再结合整体感受微调。重点关注： 他是"真用"还是"嘴上说用"？（真用的人能讲出具体工具版本、使用场景、踩过的坑） 审查意识是关键分水岭：会用 + 会审 = 靠谱，会用 + 不审 = 危险，不用 = 淘汰 态度比熟练度重要：积极拥抱的人上手很快，排斥的人推不动 注意区分"会说"和"会做"：说"我天天用 AI"但举不出具体例子的，可能只是跟风
交付闭环能力 权重 0.3
4.00

核心考察：能否把事情从需求到上线完整做完。决定了他能不能独立扛模块。

Q1：给你一个需求：做一个批量支付接口，你从拿到需求到上线，整个过程你会怎么做？
关键看点：关键看：是否有端到端的全局视角 + 是否针对具体场景做了特殊设计 + 是否考虑了上线后的事情（监控、回滚）
分数 回答特征
5分 完整链路：澄清需求（支付渠道、金额上限、频率、失败处理）→ 技术方案设计（分批、异步、幂等）→ 表结构和接口设计 → 开发自测 → code review → 测试环境验证 → 灰度/小流量上线 → 监控告警配置 → 全量上线。还会主动提到回滚方案和容量评估
4分 流程基本完整（需求确认→设计→开发→测试→上线），但缺少灰度发布、监控配置或容量评估中的一两项
3分 能说出"看需求→写代码→提测→上线"的基本流程，但比较模板化，没有针对"批量支付"这个场景做特殊考虑（如分批、幂等、对账）
2分 只关注写代码环节，对需求澄清和上线保障基本没概念
1分 说"拿到需求就开始写"，完全没有工程流程意识
Q2：如果这个接口上线后出了问题，你的回滚方案是什么？
关键看点：关键看：是否理解回滚不只是代码回退 + 是否考虑了数据一致性 + 是否有预案而不是临时应对
分数 回答特征
5分 分层回滚思路：代码层面（版本回退/功能开关）、数据层面（补偿脚本/对账修复）、业务层面（通知下游/暂停相关任务）。能区分"代码bug回滚"和"数据问题修复"是两回事，还会提到回滚演练
4分 知道代码回退和功能开关，也考虑了数据修复，但没有形成体系化的回滚策略
3分 说"回退代码版本"或"发修复版本"，但没考虑数据层面的回滚和业务影响
2分 只说"回滚代码"，对数据不一致的处理没有概念
1分 没想过回滚，或者说"出了问题再说"
Q3：假设你刚上线了一个支付回调接口，第二天有用户投诉说付了钱但订单没更新。你去查的时候，你希望日志里能看到什么信息？你平时写代码会怎么埋日志？
关键看点：关键看：是否有日志分级意识 + 是否考虑了可排查性（traceId、结构化、关键上下文）+ 是否平衡了信息量和性能
分数 回答特征
5分 能说出关键业务节点必须记日志（回调入参、签名验证结果、订单状态变更前后、数据库操作结果、耗时），异常必须记完整堆栈+上下文（订单号、用户ID）。会用结构化日志（Serilog 等）方便搜索，用 traceId 串联整条链路。也会考虑日志量对性能和存储的影响，调试日志可配置开关
4分 知道关键节点和异常要记，有日志分级意识（Info/Warn/Error），但没提到结构化日志或 traceId 串联
3分 说"重要的地方加日志"、"异常要记"，但标准比较模糊，没有体系化的思路
2分 说"多加点日志方便排查"，没有分级意识，容易记太多或太少
1分 不关注日志，或者说"出问题了再加"
Q4：假设产品给你一个需求：'用户可以批量导出订单'，就这一句话，没有其他细节。你拿到之后第一步做什么？你会问产品哪些问题？
关键看点：关键看：是否能快速识别需求中的模糊点 + 是否主动澄清而不是被动等待 + 是否有记录确认的习惯
分数 回答特征
5分 能快速列出关键的模糊点并主动澄清：导出哪些字段？最大数据量多少？导出格式（Excel/CSV）？是否需要筛选条件？是同步下载还是异步生成后通知？权限控制？确认结果会用文字记录，开发前再同步一次方案。如果产品也说不清，会给出两种方案让对方选
4分 会主动找产品确认关键问题，但遗漏了一些重要点（如数据量上限、同步/异步），记录和同步方案的习惯不够系统
3分 说"会问产品"，但没有主动梳理模糊点的习惯，是遇到一个问一个
2分 说"按自己理解先做，做完再看"，缺乏前置沟通意识
1分 说"需求不清楚是产品的问题"，推责且不主动解决
Q5：假设你做订单模块，需要调用同事负责的库存服务来扣减库存。你们怎么约定接口？如果他的服务上线比你晚，或者他的接口挂了，你怎么办？
关键看点：关键看：是否有契约意识（接口怎么约定的）+ 是否考虑了依赖方故障的降级 + 是否有协同上线的节奏意识
分数 回答特征
5分 先和对方约定接口契约（入参、出参、异常码、超时时间），用文档或 Swagger 固化下来，各自 Mock 对方接口独立开发。考虑了对方服务不可用时的降级方案（如库存扣减失败时暂存请求稍后重试，或走兜底逻辑），会主动和对方对齐上线节奏，先上谁后上谁有计划
4分 知道要定接口契约，会和对方沟通，但缺少降级方案或上线协调的考虑
3分 说"商量着来"或"谁的模块谁负责"，有边界意识但不够具体
2分 边界意识模糊，容易出现"这块到底谁负责"的扯皮
1分 没有边界概念，或者说"都写在一起就行了"
取五个问题得分的平均值，再结合整体感受微调。重点关注： 他的回答是"教科书式"的还是有实际经验支撑的？（有经验的人会提到具体踩过的坑，"完美答案"反而可疑） 他是否主动考虑了"上线后"的事情？（只想到开发阶段的人闭环能力不足） 他遇到不确定性时的第一反应是什么？（主动澄清 vs 自己猜 vs 推给别人） 关注他的第一反应：听到"批量支付接口"先想到什么？先问需求边界的人和先想技术方案的人，工作方式很不一样
风险意识 权重 0.3
4.33

核心考察：是否会主动扫描隐患。决定线上事故概率。

Q1：你们系统上线后出过什么印象比较深的故障或者险情？当时是什么原因，你做了什么防护？
关键看点：关键看：是否有主动扫描隐患的习惯 + 防护措施是否有层次（不只是代码层面，还有监控、告警、兜底）
分数 回答特征
5分 能讲出具体的故障案例（如某次并发写入导致数据重复、第三方接口超时拖垮整个服务、缓存雪崩等），分析清楚根因，讲出做了哪些防护（限流、熔断、监控告警、兜底方案），并且是主动建设而非事后补救
4分 能指出风险点并讲出防护措施，但防护不够体系化，偏单点防护
3分 能说出"数据库是瓶颈"或"第三方接口不稳定"这类泛泛的回答，防护措施比较基础（加try-catch、加日志）
2分 说不出具体风险点，或者说"我们系统还好没什么问题"，缺乏风险扫描意识
1分 完全没有风险概念，从没想过系统哪里会出问题
Q2：一个接口平时 100ms，突然变成 10s，你怎么排查？
关键看点：关键看：排查是否有层次（网络→应用→数据库→外部依赖）+ 是否有止血意识（先恢复再查因）+ 是否用过实际的监控/诊断工具
分数 回答特征
5分 有系统性排查思路：先看监控/APM确认是哪个环节慢（网络、数据库、外部依赖、GC），再看日志定位具体请求，检查数据库慢查询/锁等待/连接池耗尽，检查是否有资源竞争或线程饥饿，最后能给出临时止血方案（限流、降级）和根治方案
4分 排查思路基本正确（看日志→看数据库→看外部依赖），但缺少监控工具的使用或止血方案
3分 知道看日志和数据库，但排查路径不够系统，容易遗漏（比如只想到SQL慢，没想到连接池、GC、线程池等）
2分 只会说"看日志"或"重启试试"，没有结构化的排查思路
1分 完全没有排查经验，说不出任何思路
Q3：批量导入 10 万条数据，中间第 5 万条失败了，你怎么处理？
关键看点：关键看：是否有分批思维 + 是否考虑部分失败的处理 + 是否有幂等和断点续传意识 + 是否考虑了失败后的补偿路径
分数 回答特征
5分 第一反应就是不能全放一个事务里，要分批处理（比如每批1000条）。失败的批次记录到错误表，成功的不回滚。支持断点续传（记录处理进度）。有重试机制，重试仍失败的走人工处理或告警。还会考虑幂等性（重复导入不会产生重复数据）
4分 知道分批处理，失败记录下来后续重试，但没考虑断点续传或幂等性
3分 先想到事务回滚，追问后能改口说分批处理，但方案不够完整
2分 说"全部回滚重来"或"失败了就报错"，没有部分成功的概念
1分 没有处理思路，或者说"应该不会失败"
Q4：假设你上线了一个订单创建接口，运营反馈说有些订单被重复创建了，你怎么排查？怎么防止？
关键看点：关键看：是否有分层防护意识（前端→接口→数据库→消息消费）+ 幂等方案是否具体可落地 + 是否有实际处理经验追问路径：回答得浅 →"幂等性你一般怎么实现？唯一键放在哪一层？" 回答得好 →"如果是消息队列重复投递导致的，你怎么在消费端做幂等？"
分数 回答特征
5分 排查思路清晰（看日志确认是否同一请求重复提交、还是消息重复消费、还是前端重复点击），防护方案完整：前端防重（按钮禁用/loading）、接口层幂等（唯一请求ID/Token机制）、数据库层兜底（唯一键约束）、消息消费层幂等（去重表/状态机）。能讲清楚具体实现方式，有实际处理经验
4分 排查和防护都能讲到，但方案不够分层（比如只考虑了数据库唯一键，没考虑接口层幂等）
3分 知道"加唯一键"或"前端防重复点击"，但方案不够系统，对消息重复消费场景没考虑
2分 只能说"加个判断"，对幂等性没有系统认识
1分 没有处理重复数据的经验和思路
取四个问题得分的平均值，再结合整体感受微调。重点关注： 他是主动想到风险，还是被追问才想到？（主动的加分，被动的减分） 他的方案是停留在"知道"层面，还是"做过"层面？（做过的人能讲出具体参数和踩过的坑） 他有没有提到监控和告警？（有风险意识的人不只防，还要能发现） 同一个考察点可以和其他维度的回答交叉验证：比如他在"可托付度"里说自己很注重质量，但在风险意识题里完全没考虑异常路径，就有矛盾
综合评估
维度 权重 得分 加权得分
可托付度 0.4 4.25 1.7
技术原理认知 1.5 3.73 5.6
AI 工具提效能力 2.5 4.75 11.9
交付闭环能力 0.3 4.00 1.2
风险意识 0.3 4.33 1.3
🔒 解锁后修改评分将自动保存 查看完整报告