Java高级后端 · 架构组件开发 + CodeReview（本岗位差异化核心）

1. 开发公共组件要考虑什么【适配你当前岗位：运行相关技术组件项目】

岗位背景：参与运行相关技术组件、手册结构化项目，组件给多个业务项目组使用。

公共组件：多个业务线复用的 jar 包 / SDK，不是业务代码，

核心目标：通用性、兼容性、稳定性、易用性、可运维。

一、功能设计

1. 职责单一：单一职责原则，一个组件只解决一类问题，不要把无关能力塞进同一个组件，避免臃肿。

2. 可配置化：核心参数支持外部配置，不能硬编码。支持 SpringBoot 配置文件、注解方式开关功能，业务按需开启关闭。

3. 扩展预留：预留扩展点（接口、SPI、钩子函数），业务可自定义实现，不要写死逻辑。

4. 最小侵入：尽量低侵入，业务侧改动越少越好；最好注解 / 配置启用，不强制修改原有业务代码。

5. 能力裁剪：区分必选能力和可选能力，不需要的模块可以关闭，减少依赖和性能损耗。

二、兼容性（高频考点）

1.版本兼容

• 向前兼容：新版本不能破坏旧版本 API，方法参数、返回值改动要慎重；API 废弃用注解标记@Deprecated，保留过渡期。

• SpringBoot/Spring 版本兼容：适配项目主流版本，避免依赖冲突。

2.依赖管理

• 依赖 scope 控制（provided 可选），避免把大量传递依赖打包进组件，防止业务项目 jar 包冲突（依赖冲突是公共组件最常见坑）。

• 统一管理依赖版本，排除冲突包。

3.JDK 版本兼容：确定支持的 JDK 基线，不能使用业务项目不支持的语法。

三、稳定性 & 性能

1.异常处理

• 内部异常捕获，不能吞异常；异常信息规范，区分组件异常、业务异常。

• 故障隔离：组件自身故障，不能拖垮主业务；失败策略可选：快速失败、降级。

2.资源释放

• 线程池、连接、文件句柄等资源，提供销毁钩子，容器关闭时正常释放资源，避免内存泄漏。

3.性能

• 核心路径减少锁、减少序列化，避免频繁创建对象；

• 支持异步、限流，组件内部做好限流保护，防止业务调用把组件打崩。

4.幂等性：如果涉及调用外部资源，对外操作尽量支持幂等，防止重复调用产生脏数据。

四、可观测性（运维监控）

1. 日志规范：统一日志级别、格式；关键节点打印日志，不要大量打 DEBUG 日志影响性能；支持日志开关。

2. 埋点监控：埋入指标（成功数、失败数、耗时），暴露 Metrics，接入 Prometheus；支持链路埋点，集成 SkyWalking。

3. 错误码：自定义组件错误码，方便业务定位问题。

五、易用性 & 文档

1.API 设计简洁：方法命名易懂，参数合理，减少业务理解成本。

2.完善文档：

• 使用文档：引入依赖、配置示例、demo 代码；

• 手册：参数说明、版本变更、已知坑、最佳实践（匹配你的岗位：手册结构化项目）

3.Demo 示例：提供示例工程，业务快速上手。

4.版本管理 ：语义化版本号主版本.次版本.修订号，写 CHANGELOG，记录每版本新增 / 修改 / 废弃内容。

六、测试

1. 单元测试：核心逻辑全覆盖。

2. 集成测试：在不同业务场景验证。

3. 兼容性测试：多版本 Spring、JDK 验证。

4. 压力测试：高并发场景验证性能、内存泄漏。

七、发布与运维

1. 灰度发布：组件升级后，业务可以逐步灰度接入。

2. 问题排查：支持动态开关，业务可临时关闭组件能力，快速降级。

3. 问题反馈通道：业务使用组件遇到问题，可快速定位是业务问题还是组件本身 bug。

高频深挖面试追问

Q1：公共组件最大的坑是什么？

依赖冲突，API 不兼容。升级组件版本导致业务项目启动报错。所以要控制传递依赖，严格保证 API 向前兼容。

