快手实习复盘&面试准备

在某手的增长引擎架构组实习了4个月，在简历上是这样写的：

由于已经过去了一段时间，学校发的实习日记也已经上交，现在只能尽可能回忆实习期间的工作内容。

根据我的简历，让GPT问了我一些问题。我将借这些问题回顾这段实习：

广告投放平台后端研发

1. 你简历里写“负责广告投放业务接口开发”，具体负责了哪些接口？

我主要负责公司内部toB广告投放业务平台“自动基建”需求的相关借口。除了简单的业务枚举值接口，以及配置中心账号读取接口外，主要是广告自动投放任务的创建、编辑、查询、启停相关的接口。

2. 广告投放平台里的核心业务模型有哪些？比如 campaign、unit、creative 这类对象之间是什么关系？

以腾讯广告广点通为例，其业务模型可以分为5个层级，其关系如下：

• Campaign：整体投放目标 → 比如“应用下载”。
• AdGroup：投放策略 → 比如“18-30 岁用户、oCPC 出价”。
• Ad：一个投放单元 → 关联具体创意。
• AdCreative：创意模板 → 由多个组件拼接。
• Component：创意最小单元 → 比如图片、视频、标题。

3. 你提到“复杂查询逻辑设计”，复杂在哪里？有没有涉及多表 join、动态查询条件、分页、排序？

都涉及到了：

• 任务表中存放的是每条任务，但各媒体和圈层的钱效约束在另一个表，查询的时候会将这两个表join联合查询。
• 每个投放任务的查询包含多种复杂条件，例如钱效约束 、投放策略、出价与目标、投放产品、任务状态、创建编辑人和时间等等，且这些条件都是可选的。我当时是用NamedParameterJdbcTemplate配合动态拼接的SQL语句和MapSqlParameterSource创建动态查询。
• 分页也实现了，使用 LIMIT 和 OFFSET 拼接 SQL，并且还封装了通用的分页结果VO类。
• 排序使用ORDER BY，默认按创建时间降序排序，且在SQL中位于分页之前。

4. 你提到接口响应时间平均减少 50%，你是怎么定位瓶颈的？

定位使用 EXPLAIN分析对应SQL语句，重点关注：

• type：至少应达到 range，理想是 ref 或 const，避免 ALL 全表扫描。
• key：实际使用的索引。
• rows：扫描行数，越小越好。
• Extra：出现 Using filesort、Using temporary 意味着需要优化。

5. 如何使用本地缓存进行接口优化的？

本地缓存使用Guava的LoadingCache实现本地缓存，例如：

private final LoadingCache<Long, User> userCache = CacheBuilder.newBuilder()
            .maximumSize(1000)                      // 最多缓存 1000 个条目
            .expireAfterWrite(10, TimeUnit.MINUTES) // 写入后 10 分钟过期
            .build(new CacheLoader<Long, User>() {
                @Override
                public User load(Long userId) throws Exception {
                    // 定义缓存未命中时的加载逻辑（如查数据库）
                    return queryUserFromDb(userId);
                }
            });

LoadingCache的内部结构类似ConcurrentHashMap，将整个缓存分成多个 Segment（默认4个）。每个 Segment 内维护独立的锁和哈希表。内部还维护了三种队列：

• WriteQueue（写序）：按写入时间排序，用于实现 expireAfterWrite
• AccessQueue（访问序）：按最后访问时间排序，用于实现 expireAfterAccess
• RecencyQueue（最近访问队列）：记录最近被访问的条目，用来区分 LRU 的热数据

主要流程如下图所示：

cache.get(key)
    │
    ├─ 计算 hash → 定位 Segment → 对 Segment 加锁
    │
    ├─ 在哈希桶中查找 Entry
    │   ├─ 找到且未过期 → 记录访问（LRU队列）→ 返回value
    │   └─ 未找到或已过期
    │       ├─ 创建 LoadingValueReference (占位)
    │       ├─ 释放锁
    │       ├─ 调用 CacheLoader.load()  ████████████ 耗时操作 ████████████
    │       ├─ 重新加锁
    │       └─ 存入value → 返回
    │
    └─ (附带) 检查并移除 WriteQueue/AccessQueue 头部过期节点
                检查 size > max → 驱逐 LRU 最老节点

在大多数情况，只要数据变更低频、或者不一致的时间窗（如几秒）在业务上可接受，就优先用本地缓存。只有当必须跨实例实时共享、或数据量远超单机内存时，才引入 Redis。

