北京京东世纪贸易有限公司校招技术产品面试经验——求职精灵（finsight.work）

按“背景、挑战、方案、结果、复盘”五段讲，重点放在技术判断。

1. 背景：项目服务谁、规模多大、你负责哪一块。比如校园预约系统面向三万名学生，早八点开放预约。
2. 挑战：定义清楚是技术挑战还是工程挑战。高并发下的超订、接口超时、数据一致性，都是可讲的点。
3. 方案：前端防重复提交与排队，Redis 原子扣减，消息队列异步落库，死信重试与人工告警。每一层说清为什么。
4. 结果：给量化指标，比如峰值 QPS、零超订、数据库压力下降比例。
5. 复盘：说一个当时没做好的点，比如压测覆盖不足，或监控指标缺失。

追问预警：面试官会问“Redis 扣减成功但消息丢了怎么办”，要答本地消息表、对账和补偿。

按“发现、定位、优化、验证”四步回答。

1. 发现：开启慢查询日志，设置 long_query_time，配合监控看执行次数和耗时分布。
2. 定位：用 EXPLAIN 看 type、key、rows、Extra。type 从 ALL 到 index、range、ref、const 逐步变好；Extra 出现 Using filesort 或 Using temporary 要警惕。
3. 优化：按 WHERE、ORDER BY、JOIN 设计联合索引，遵循最左前缀；用覆盖索引减少回表；避免 SELECT 星号；深度分页改游标；必要时读写分离或归档。
4. 验证：在预发环境对比执行计划和耗时，观察索引对写入的影响。

边界：索引不是越多越好，区分度低的列单独建索引收益有限；需确认业务是否允许短暂不一致。追问预警：索引失效的常见原因。

先解释 DI，再对比两个注解。
依赖注入是 IOC 的实现方式：对象不自己 new 依赖，而由容器在创建时把依赖传进来，从而降低耦合、方便替换和测试。

1. @Autowired 是 Spring 提供的，默认按类型注入；同类型有多个 Bean 时抛异常，需要配合 @Qualifier 指定名称；可标注在字段、构造器、setter 上。
2. @Resource 是 JDK 标准注解，默认按名称注入，找不到再按类型；可通过 name 指定 Bean 名称。
3. 选择：同接口多实现时用 @Autowired 加 @Qualifier 更灵活；单实现时两者差别不大。

边界：字段注入不利于单元测试，构造器注入更推荐。追问预警：循环依赖的三级缓存、@Autowired 注入失败的排查顺序。

先列七种传播行为，再讲失效场景。

1. REQUIRED：有事务就加入，没有就新建，默认值。
2. REQUIRES_NEW：总是新建事务，挂起外部事务。
3. NESTED：有事务时创建保存点，回滚到保存点。
4. SUPPORTS：有则加入，无则以非事务运行。
5. NOT_SUPPORTED：以非事务运行，挂起外部事务。
6. MANDATORY：必须在事务中，否则抛异常。
7. NEVER：必须在非事务中，否则抛异常。

失效场景：private 方法、同类内部 this 调用、异常被 catch 吞掉、抛出受检异常但未配置 rollbackFor、类未被 Spring 管理、事务管理器或数据源不匹配、异步线程中调用。
追问预警：同类调用失效的本质是绕过了代理，可以用 AopContext 或拆类解决。

先拆需求，再定存储，最后讲合并与一致性。

1. 需求：未登录用户用本地或设备临时购物车，登录用户持久化并多端同步；要支持加购、改数量、删除、全选、失效商品提示。
2. 存储：Redis Hash 存热数据，key 为 cart:{user_id}，field 为 sku_id，value 包含数量、价格快照、加入时间、选中状态；MySQL 存明细做持久化。
3. 合并：登录后把临时购物车逐项与服务端合并，同一 SKU 数量相加，取较新的价格快照，合并后删除临时数据。
4. 边界：需确认购物车上限、是否支持多仓或预售、价格快照保留多久；热点用户可用分片 Hash，避免大 key。
5. 一致性：Redis 写成功即返回，异步落库；用版本号或更新时间解决多端覆盖。追问预警：商品下架、价格变化、库存不足时怎么提示。

