康云辉 .net 全栈 12年经验 面试官：李恺 已完成
百分制得分： 76.3 分
可托付度 权重 0.4
4.50

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

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

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

【.NET 核心与异步编程】
Q1：async/await 底层是怎么实现的？ConfigureAwait(false) 什么时候该用？
关键看点：关键看：是否理解状态机机制 + 是否清楚 SynchronizationContext 的影响 + 是否知道 ConfigureAwait 的适用场景
分数 回答特征
5分 能讲清楚编译器将 async 方法转换为状态机（IAsyncStateMachine），知道 SynchronizationContext 的作用，能说出 ConfigureAwait(false) 在库代码中避免死锁和提升性能的原因，知道 ASP.NET Core 没有 SynchronizationContext 但在库代码中仍建议使用
4分 知道状态机和 SynchronizationContext 的概念，ConfigureAwait(false) 的使用场景基本正确，但细节不够完整
3分 知道"不阻塞线程"、"编译器会做转换"，但讲不清状态机的具体机制，ConfigureAwait 只知道"避免死锁"
2分 只会用 async/await 语法，说不出底层原理，ConfigureAwait 没听过或说不清
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：Parallel.ForEach 和 Task.WhenAll 有什么区别？你怎么选？
关键看点：关键看：是否理解同步并行 vs 异步并发的本质区别 + 是否能根据场景选择 + 是否考虑并发度控制
分数 回答特征
5分 能讲清楚 Parallel.ForEach 是同步阻塞的并行（基于线程池分区），适合 CPU 密集型；Task.WhenAll 是异步并发，适合 I/O 密集型。知道 Parallel.ForEach 会阻塞调用线程，Task.WhenAll 不会。能根据具体场景（如批量调接口用 WhenAll，批量计算用 Parallel）做出选择，还会考虑并发度控制（SemaphoreSlim / MaxDegreeOfParallelism）
4分 区别和适用场景都正确，但没提到并发度控制或细节不够
3分 知道一个是并行一个是异步，但具体区别和选择依据说不清
2分 混淆两者，或者只用过其中一个
1分 不了解两者的区别
Q4：.NET 8 相比之前版本你觉得最有价值的改进是什么？
关键看点：关键看：是否持续关注技术演进 + 是否有实际升级/使用经验 + 是否能评估新特性的实际价值
分数 回答特征
5分 能说出多个有价值的改进并结合实际使用体验（如 Native AOT 改进、性能提升、Minimal API 增强、Identity API endpoints、Time abstraction、Frozen collections 等），能说出这些改进对实际项目的影响
4分 能说出几个改进点且理解正确，但缺少实际使用体验
3分 知道一两个改进（如"性能更好了"），但说不出具体细节
2分 只知道版本号升级了，说不出具体改进
1分 不了解 .NET 版本演进，一直用旧版本没关注过
【数据访问与 SQL 优化】
Q5：EF Core 的变更追踪机制是怎么工作的？什么时候该用 AsNoTracking？
关键看点：关键看：是否理解快照对比的内部机制 + 是否清楚性能影响 + 是否知道何时该关闭追踪
分数 回答特征
5分 能讲清楚 DbContext 内部通过快照（Snapshot）对比实体的原始值和当前值来检测变更，SaveChanges 时生成对应的 SQL。知道 AsNoTracking 跳过快照创建，在只读查询场景下减少内存开销和提升性能。还能提到 AsNoTrackingWithIdentityResolution 的区别和 ChangeTracker 的状态（Added/Modified/Deleted/Unchanged）
4分 知道快照对比机制，AsNoTracking 的使用场景正确，但没提到性能量化或 ChangeTracker 状态细节
3分 知道"EF 会追踪实体变化"，AsNoTracking 是"只读时用"，但说不清内部机制
2分 只知道 AsNoTracking 这个 API，不理解为什么要用
1分 不了解变更追踪机制
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：消息队列的消费者怎么做水平扩展？分区/竞争消费你怎么理解？
关键看点：关键看：是否理解分区消费和竞争消费的机制差异 + 是否考虑了顺序性和扩展上限
分数 回答特征
5分 能讲清楚 Kafka 通过分区（Partition）实现并行消费，同一消费者组内每个分区只能被一个消费者消费，扩展消费者数不能超过分区数。RabbitMQ 通过竞争消费（Competing Consumers）实现，多个消费者从同一队列拉取消息，消息只被一个消费者处理。知道两种模式的优缺点和适用场景，能考虑消息顺序性问题
4分 分区和竞争消费的概念正确，但对顺序性或扩展限制的理解不够深入
3分 知道"多个消费者可以并行消费"，但分区和竞争消费的区别说不清
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 + 是否倾向最终一致性 + 是否有实际落地经验
分数 回答特征
5分 能讲清楚分布式事务的问题（性能差、可用性低、实现复杂），倾向于最终一致性方案：Saga 模式（编排式/协调式）、事务性发件箱（Outbox Pattern）、补偿机制。知道 CAP 定理，能根据业务场景选择一致性级别（强一致 vs 最终一致）。能举出实际项目中的做法
4分 知道分布式事务的问题，了解 Saga 或最终一致性方案，但缺少实际经验或细节
3分 知道"分布式事务很难"，提到过 TCC 或 Saga 但说不清具体实现
2分 说"用分布式事务框架"或"两阶段提交"，没有深入理解
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：ASP.NET Core 的中间件管道是怎么工作的？请求从进来到返回经过了哪些环节？
关键看点：关键看：是否理解洋葱模型 + 是否知道中间件顺序的重要性 + 是否能自定义中间件
分数 回答特征
5分 能讲清楚中间件管道的洋葱模型（请求从外到内依次经过每个中间件，响应从内到外返回），知道 Use/Map/Run 的区别，能说出常见中间件的顺序（异常处理 → HTTPS重定向 → 静态文件 → 路由 → 认证 → 授权 → 端点执行）。知道中间件顺序很重要（如异常处理必须在最外层），能自定义中间件
4分 洋葱模型理解正确，知道常见中间件和顺序，但对自定义中间件或顺序影响的理解不够深入
3分 知道"请求经过一系列中间件"，但对洋葱模型和顺序的重要性理解不够
2分 只知道"有中间件"，说不清工作机制
1分 不了解中间件管道
Q23：你们项目是单体还是微服务？如果让你拆微服务，你怎么决定拆分边界？
关键看点：关键看：是否按业务域而非技术层拆分 + 是否了解拆分成本 + 是否有"不过早拆分"的意识
分数 回答特征
5分 能讲清楚拆分的判断依据：按业务领域边界拆（DDD 的限界上下文），而不是按技术层拆。知道拆分的时机（团队规模增长、部署频率不同、扩展需求不同），能说出拆分带来的成本（分布式事务、服务间通信、运维复杂度），有"不要过早拆分"的意识。能举出实际项目中的拆分经验或思考
4分 拆分思路正确（按业务域），知道拆分的成本，但缺少实际经验
3分 知道"按功能拆"，但对拆分边界和成本的理解不够深入
2分 说"每个功能一个服务"，过度拆分倾向，不了解成本
1分 不了解微服务拆分
Q24：你在项目里用过哪些设计模式？举个实际例子说说为什么用它而不是别的方案。
关键看点：关键看：是否有实际应用经验 + 是否能做 trade-off 分析 + 是否有避免过度设计的意识
分数 回答特征
5分 能举出实际项目中的例子（如用策略模式处理多种支付渠道、用工厂模式创建不同类型的通知服务、用中介者模式解耦模块间通信），说清楚为什么选这个模式而不是别的（trade-off 分析），知道过度设计的问题
4分 有实际例子，选择理由合理，但对比分析不够深入
3分 能说出几个模式名称和基本概念，但举不出实际应用的例子
2分 只知道名称（"单例模式"、"工厂模式"），不知道怎么在项目中用
1分 不了解设计模式
Q25：DDD 了解吗？聚合根、领域事件这些概念你怎么理解？有没有实际用过？
关键看点：关键看：是否理解核心概念 + 是否有实际应用经验 + 是否知道 DDD 的适用场景和局限性
分数 回答特征
5分 能讲清楚 DDD 的核心概念：聚合根（保证聚合内的一致性边界，外部只能通过聚合根操作聚合内的实体）、领域事件（聚合间的解耦通信，如"订单已支付"事件触发发货流程）、限界上下文（划分业务边界）。有实际项目中的应用经验，知道 DDD 不是银弹，适合复杂业务域
4分 概念理解正确，有一定实践经验，但对限界上下文或事件驱动的理解不够深入
3分 知道 DDD 的基本概念（实体、值对象、聚合根），但没有实际应用经验
2分 只听说过 DDD，说不清具体概念
1分 不了解 DDD
不需要每个问题都问，根据候选人简历和岗位侧重选择即可。重点关注： 他是"背答案"还是真理解？（追问细节不会卡壳的是真理解） 深度比广度重要：一个方向能讲透比每个都知道皮毛更有价值 有没有实际踩坑经验？（踩过坑的人讲出来有血有肉）
AI 工具提效能力 权重 2.5
4.60