6. 读写分离是怎么做的？如何保证读到的数据足够新？

7. 如果主从延迟导致用户刚修改广告配置后查不到最新结果，你会怎么解决？

8. 广告投放平台对数据一致性和接口性能哪个更重要？不同场景怎么权衡？

9. 如果广告主同时修改同一个投放计划，如何避免并发更新问题？

激励业务RPC服务架构开发

1. 你参与的激励 Reco 引擎 RPC 服务主要解决什么问题？

我们做的激励推荐引擎，本质上是要在“发钱/奖励”这类高敏感、高ROI要求的场景下，把策略快速、安全、可控地落地。主要解决三件事：

1. 策略与业务解耦，支撑多场景复用
   赚钱页、Feeds流挂件、直播间等场景，都需要“出价、圈人、排序、选择任务”这一整套推荐逻辑。如果每个场景各写一套，成本高且策略割裂。我们通过统一RPC服务，把核心推荐流程抽象成“接收请求 → 预校验 → 策略编排 → 返回任务列表”，上层场景只传场景ID和上下文，引擎内部做差异化策略，实现一套引擎服务所有激励场景。
2. 让算法团队能安全、独立地迭代策略
   算法同学不需要关心网络层、序列化、容灾这些工程问题。我们在架构层提供了稳定的接口契约、策略配置体系、mock数据能力和实验分流机制。他们只需在约定好的策略槽位里填充/替换算法，通过AB实验观察效果，决定推全或回滚。这样策略迭代周期从天级缩短到小时级。
3. 保障高可用与可控性
   激励场景直接和钱挂钩，出了问题就是资损。RPC服务承担了流量防护（限流、熔断）、参数校验、降级兜底（比如策略超时返回固定任务）、全链路Trace追踪等职责，确保策略“错”的时候系统不崩，且能快速定位问题。

2. 为什么这个场景要用 RPC，而不是 HTTP 接口？

主要是调用关系、性能要求和治理能力这三点决定的。

• 调用方主要是内部微服务，不是前端直接调
  客户端通常不会直连推荐引擎，而是先到接入层/网关，再由Server端调用我们的引擎。内部服务间调用，天然适合RPC：基于长连接多路复用，避免频繁握手开销；强类型接口契约，减少沟通成本。
• 延迟和吞吐要求很高
  激励场景尤其是Feed流挂件、直播间等，推荐需要在几十毫秒甚至更低延迟返回，否则影响用户体验和转化。RPC基于Protobuf序列化，体积小、解析快，配合多路复用，比HTTP+JSON的短连接模式性能更优。
• 依赖完善的服务治理
  我们需要服务发现、负载均衡、熔断限流、链路追踪、灰度路由（按实验ID分流）等能力。公司内部的RPC框架（基于Protobuf的）对这些有完整支持，可以直接利用，而HTTP要补这些能力成本比较高。

简单说就是：内部高性能调用、强治理需求、多语言/多团队协作，这几个因素加在一起，选择RPC是自然的结果。

3. Protobuf 相比 JSON 有什么优势和缺点？

优势：

• 序列化体积小、速度快：二进制编码，字段名不传输，只传编号和值，节省带宽；解析也比JSON文本解析快很多，这对推荐这种高QPS、低延迟场景非常关键。
• 强类型与向前/向后兼容：通过字段编号而非字段名字匹配，增删字段只要遵守编号规则就不会破坏兼容性，这一点在做多版本AB实验和灰度时特别重要。
• 自动生成多语言桩代码：算法侧部分服务可能用Python或C++做模型推理，Protobuf能直接生成对应的数据结构，减少手工维护成本。

缺点：

• 可读性差：二进制不可读，调试需要工具反序列化。我们为此在mock平台和日志里会专门打印JSON化的内容，方便联调和问题排查。
• 浏览器端不友好：如果是直接给前端用的接口，Protobuf需要额外的JS解析或通过网关转JSON。但我们的服务是内部RPC层，恰好规避了这个缺点。
• 字段模型变更要谨慎：虽然兼容，但字段编号一旦分配出去，就不能随便改含义，需要严格遵守约定。如果设计不合理，后期扩展会带来越来越多的废弃字段，增加维护负担。

4. 你们设计统一请求/响应模型时，字段是如何抽象的？

我们遵循“通用头+业务体”的模式，兼顾复用与灵活性。以请求为例：