Q2：组件什么时候抛出异常，什么时候降级返回？

提供配置开关，业务可选。默认：严重故障快速失败；非核心能力可配置降级，保证主流程不中断。不能内部静默吞异常，业务无法感知故障。

Q3：组件怎么做扩展，不频繁改组件源码？

使用 SPI 策略模式、钩子接口。业务自定义实现类，通过配置注入，不用修改组件代码。

Q4：公共组件日志怎么设计，防止日志爆炸？

关键信息 INFO，调试信息 DEBUG；限制大对象打印；支持全局日志开关，避免大量日志打满磁盘。

Q5：公共组件版本号规范？

语义化版本 MAJOR.MINOR.PATCH。 MAJOR：不兼容 API 变更；MINOR：新增功能，向前兼容；PATCH：bug 修复。

一句话背诵总结

公共组件开发遵循单一职责、低侵入；重点做好 API 向前兼容、依赖管控防止 jar 冲突；

完善异常处理、资源回收；增加日志、埋点监控；配套文档 Demo 与版本变更记录；

单元 + 集成 + 压测保障稳定性；预留 SPI 扩展点，支持业务自定义，故障可降级隔离，避免组件故障拖垮业务。

2. CodeReview 核心检查点【匹配岗位：配合项目经理 CodeReview，保障交付质量】

面试背景：你的岗位要求参与 CodeReview，保证交付质量。

CR 不是找 bug，是规范、安全、性能、可读性、可维护性、异常边界全维度把关。

一、业务逻辑层（最先看）

1. 是否正确理解需求，逻辑和产品需求一致

2. 边界场景是否处理：空值、入参非法、分支遗漏

3. 幂等性：重复调用会不会产生脏数据（新增、扣款、消息消费）

4. 事务范围：事务粒度是否合理，事务内禁止远程调用、耗时操作

5. 并发场景：多线程、并发更新是否存在竞态问题

6. 数据一致性：是否存在数据漏更新、部分更新

二、代码规范 & 可读性

1. 命名：类、方法、变量见名知意，禁止拼音、无意义简写（a,b,temp）

2. 注释：复杂逻辑写注释；不要写重复代码的注释；废弃代码直接删除，不要注释保留

3. 方法长度：单个方法不要过长，单一职责；过长方法要拆分

4. 常量：魔法数字、固定字符串抽取常量，禁止硬编码

5. 重复代码：重复逻辑抽公共方法 / 公共组件，不要复制粘贴

6. 分支：if/else 嵌套不能太深，优先卫语句减少嵌套

7. 格式：代码格式化，缩进、空行统一，遵循团队编码规范

三、异常处理

1. 是否捕获宽泛异常 catch(Exception e)，吞掉异常不打印日志

2. 异常捕获范围是否过大，不该捕获的异常不要捕获

3. 异常日志：日志是否打印堆栈，入参信息，方便排查；不要只打印 e.getMessage ()

4. 抛出异常：自定义业务异常，不要直接抛出原始 Exception

5. finally 资源释放：IO、连接等资源是否关闭；推荐 try-with-resources

四、性能检查点（Java 后端重点）

1. 数据库 SQL：避免 select *；禁止大 offset 分页；索引是否存在；in 集合不能过大；禁止隐式类型转换导致索引失效

2. 循环内部：禁止循环内查 DB、Redis；循环创建大量对象

3. 集合使用：预估容量初始化 HashMap，减少扩容；大集合注意内存占用

4. 线程池：线程池参数合理，不要手动 new Thread；线程池资源是否释放

5. 锁：锁粒度是否过大；锁内部是否有慢查询 / 远程调用；避免死锁风险

6. 对象创建：避免循环频繁创建对象，减少 GC 压力

7. 序列化：大对象序列化耗时评估

五、安全检查点

1. SQL 注入：使用 Mybatis #{}，禁止 ${} 拼接 SQL

2. XSS：前端输入做转义；接口返回特殊字符处理

3. 权限校验：接口是否做权限判断，越权访问（水平 / 垂直越权）