核心考察：是否拥抱 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 的能力边界 + 是否有自己的判断框架
分数 回答特征
5分 能准确指出局限性（上下文理解有限、复杂业务逻辑容易出错、安全敏感代码不能盲信、可能生成过时的API用法），并且能说出自己的应对策略。对 AI 既不盲信也不排斥，态度理性务实
4分 能指出主要局限性，态度理性，但应对策略不够具体
3分 能说出一两个局限性（"有时候不准"），但分析不够深入
2分 说不出具体局限性，要么过度信任（"AI 什么都能做"），要么过度否定（"AI 都不靠谱"）
1分 对 AI 完全没有认知，说不出任何看法
Q5：如果团队要求必须用 AI Coding 工具来提效，你怎么看？
关键看点：关键看：态度是主动拥抱还是被动接受 + 是否有推动团队提效的意识 + 是否把 AI 当作长期趋势而非短期工具
分数 回答特征
5分 非常积极，认为这是趋势，自己已经在用了。还能提出建设性建议（如团队可以共享 prompt 模板、建立 AI 使用规范、定期分享 AI 提效技巧）
4分 积极接受，愿意学习和使用，但没有额外的建设性想法
3分 接受但不主动，说"团队要求就用"，态度是配合而非主动拥抱
2分 有顾虑或抵触，说"担心代码质量"或"不太习惯"，需要较多推动
1分 明确抵触，认为 AI 是噱头或者会降低代码质量
取五个问题得分的平均值，再结合整体感受微调。重点关注： 他是"真用"还是"嘴上说用"？（真用的人能讲出具体工具版本、使用场景、踩过的坑） 审查意识是关键分水岭：会用 + 会审 = 靠谱，会用 + 不审 = 危险，不用 = 淘汰 态度比熟练度重要：积极拥抱的人上手很快，排斥的人推不动
交付闭环能力 权重 0.3
3.00

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

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

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

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：你怎么保证消息队列消费不丢数据？重复消费怎么办？
关键看点：关键看：是否理解消息可靠性的完整链路（生产→broker→消费）+ 幂等方案是否具体可落地 + 是否有监控意识
分数 回答特征
5分 不丢数据：生产端确认机制（ack）、消费端手动确认（处理完再ack）、持久化配置、Dead Letter Queue 兜底。重复消费：业务层做幂等（唯一键/状态机/去重表），能讲清楚具体实现方式。还能提到监控消费延迟和积压告警
4分 不丢和幂等都能讲到，但细节不够完整（比如只说了消费端ack，没提生产端确认），或者没提到监控
3分 知道要手动ack，知道幂等的概念，但具体实现说不清楚，Dead Letter 只是听说过
2分 只能说"用ack"，幂等说不出具体方案，对消息丢失场景认识不全
1分 不了解消息队列的可靠性机制
取四个问题得分的平均值，再结合整体感受微调。重点关注： 他是主动想到风险，还是被追问才想到？（主动的加分，被动的减分） 他的方案是停留在"知道"层面，还是"做过"层面？（做过的人能讲出具体参数和踩过的坑） 他有没有提到监控和告警？（有风险意识的人不只防，还要能发现）
综合评估
维度 权重 得分 加权得分
可托付度 0.4 4.50 1.8
技术原理认知 1.5 2.60 3.9
AI 工具提效能力 2.5 4.60 11.5
交付闭环能力 0.3 3.00 0.9
风险意识 0.3 3.25 1.0
🔒 解锁后修改评分将自动保存 查看完整报告