• 通用请求头（RequestHeader）
  包含：
  • 用户标识：user_id, device_id
  • 场景标识：scene_id（区分赚钱页/挂件/直播间）
  • 实验信息：exp_params（Map结构，承载算法实验参数）
  • 客户端上下文：app_version、os、network_type
  • 链路追踪：trace_id、span_id
• 业务请求体
  包含：
  • 业务相关参数
  • 扩展位：extra（Map<String,String>），允许各场景透传特殊参数而无需频繁改协议

响应模型类似：

• 通用状态：code、message
• 业务返回结果
• 实验标记、实验命中情况等：方便定位哪个策略产生了这条结果

这样抽象的好处是：不变的部分在Header里统一处理（监控、校验、分流），变的部分在业务体和ext扩展里承载，新场景接入多数情况只须增加scene_id枚举和对应策略配置，不用改协议。

5. 你在架构开发中主要做了哪些内容？

• 基于Java设计推荐链路的RPC服务架构；
• 完成各类激励场景的需求开发，实现请求处理、实验策略分流、数据预校验、响应封装等流程；
• 构建mock数据方案至配置中心，支持server端、QA在上线前的staging、PRT等环境进行联调测试；
• 优化增长推荐链路中的接口性能、日志监控与链路跟踪。

6. 你简历里提到将离线推理升级为在线推理，你具体参与了哪部分？

这个我主要是从后端工程接入和推荐链路架构改造的角度参与的，不是负责模型训练本身。

原来的链路更偏离线：算法同学离线训练或离线打分，把结果写到 Hive 表，再通过定时任务同步到 Redis，线上 Java 服务在 RPC 业务逻辑里查 Redis，拿到结果后返回。这个方式比较稳定，但问题是实时性不够，策略迭代和实验也不够灵活。

我参与的部分主要是梳理和改造服务端调用链路。在线推理之后，线上请求不再只是简单查 Redis，而是需要在请求进来时，根据用户、场景、任务等上下文组织参数，再调用公司的在线推理平台，也就是类似 Kaiworks 这样的模型服务平台，拿到实时打分或排序结果。

7. 离线推理和在线推理的区别是什么？

我的理解是，核心区别在于推理发生的时间点不同。

离线推理是提前批量算好结果。比如每天或者每小时跑一次离线任务，用 Hive 里的用户特征、行为特征、业务特征做批量计算，把每个用户或每类场景的结果提前算出来，然后写到 Hive 或 Redis。线上服务请求来的时候，只需要查 Redis 拿结果就行。

它的优点是线上链路简单、延迟低、稳定性好，因为线上只查缓存，不需要实时调用模型。缺点是实时性差，比如用户刚刚发生了新行为，离线结果可能还没更新；另外策略调整也依赖离线任务重新计算，实验灵活性差一些。

在线推理是请求来的时候实时算。线上服务会拿到当前用户、场景、设备、实时行为等上下文特征，然后调用在线推理服务，模型实时返回打分、排序或决策结果。

它的优点是实时性更好，可以结合用户当前状态和最新特征，策略迭代也更灵活，适合推荐、广告、增长策略这类对时效性比较敏感的场景。缺点是工程复杂度更高，需要关注模型服务延迟、超时、稳定性、降级兜底、特征一致性和监控告警。

所以简单来说：

离线推理像是“提前把答案算好，线上查表”；

在线推理像是“请求来了以后，现场根据当前上下文算答案”。

8. A/B 实验的基本原理是什么？

A/B 实验本质上是为了验证一个新策略是否真的比旧策略好。

基本做法是把用户按照某种稳定规则随机分流，比如按照 userId hash，把一部分用户分到对照组 A，继续使用原有策略；另一部分用户分到实验组 B，使用新策略。然后在同一时间窗口内观察两组用户的核心指标差异，比如点击率、转化率、留存、ROI、收入、成本、时长等。

这里有几个关键点。

第一是随机分流，要保证实验组和对照组的人群分布尽量一致，否则指标差异可能不是策略带来的。

第二是单一变量，最好只改变一个核心策略，比如是否接入在线推理、是否更换排序模型、是否调整出价策略，这样才能判断指标变化来自哪里。

第三是指标评估，不仅看核心收益指标，也要看护栏指标。比如增长场景里可能既看拉活、次留、ROI，也要看成本、用户体验、系统延迟等，不能只看一个指标涨了就推全。