4. 敏感信息：手机号、身份证、密码日志脱敏，不能明文打印

5. 输入校验：所有入参校验（非空、长度、格式），防御脏数据

6. 接口防刷：高频接口是否限流

六、依赖、资源与连接池

1. 新增依赖：引入新 jar 是否必要，版本是否冲突

2. 连接池：Redis、DB、http 连接池配置合理；用完及时归还连接

3. 资源释放：流、连接、句柄，避免内存泄漏

4. 配置：硬编码配置抽至配置文件，不要写死代码

七、可观测性（日志、监控）

1. 关键链路是否打印日志，日志级别合理，INFO 不要泛滥

2. 耗时接口、核心方法是否埋点 metrics，监控成功率、耗时

3. 错误场景是否告警，异常事件上报

八、测试相关

1. 单元测试：核心逻辑、边界 case 是否补充单元测试

2. 有没有考虑回滚方案；变更是否支持灰度

3. 是否存在影响其他模块的改动，评估影响范围

九、架构 & 公共组件相关（适配你的岗位）

1. 是否复用现有公共组件，重复造轮子

2. 公共组件调用方式是否正确，参数配置是否符合组件文档

3. 修改公共组件：评估改动是否影响其他业务，保证向前兼容

CR 禁止的典型坏味道（快速背诵）

1. 捕获异常后只 return，不打日志，静默失败

2. 事务里面调用第三方 http 接口

3. 循环中查询数据库 /redis

4. 魔法数字、无意义命名

5. 注释掉的代码直接提交到仓库

6. select *、大分页、不走索引 SQL

7. 不做入参校验，直接使用入参

8. 直接 new Thread，不使用线程池

高频深挖面试追问

Q1：CodeReview 重点关注什么，优先看哪块？

优先业务逻辑正确性和边界场景；其次并发、安全、性能；再看可读性和规范。如果逻辑错，代码写再漂亮也没用。

Q2：CR 发现代码写的不优雅，但是功能没问题，怎么处理？

区分阻断项和优化项。逻辑 bug、安全问题、性能隐患是阻断项，必须修改才能合并；单纯代码美化可以标记为优化项，允许后续迭代重构，不阻塞本次上线。

Q3：CR 时怎么评估改动影响范围？

看修改的类和方法，梳理调用链路；判断是否被其他模块依赖，公共组件改动要评估全业务影响，必要时联动多业务测试。

Q4：为什么禁止 catch (Exception) 空吞异常？

异常被吞，没有日志堆栈，线上故障无法定位问题，请求看似成功实际逻辑异常。

Q5：公共组件代码 CR 要额外关注什么？

重点关注 API 兼容性、依赖冲突、故障隔离，改动会不会影响其他业务项目，配套文档是否同步更新。

一句话背诵总结

CodeReview 从业务逻辑、边界幂等入手；检查代码可读性、异常处理、SQL 性能；关注安全、入参校验、敏感信息脱敏；

核查连接池、线程池、资源释放；补充日志埋点与单元测试；

区分阻断 bug 和代码优化项；公共组件改动重点评估兼容性与跨业务影响。

3. 技术选型评估维度【匹配岗位：参与项目可行性分析、立项、技术选型】

面试场景：项目立项、可行性分析，怎么挑选框架 / 中间件 / 组件；不是只看功能，要结合业务、团队、运维、成本综合评估。

一、业务需求匹配度（首要评估点）

1. 功能匹配：是否满足当前业务核心能力；是否覆盖未来一段时间（1~3 年）业务发展。不需要的复杂能力不盲目引入，避免过度设计。

2. 性能指标：吞吐量、响应时间、并发能力；是否满足 QPS、RT 要求。

3. 场景适配：强一致性 / 最终一致性；是否需要持久化；是否支持异步、批量处理；是否需要高可用。

4. 扩展性：业务增长后，能否横向扩容，支撑数据量、流量上涨。

二、可用性与稳定性

1. 高可用：集群部署、故障转移、主从切换；单点风险评估。

2. 容错能力：故障降级、重试、熔断；节点宕机后数据是否丢失。

