华勤技术软件开发秋招一面面经（10.10）

《面试题目》

1. 项目中用 ES 有遇到什么问题？
2. 检索准确率不高怎么办？
3. OpenFeign 解决什么问题？接收方和接口怎么配置？
4. AI 写代码的弊端有哪些？
5. 你平时怎么用好 AI 写代码，有什么流程？
6. 慢 SQL 怎么优化？
7. 反问。

《参考解析》

ES 在项目里会踩什么问题。答题时按「写入、查询、集群、数据一致性」四类讲最有条理。写入侧：默认每秒 refresh 一次，写多读少的场景要调大 refresh_interval 甚至先关掉再按批 refresh；批量导入用 _bulk 而不是单条写入；文档 ID 自动生成还是自定义会影响写入路径。查询侧：from + size 深分页在 max_result_window（默认 10000）之后直接报错，正确做法是 search_after（有稳定排序键）或 scroll／PIT（离线导出场景）；聚合查询吃内存，字段上开 fielddata 要谨慎，容易 OOM；term 和 match 用错是最常见的低级错误——不分词的字段（keyword、数字、日期）用 term，需要分词检索的文本字段用 match。集群侧：分片数不是越多越好，小分片会让查询扇出放大、集群元数据压力上升，一般按「单分片 10～30GB」估；副本数影响写入与查询的取舍。一致性侧：ES 不是事务型存储，MySQL 与 ES 的同步要靠 binlog 订阅（Canal）/MQ 异步写，必须考虑失败重试和全量对账，否则会出现「库里改了、搜出来还是旧数据」。

检索准确率不高怎么办。先定位是哪一环的问题，不要一上来就换模型。步骤是：① 建评测集——拿几十条真实查询，人工标出应该命中的文档，算 Recall@k 和 NDCG，有了基线才知道改动有没有用；② 看召回层，检索不到通常是分词问题（行业术语、型号、人名被切碎）、同义词没配、查询串太口语化，对应的手段是自定义词典、同义词表、analyzer 调整、multi_match 跨字段加权；③ 看排序层，BM25 的默认打分对短字段不友好，可以用 boost、function_score（按时间、热度、销量加权），或者接一个 rerank 模型对 Top-50 精排；④ 看查询改写，把用户的自然语言先过一次同义扩展或向量召回，做关键词加向量的混合检索，再融合排序。最后提醒一句：准确率和覆盖率往往是一对矛盾，收紧匹配规则会提高准确率但漏召回，必须用评测数据说话。

OpenFeign 解决什么问题、怎么配。它解决的是「服务之间用 HTTP 调用时，手写 URL、拼参数、解析响应、处理负载均衡」这一堆重复劳动，把这些收敛成声明式接口：写一个带 @FeignClient(name = "服务名") 的接口，方法上用 @GetMapping 等注解描述契约，Spring Cloud 会生成代理，集成服务发现与负载均衡（LoadBalancer），你像调本地方法一样调用。接收方就是普通的 Spring MVC Controller，路径、方法、参数名、请求体结构必须与 Feign 接口严格对齐——这也是最容易出错的地方。配置上要注意：@EnableFeignClients 扫描包路径；path 用来加统一前缀；超时（connectTimeout/readTimeout）必须显式设置，默认值往往不适合生产；重试要小心，Feign 自带的 Retryer 加上 Ribbon/LoadBalancer 的重试会叠加，写操作场景要关掉；日志级别用 Logger.Level 按需打开，排查完记得调回去；降级走 Fallback 或 FallbackFactory；跨服务的鉴权信息、链路 trace 头需要拦截器透传。面试官问「接收方和接口怎么配置」，其实是想确认你是否真的写过，把「接口定义在调用方、@FeignClient 的 name 对应注册中心的服务名、接收方 Controller 的路径要对上」说清楚即可。

AI 写代码的弊端。真实存在的几类：① 幻觉 API，调用了不存在的方法或参数，编译期才发现；② 看似正确但边界缺失，空值、越界、并发、异常路径经常漏，而这类 bug 恰恰最难在 review 里看出来；③ 缺乏全局上下文，它给出的实现可能和项目既有的分层、命名、错误处理约定不一致，长期下来代码风格分裂；④ 安全与合规风险，拼接 SQL、硬编码密钥、引入来路不明的依赖；⑤ 认知卸载，人不再理解自己提交的代码，出问题无法定位；⑥ 把 review 成本从编写者转移到了评审者，团队总成本未必下降。这些不是不要用，而是要知道每个风险的闸门在哪。

怎么用好 AI 写代码。可以给一套自己的流程：动手前先让 AI 读现有代码与约定（同类模块的实现、错误处理方式、测试写法），把它当需要上下文的协作者而不是搜索引擎；需求先拆小，一次只让它改一个可验证的点，改动面越小越容易 review；先定接口和验收标准（输入输出、边界条件、要过的测试），再让它填实现；生成完必须过编译、过测试、跑一遍真实链路，再人工 review 关键路径（并发、事务、异常、SQL）；把反复出现的坑写进项目里的规则文档或提示词，让它下次自动避开；对不可逆的部分（生产配置、数据订正、密钥）不由 AI 代笔。最后一句总结很能加分：AI 提高的是打字速度，不提高你对系统正确性的责任。

慢 SQL 怎么优化。顺序是「先定位、再优化、后验证」。定位靠慢查询日志（slow_query_log、long_query_time）和 EXPLAIN，重点看 type（出现 ALL 全表扫描、index 全索引扫描要警惕）、key（实际用了哪个索引，跟预期不一致说明索引没走到）、rows（预估扫描行数）、Extra（Using filesort、Using temporary 是排序和分组没走索引的信号）。优化手段按性价比排：① 加合适索引，遵守最左前缀，尽量做覆盖索引，避免在索引列上做函数运算或隐式类型转换（字符串列传数字会直接失效）；② 改写 SQL，去掉 select *、减少回表、大 offset 分页改成游标（where id > ?）或延迟关联；③ 拆解大事务与长事务，别在一个事务里做批量更新；④ 结构层面考虑归档历史数据、分区、读写分离、必要时做冗余字段减少 join；⑤ 治理层面加监控告警和上线前的 SQL 审核。最后一定要说验证方式：改完再跑 EXPLAIN 对比，看真实耗时和线上监控的 P99，而不是「加了索引应该就好了」。