第四是灰度放量，实验通常不会一开始全量，而是先小流量验证，观察稳定后再逐步扩大。如果实验效果不好或者系统有异常，就可以快速回滚。

在我参与的链路里，A/B 实验和在线推理的关系主要是：通过实验平台或配置中心控制哪些用户、哪些场景走新链路，哪些继续走旧链路，然后通过日志和指标看新链路是否带来正向收益。

9. 后端工程和算法工程在推荐系统中如何协作？

推荐系统里后端工程和算法工程是强协作关系。

算法工程更关注“怎么推荐得更准”，比如特征设计、模型训练、排序策略、召回策略、实验指标分析等。他们会给出模型、策略逻辑、需要的输入特征，以及期望输出的分数或排序结果。

后端工程更关注“怎么把算法稳定、高效地跑在线上”，包括 RPC 服务设计、请求响应模型、特征获取、缓存、超时控制、降级兜底、配置管理、日志监控、灰度发布等。

以在线推理为例，算法同学可能会提供模型和推理配置，说明需要哪些用户特征、场景特征，以及输出 score 的含义。后端同学要做的是把业务请求里的上下文整理好，调用在线推理平台，拿到结果后和业务规则结合，保证server端能够接收到正确的数据。同时还要保证线上 QPS、延迟、稳定性符合要求。

双方协作通常会经历几个阶段：

第一是需求沟通，确认业务目标、场景、输入输出和指标；

第二是接口设计，约定请求字段、返回字段、异常情况和默认值；

第三是联调测试，用 mock 数据或者测试环境验证数据链路是否正确；

第四是灰度和 AB 实验，通过小流量观察效果和稳定性；

第五是根据实验结果决定回滚、优化还是推全。

所以我的理解是，算法负责策略效果，后端负责工程落地。推荐系统真正上线时，不能只看模型效果，也要看链路是否稳定、延迟是否可控、异常时是否能兜底。

研发提效平台建设

1. 你们为什么要做 Reco 需求承接提效平台？

主要原因是 Reco，也就是推荐相关需求变化比较快，而且很多需求在工程结构上有比较强的重复性。

比如新增一个增长场景、一个激励任务，或者一个新的推荐策略时，后端经常需要重复创建类似的业务类、请求响应模型、配置项、mock 数据、RPC 方法骨架等。虽然每个需求的业务逻辑不同，但工程框架、代码目录、命名规范、字段定义、基础校验、mock 配置这些东西是比较模式化的。

如果每次都人工从零写，一方面会浪费研发时间，另一方面也容易出现代码风格不统一、字段漏配、mock 数据不完整、联调成本高等问题。

所以我们做 Reco 需求承接提效平台，本质上是想把这类重复、模式化的工程工作平台化。研发或算法同学只需要在页面上配置业务类、字段、类型、mock 信息等，平台就可以自动生成一部分标准代码和配置。这样后端同学可以把更多时间放在真正的业务逻辑、链路设计和性能稳定性上。

我参与的部分主要偏工程侧，比如代码生成逻辑、mock 数据配置生成，以及和现有推荐链路代码规范的适配。

2. JavaPoet 的作用是什么？为什么不用简单字符串拼接生成代码？

JavaPoet 的作用是用结构化的方式生成 Java 代码。它可以把类、字段、方法、注解、泛型、访问修饰符、import 等 Java 语法元素抽象成对象，最后再生成规范的 Java 源码文件。

如果用字符串拼接，简单场景确实能做，比如拼一个 POJO 类。但一旦代码结构复杂，就会很难维护。比如字段多了以后，换行、缩进、import、注解、泛型、方法参数、异常处理都要自己控制，代码模板会变成大量字符串，既难读，也容易生成语法错误。

JavaPoet 的好处主要有几个：

第一是语法结构更安全。它不是简单拼字符串，而是通过 TypeSpec、MethodSpec、FieldSpec 这种结构描述 Java 代码，出错概率更低。

第二是可读性更好。生成逻辑本身更像是在“描述一个类应该长什么样”，而不是维护一大段字符串模板。

第三是更容易扩展。比如后续要给类加注解、给字段加默认值、给方法加参数，用 JavaPoet 扩展会比字符串拼接清晰很多。

第四是格式更统一。生成出来的代码缩进、import、方法结构更规范，比较符合团队代码规范。

所以我们不用简单字符串拼接，主要是因为平台不是一次性脚本，而是长期维护的工程工具。代码生成逻辑本身也需要可维护。