3. 故障恢复：故障定位难度、数据备份、恢复 RTO/RPO 指标。

4. 成熟度：社区活跃度、版本稳定性；是否大规模生产落地。避开冷门、停止维护的技术。

三、兼容性与集成成本

1. 语言 / 框架兼容：能否和现有技术栈（SpringBoot、SpringCloud）无缝集成。

2. 版本兼容：和现有中间件、JDK 版本是否冲突；是否会带来依赖包冲突。

3. 侵入性：接入后对业务代码侵入程度；替换成本，后续想切换其他组件改造成本高不高。

4. 迁移成本：存量数据迁移难度、双写、灰度切换方案。

四、团队成本（非常高频考点）

1. 学习成本：团队是否掌握这项技术；学习曲线陡峭程度。

2. 维护成本：后续谁负责维护；排查问题难度。

3. 人力：是否需要专门运维人员；出现问题能不能快速定位解决。

4. 培训：是否需要组织团队培训，文档资料是否丰富。

五、运维 & 可观测性

1. 监控指标：是否暴露 metrics，支持接入 Prometheus、Grafana。

2. 日志、链路追踪：日志规范，支持 SkyWalking/Pinpoint 链路埋点。

3. 告警能力：支持配置告警，故障提前感知。

4. 运维复杂度：部署、扩容、升级、备份是否简单；资源占用（CPU / 内存）。

六、安全

1. 权限控制：账号、密码、访问鉴权，最小权限。

2. 数据安全：传输加密、存储加密；敏感数据保护。

3. 漏洞：历史安全漏洞，版本是否持续修复安全补丁。

七、生态与社区

1. 社区活跃度：issue 响应、更新频率。

2. 生态：周边工具、文档、案例、解决方案。

3. 技术支持：开源社区支持；商用版是否有厂商兜底。

八、成本评估

1. 资源成本：服务器、内存、磁盘资源消耗。

2. 许可证：开源协议是否合规，是否存在商业版权风险。

3. 人力成本：开发、测试、运维人力投入。

九、风险评估 & 备选方案

1. 识别风险点：性能瓶颈、稳定性隐患、团队不熟悉、社区停止维护。

2. 降级备选：主方案不可行，备选方案是什么。

3. 回滚方案：上线出问题，是否能快速回退。

高频深挖面试追问

Q1：技术选型优先级怎么排？

业务需求匹配 > 稳定性可用性 > 团队维护成本 > 运维可观测性 > 生态成本；不要单纯追求新技术。

Q2：新技术很炫酷，但是团队没人懂，怎么评估？

风险偏高。如果业务不是强需求，优先选团队熟悉的成熟技术；如果必须引入，要评估学习周期、试点项目、备选方案，灰度试点，不能直接全量上线。

Q3：技术选型为什么要准备备选方案？

防止主方案出现未预估问题（性能不达标、bug、社区停更），出现问题可以切换备选方案，保障项目交付。

Q4：RTO、RPO 是什么？

RTO：恢复时间目标，故障后业务多久恢复；RPO：恢复点目标，故障允许丢失的数据量。高可用选型重点看这两个指标。

Q5：引入中间件，怎么评估会不会过度设计？

只看未来 1-3 年业务，不预估太远的流量；如果当前业务简单，引入重组件带来大量运维成本，就是过度设计，优先轻量方案。

一句话背诵总结

技术选型优先评估业务匹配度与性能；考察高可用、故障恢复能力；

评估和现有技术栈兼容性、代码侵入度；

重点考量团队学习、维护人力成本；配套监控、日志等可观测能力；

评估安全、资源、版权成本；识别风险，准备备选和回滚方案，不盲目追新。

4. 线上故障标准处理流程

优先止损（降级/回滚）→ 现象确认 → 日志定位根因 → 修复验证 → 复盘优化。

5. 限流、熔断、降级区别

核心一句话总纲：限流保护自身；熔断保护调用方；

降级牺牲非核心，保住主业务。三者都是高可用保护手段，触发时机、目标对象不一样。

一、限流（保护自己）