先讲复制三阶段，再讲脑裂与防护。

1. 全量同步：从库发 PSYNC，主库 BGSAVE 生成 RDB，同时把后续写命令写入 repl_backlog；RDB 发送完成后，再补发缓冲区命令。
2. 增量同步：主库把写命令持续推给从库；断线重连时从库带 runid 和 offset，若偏移量仍在 backlog 中，只补发缺失部分。
3. 脑裂：网络分区后哨兵或集群把从库选为新主，原主库未感知仍在写入，恢复后出现两个主库，数据分叉。
4. 防护：配置 min-replicas-to-write 和 min-replicas-max-lag，让主库在健康从库不足或延迟过大时拒绝写入；集群侧保证多数派仲裁，旧主恢复后降级为从库并全量同步。

边界：这两个参数会降低可用性，需按业务容忍度设置。追问预警：异步复制丢数据怎么兜底。

按“库存分层、扣减链路、异常补偿”回答。

1. 分层：活动库存放 Redis，承接秒杀流量；预占库存记录下单未支付；实物库存落 MySQL，作为最终账本。
2. 扣减：用 Lua 脚本把“判断库存大于 0”和“扣减”做成原子操作，避免并发读改写；扣减成功后创建待支付订单，并设置超时。
3. 支付：支付回调扣减实物库存，用乐观锁或状态机保证只扣一次；回调要做幂等。
4. 回滚：取消或超时未支付，Redis 库存加回，释放预占；通过定时任务对账，修复缓存与数据库差异。
5. 边界：需确认是否允许超卖少量、是否多仓发货、热点 SKU 如何分桶。

追问预警：Redis 扣了但订单创建失败怎么办？答本地事务表加补偿，或先落订单再扣库存。

思路：把 K 条链表的头节点放入小顶堆，每次弹出最小值接到结果链表，再把该节点的下一个节点入堆，直到堆空。
复杂度：设总节点数为 N，堆大小为 K，时间 O(N log K)，空间 O(K)。
边界：需确认 K 是否可能为 0、链表是否可能为空、节点值是否可能重复；重复值时堆的稳定性不保证，但结果仍然有序。若不允许修改原链表，需要新建节点。
替代方案：两两归并，时间 O(N log K)，空间 O(1)，实现更简单但常数更大；数据量小的时候可以直接全部收集后排序，O(N log N)。
可复用表达：“K 路归并的核心是把“比较 K 个头节点”从 O(K) 降到 O(log K)。”追问预警：如果链表是流式输入、无法一次拿到全部头节点，怎么改。

思路：二维动态规划。dp[i][j] 表示 s1 前 i 个字符与 s2 前 j 个字符的 LCS 长度。
转移：若 s1[i-1]==s2[j-1]，dp[i][j]=dp[i-1][j-1]+1；否则取 max(dp[i-1][j], dp[i][j-1])。初始值为 0，答案是 dp[m][n]。
复杂度：时间 O(m×n)，空间 O(m×n)，可用滚动数组降到 O(min(m,n))。
边界：需确认是子序列还是子串，子串要求连续，转移逻辑不同；空串返回 0；字符集大小写是否敏感要问清。
可复用表达：“子序列不要求连续，所以失配时要继承两个方向的最大值；子串失配直接归零。”追问预警：如果要求输出具体序列，需要额外记录方向或回溯。

先给定义，再给例子，最后落到岗位。
我理解“客户为先”不是服务态度好，而是在每次决策时把用户价值放在第一位，哪怕它会增加自己的工作量。
可以讲一次你做页面或功能改版的经历：技术指标很好看，但用户测试时发现关键信息被藏到页面下方，你于是推翻方案，把价格、库存和评价放回首屏。
这件事说明，技术做得好不等于用户用得好。后来你在每个需求评审前都会问三个问题：用户是谁、他最想完成什么、这个改动会不会让他多一步。
落到岗位：技术产品每天面对大量取舍，客户为先就是判断优先级的尺子，而不是一句口号。
追问预警：如果客户需求与公司成本冲突怎么办？答先找双赢方案，再按长期价值排序。