3. 代码生成平台生成了哪些代码？

我这块可以从“生成代码骨架，不替代业务逻辑”这个角度回答。

平台主要生成的是推荐需求承接中重复度比较高的工程代码，比如：

第一类是业务模型类，例如某个推荐场景下的请求参数类、响应结果类、业务配置类、字段定义类等。

第二类是RPC 接口相关代码骨架，比如方法签名、入参出参结构、基础的请求封装和响应封装逻辑。

第三类是基础校验和转换逻辑，比如字段非空校验、枚举值转换、业务参数映射等。当然复杂业务判断还是需要人工补充。

第四类是mock 数据配置。因为推荐链路上线前需要在 staging、PRT 等环境做联调，mock 数据可以帮助 server 端、QA 或算法同学在真实数据不完整时先验证链路。

第五类是一些配置模板或样例代码，比如和配置中心、场景标识、实验参数相关的基础配置结构。

不过我会强调：平台不会把完整业务逻辑都生成出来，它主要生成标准化、重复性的代码骨架。真正涉及策略理解、业务判断、异常兜底、性能优化的部分，还是需要研发同学手动实现。

4. 如何保证生成代码的可读性和可维护性？

我理解主要从两个层面保证：一个是生成出来的代码要可读，另一个是生成代码的逻辑本身要可维护。

对于生成出来的代码，首先要遵循团队已有的代码规范。比如包路径、类名、字段名、注释、方法结构、分层职责要和现有项目保持一致，不能生成一套“平台自己的风格”。

其次，生成代码只负责通用骨架，不把复杂业务逻辑硬塞进去。比如请求类、响应类、基础方法、mock 配置可以生成，但复杂策略判断还是留给开发者补充。这样生成代码不会变成一大坨难以理解的自动生成逻辑。

第三，生成结果要尽量和人工写的代码接近。比如类名语义清楚、方法名表达清楚、字段类型明确，必要时生成基础注释，让开发者一看就知道每一段代码的作用。

对于代码生成平台本身，我们会把模板逻辑拆开，比如模型类生成、RPC 方法生成、mock 配置生成分别封装，避免所有生成逻辑写在一个大方法里。

另外，使用 JavaPoet 这种结构化代码生成工具，也有助于维护。因为生成逻辑不是字符串拼接，而是按类、字段、方法这些结构组织，后续新增字段、注解、方法模板时会更清晰。

所以总结来说，可读性靠代码规范和合理边界，可维护性靠模板拆分、结构化生成和不滥用自动生成。

5. 如果业务模板变化频繁，代码生成平台如何设计扩展点？

如果业务模板变化频繁，我觉得不能把模板写死在代码里，否则每次业务变化都要改平台代码，平台本身就会变成新的维护负担。

可以从几个方向设计扩展点。

第一是模板和生成逻辑分层。比如字段定义、类定义、方法定义、mock 配置这些可以抽象成中间模型。前端页面或配置中心先生成一份结构化描述，然后后端生成器根据这份描述生成代码。这样业务变化时，优先改配置或模板，而不是改核心生成流程。

第二是按模块拆分生成器。比如 ModelGenerator 只负责生成模型类，RpcGenerator 只负责生成接口骨架，MockConfigGenerator 只负责生成 mock 配置。如果后续只改 mock 逻辑，就不影响模型类生成。

第三是预留自定义配置项。比如支持自定义包名、类名、字段类型、注解、默认值、是否生成校验逻辑、是否生成 mock 数据等。这样不同业务场景可以通过配置选择需要的能力。

第四是保留人工扩展区。自动生成代码最好只生成基础骨架，对于容易变化的业务逻辑，可以通过接口、抽象类、策略类或者 TODO 区域留给开发者手动实现，避免平台过度生成。

第五是版本化模板。如果不同业务线使用不同模板，可以给模板加版本，比如 v1、v2。老需求继续使用老模板，新需求使用新模板，避免模板升级影响已有代码。

我当时的理解是，代码生成平台的核心不是“生成越多越好”，而是把稳定、重复、规范化的部分沉淀下来，把变化频繁、需要业务判断的部分留给研发同学。这样平台才能真正提效，而不是增加额外复杂度。

6. 生成代码后如何接入流水线？

我们在代码中使用JGit库，在服务器运行时会先生成对应java代码，然后调用git命令新建分支、添加并提交，然后触发云平台的流水线自动构建并打包到产物仓库，架构或算法同学可以直接部署并进行mock测试。

