25年10月智晟未来信息科技 Java开发实习生一面

写代码遇到bug时，你一般怎么排查？能举个最近解决的小例子吗？

“我遵循 ‘现象→定位→根因→修复→预防’ 五步法：
1️⃣ 复现与观察：明确触发条件（如‘仅iOS端提交订单失败’）
2️⃣ 日志追踪：查应用日志+链路ID（项目中集成SkyWalking）
3️⃣ 工具辅助：Arthas动态监控方法参数、Postman模拟请求
4️⃣ 最小化验证：写单元测试隔离问题模块
最近案例：

• 现象：测试反馈‘修改收货地址后，订单仍显示旧地址’
• 排查：
  • 日志发现addressService.update()返回成功，但订单查询仍为旧值
  • 用Arthas监控：watch com.service.AddressService update '{params, returnObj}' -x 3
  • 发现更新后未清除Redis缓存（缓存Key含用户ID，但更新逻辑漏了删除）
• 解决：在更新方法末尾加redisTemplate.delete("address:"+userId)
• 预防：推动团队在Code Review Checklist增加‘缓存操作完整性’检查项
  感悟：80%的Bug源于‘想当然’，严谨的日志埋点和缓存策略设计是防坑关键。”

项目里经常需要多表查询吗？比如查订单时要关联用户信息，你是怎么写的？

“高频场景（如订单列表需展示用户昵称、商品图片），我的策略：
🔹 简单关联（1-2表）：MyBatis-Plus QueryWrapper + apply("LEFT JOIN user u ON o.user_id = u.id")
🔹 复杂关联（≥3表）：

• 写XML自定义SQL（明确JOIN条件，避免N+1）
• 示例：

  <select id="selectOrderWithDetail" resultType="OrderVO">
    SELECT o.*, u.nickname, p.title 
    FROM orders o
    LEFT JOIN user u ON o.user_id = u.id
    LEFT JOIN product p ON o.product_id = p.id
    WHERE o.user_id = #{userId}
    ORDER BY o.create_time DESC
  </select>
  

🔹 性能优化：
• 用EXPLAIN验证是否走索引（为user_id建联合索引）
• 大数据量时：先查订单ID列表 → 批量查用户/商品信息（MyBatis foreach）
原则：宁可多查字段，避免多次数据库往返；所有JOIN均在测试环境压测验证。”

Redis哨兵机制听说过吗？简单说说它主要是解决什么问题的？

“哨兵（Sentinel）核心解决 Redis主从架构的高可用问题：
✅ 监控：持续检测主/从节点健康状态
✅ 自动故障转移：主节点宕机时，选举从节点升主（基于Raft协议投票）
✅ 通知：通过API通知客户端新主节点地址
✅ 配置提供者：客户端连接哨兵获取当前主节点
项目认知：

• 当前二手平台用单机Redis（数据量小+有持久化），但设计时预留哨兵配置：

  spring.redis.sentinel.master=mymaster
  spring.redis.sentinel.nodes=192.168.1.10:26379,192.168.1.11:26379
  

• 深知哨兵局限：