定义 ：限制请求流量，防止大量请求压垮当前服务。保护本服务，拒绝超额流量。

• 触发条件：请求量超过预设阈值（QPS、并发数）

• 作用对象：进入当前服务的流量

• 核心思想：多余请求直接拒绝，不让请求进来

• 常见算法：计数器、滑动窗口、漏桶、令牌桶

• 返回：返回限流提示，快速失败

• 例子：接口限制 QPS=200，超过直接返回 "请求过于频繁"

二、熔断（保护调用方，防止雪崩）

定义 ：调用下游服务连续失败达到阈值，触发熔断，不再继续调用故障下游，快速返回，避免请求堆积拖垮调用方，防止雪崩。

• 触发条件：调用下游失败率 / 超时率到达阈值

• 作用对象：依赖的下游服务

• 核心思想：下游坏了，切断对下游的调用

• 状态机：关闭→打开→半开→关闭

  • 关闭：正常调用下游

  • 打开：熔断开启，直接不走远程调用

  • 半开：等待冷却时间，放少量探测请求验证下游是否恢复；成功则关闭熔断，失败继续打开

• 例子：调用订单服务连续超时，熔断打开，不再请求订单服务

三、降级（牺牲次要，保核心业务）

定义 ：流量突增或依赖异常时，主动关闭 / 简化非核心功能，释放资源保障核心链路正常运行。

• 触发条件：流量大、资源紧张、依赖异常，人工或自动触发

• 作用对象：本服务非核心业务逻辑

• 核心思想：丢卒保车，关闭不重要接口，保住主流程

• 分类：

  • 自动降级：超时、失败触发

  • 人工降级：大促前手动关闭非核心功能

• 例子：大促时关闭商品评论、推荐，保障下单支付主流程

四、三者横向对比（背诵表格）

表格

|------|---------------|---------------|---------------|
| 维度 | 限流 | 熔断 | 降级 |
| 保护目标 | 保护自身 | 保护调用方，防止雪崩 | 保护核心业务 |
| 触发原因 | 流量超过阈值 | 下游调用失败 / 超时过多 | 流量高、资源不足、依赖异常 |
| 针对对象 | 入站流量 | 下游依赖服务 | 自身非核心逻辑 |
| 手段 | 拒绝多余请求 | 切断对下游调用 | 关闭 / 简化非核心功能 |
| 是否恢复 | 持续限流，流量下降自动放开 | 冷却后半开探测恢复 | 人工 / 自动恢复功能 |

五、高频深挖面试追问

Q1：雪崩是什么？三者怎么协同防止雪崩？

雪崩：A 调用 B，B 调用 C；C 故障，B 请求堆积线程耗尽，进而 A 也被拖垮，连锁故障。

• 限流：挡住超大流量，不让大量请求进入系统

• 熔断：下游故障，快速切断调用，不继续等待占用线程

• 降级：关掉非核心功能，腾出资源给核心接口

协同顺序：网关限流 → 服务内熔断 → 业务降级

Q2：熔断和降级最容易混淆点在哪？

熔断：下游服务挂了，不调用下游 ； 降级：我主动关掉自己非核心逻辑。 熔断是被动保护；降级可以主动预案。

Q3：限流常用算法对比？

1. 固定计数器：简单，临界时间点存在突刺漏洞

2. 滑动窗口：平滑统计，Sentinel 默认

3. 漏桶：匀速流出，削峰；无法应对突发流量

4. 令牌桶：可预存令牌，允许一定突发流量，网关常用

Q4：Sentinel 中三者怎么实现？

Sentinel 同时支持：限流（流量规则）、熔断（熔断降级规则，异常比例 / 超时）、降级。

Q5：熔断半开状态作用？

不能永久断开下游；等待冷却窗口，放少量探测请求验证下游是否恢复。探测成功关闭熔断，失败继续熔断。

一句话背诵总结

限流限制流入流量，保护自身；熔断在下游故障时切断调用，避免服务雪崩；

降级主动舍弃非核心业务保障主流程；

网关先限流，服务内部熔断，业务层降级，三层防护保障微服务高可用。