行为面与项目深挖

1. 你实习中最有挑战的一个问题是什么？

最有挑战的是刚进入大厂真实业务时，要快速理解增长业务和公司内部工程体系。很多广告、增长、推荐术语一开始不熟，比如投放层级、ROI、拉新拉活、推荐场景等。我当时的做法是先把业务概念翻译成技术对象，比如表、字段、接口、配置、任务状态，再去参考相似代码实现。这样慢慢把业务理解、代码规范和内部工具链串起来。

---

2. 你遇到过线上问题吗？怎么排查？

我没有主导过特别严重的线上事故，但参与过一些联调和环境问题排查，比如接口返回为空、mock 数据没生效、RPC 调用异常、配置不符合预期等。我的排查思路一般是先确认请求参数和实验/配置是否命中，再看日志和链路追踪，确认请求有没有打到目标服务；然后看下游返回、缓存、mock 配置和异常日志。最后根据问题定位是参数问题、配置问题、环境问题还是代码逻辑问题。

---

3. 和算法同学协作时有没有分歧？怎么解决？

有时会有，比如算法同学更关注策略效果，希望字段和逻辑尽快上线；工程侧会更关注接口稳定性、字段兼容、超时兜底和日志可观测性。我的处理方式是先对齐目标，再把问题拆成输入、输出、异常情况和上线风险。能快速支持的先支持，容易影响稳定性的部分会建议增加默认值、降级逻辑或灰度实验，避免直接影响线上链路。

---

4. 你有没有推动过某个技术方案落地？

有，比较典型的是参与 Reco 需求承接提效平台的一部分建设。我主要做的是根据业务类定义自动生成部分后端代码和 mock 配置，减少重复开发。这个方案不是替代研发，而是把请求响应类、RPC 方法骨架、基础配置、mock 数据这些重复度高的部分自动化生成，让开发同学把时间更多放在业务逻辑和链路稳定性上。

---

5. 你写代码时如何保证质量？

我一般会先看项目里类似功能的实现，保证目录结构、命名、分层职责和团队风格一致。开发时尽量复用已有工具类和公共逻辑，不随便造轮子。提交前会自测核心流程，包括正常参数、异常参数、空值、边界情况。涉及接口的代码，我会看日志、mock 数据和测试环境返回结果，确认链路是通的。

---

6. 你怎么看待代码规范？

我觉得代码规范不是形式主义，而是大型项目协作的基础。尤其在多人维护的业务系统里，统一的命名、目录、分层和注释习惯能降低理解成本。对实习生来说，遵守规范也很重要，因为不能只追求代码能跑，还要保证别人后续能看懂、能维护、能扩展。

---

7. 你做过单元测试吗？哪些代码最值得写单测？

做过一些基础测试和自测。我的理解是，最值得写单测的是纯逻辑、边界清晰、容易出错且不强依赖外部环境的代码。比如参数校验、字段转换、枚举映射、代码生成逻辑、mock 配置生成逻辑、工具类方法等。对于强依赖数据库、RPC 或配置中心的链路，更多会结合 mock、联调环境和集成测试验证。

---

8. 如果产品需求不清楚，但排期很紧，你会怎么做？

我会先把需求拆成确定部分和不确定部分。确定的部分先设计接口和基础代码，避免完全等需求；不确定的部分尽快找产品、导师或算法同学确认，尤其是输入输出、边界情况、验收标准和上线风险。如果确实来不及，我会先做一个可扩展、可兜底的版本，把易变的逻辑放到配置或独立方法里，避免后面大改。

---

9. 如果你不同意导师或 Leader 的技术方案，你会怎么沟通？

我不会直接否定，而是先确认自己有没有理解错。然后把我的担忧具体化，比如性能风险、扩展性问题、上线风险或维护成本，并给出替代方案或折中方案。如果 Leader 最终决定按原方案做，我会先执行，但在实现过程中尽量把风险点通过日志、监控、配置开关或降级逻辑兜住。

---

10. 你觉得自己目前最大的技术短板是什么？

我觉得自己目前最大的短板是对大规模分布式系统的底层原理和线上稳定性经验还不够深。实习中我接触了 RPC、配置中心、容器部署、日志监控、推荐链路等，但更多还是在已有体系下开发和联调。后续我希望继续加强 JVM、并发、缓存、数据库性能优化、分布式系统设计这些基础能力，也多积累真实线上问题的排查经验。