近期常文的高频问题

八股文：

八股文面试技巧： 1.提前熟悉网页上对应的八股文的位置 2.快速定位到对应的八股文，用自己的话语去讲解 3.针对不熟悉的八股文，提前多打开几个界面

场景题：

回答技巧： 1.先听明白面试官想听什么，再做回答，如果没听明白，可以让面试官再讲解一遍 2.尽可能的往我们所学的技术栈上去靠拢，讲底层的先讲基本概念，讲在项目中怎么使用的 3.可以从业务层面去讲设计，哪样子跟现实生活场景匹配就答哪个 4.不能答非所问 5.要学会去思考，不要紧张，按照自己的理解和想法去作答 6.问到不会的问题，没关系，复盘下来，整理答案，作为下次面试的问题去和面试官沟通

系统规模类问题

一、系统规模类问题回答参考（用户量 / QPS / 数据量）：

核心原则：

1. 口径统一：记住自己说的数字，后续所有技术方案（如 Redis 容量、分库分表策略）必须能支撑得起这个数据量。
2. 合理推算：学会从日活（DAU）推导峰值 QPS，从订单量推导表数据量，让面试官感觉你的数据是“算出来的”，而不是“编出来的”。
3. 适度包装：在真实项目基础上乘以 3-5 倍是安全的，但不要夸大到自己无法解释的水平（例如单表说 10 亿条却说没分表）。

参考数据（根据工作经验调整）：

工作经验	用户量（注册用户/日活）	秒杀/大促峰值 QPS	核心订单/业务表数据量	数据库集群规模
1-3 年	10万 ~ 50万 / 1万 ~ 5万	1,000 ~ 3,000	百万级 ~ 千万级	主从（1主1从）
3-5 年	50万 ~ 500万 / 5万 ~ 30万	5,000 ~ 20,000	千万级 ~ 亿级	主从或分库分表（4~8个实例）
5 年以上	500万以上 / 50万以上	2万以上	亿级 ~ 十亿级	分库分表 + 读写分离（10+ 实例）

不同业务场景的侧重点：

• 电商（商城）：重点讲秒杀 QPS、订单表数据量、库存扣减一致性。订单表通常是数据量最大的表。
• 医疗（HIS/互联网医院）：重点讲挂号并发量、电子病历/影像文件存储量（非结构化数据）。高峰通常在上午 8-10 点。
• 新能源（充电桩）：重点讲设备并发上报（MQTT/长连接）、订单流水、计费结算数据。QPS 相对平稳，但并发连接数高。
• AI / 大数据：重点讲日增数据量（TB/GB 级别）、模型训练样本量、接口调用并发（如文生图、大模型 API）。

数据推算逻辑（面试时可主动说出来，显得专业）：

1. 从 DAU 算 QPS：
   • 假设日活 10 万人，平均每人产生 20 次请求，总请求 200 万。
   • 80% 请求集中在白天 8 小时，即 160 万请求 / 28800 秒 ≈ 55 QPS（均值）。
   • 峰值通常是均值的 5-10 倍，即 300 ~ 500 QPS。秒杀场景再乘以 10，即 3000 ~ 5000 QPS。
2. 从订单量算表数据量：
   • 假设日活 10 万，转化率 5%，日订单 5000 单。
   • 一年订单：5000 * 365 ≈ 180 万。
   • 3 年积累：约 500 ~ 600 万 数据，这时候必须考虑分库分表或归档。

常见追问及应对：

• 问：“你们 Redis 集群多大？” 答：根据热数据量来。比如缓存用户会话（10万日活 * 2KB）约 200MB；缓存商品详情（1万 SKU * 5KB）约 50MB。总量几百 MB 到几个 GB 都是合理的，说“4 主 4 从，总共 16GB 内存”即可。
• 问：“MySQL 单表多少数据会慢？” 答：InnoDB 单表千万级（1000万~2000万）以下性能较好，超过后 B+ 树层级变深，查询和 DDL 会变慢，所以我们通常在千万级做分表。
• 问：“你们的 GC 情况怎么样？” 答：根据堆内存大小。比如 4G 堆，使用 G1，Young GC 几十毫秒，Full GC 几乎不发生（或发生频率极低，如一周一次且可控）。

二、服务器与部署类问题回答参考（机器数量 / 配置 / 部署架构）：

核心原则：

1. 数量与 QPS 匹配：应用服务器的数量必须能支撑你之前提到的峰值 QPS，且要预留 30%-50% 的冗余。
2. 配置与业务类型匹配：CPU 密集型（如视频转码、复杂计算）侧重 CPU 核数；内存密集型（如缓存中间件、Java 应用）侧重内存大小。
3. 混合部署与独立部署：中小型项目可以混合部署（MySQL 和应用在同一台或同一批机器）；大型项目必须独立部署，甚至中间件（Redis、MQ）也要独占机器。

参考数据（根据工作经验调整）：

工作经验	应用服务器数量	单台配置（CPU/内存/带宽）	数据库/中间件部署方式	部署环境
1-3 年	2 ~ 4 台	4核8G / 5M带宽	MySQL 主从共 2 台；Redis 单实例或主从 1~2 台	单体或少量微服务，可混合部署
3-5 年	4 ~ 10 台	8核16G / 10M带宽	MySQL 分库分表 4+ 实例；Redis Cluster 3主3从	微服务拆分，核心业务独立部署
5 年以上	10+ 台	16核32G+ / 20M+带宽	数据库按业务域拆分；中间件集群化部署	容器化（K8s）部署，全链路独立

服务器数量推算逻辑（面试时可主动展示计算过程）：

1. 从峰值 QPS 算 Tomcat 线程数：
   • 单机 Tomcat 线程池通常配置 200~500。假设一个接口平均响应时间 200ms。
   • 单机理论 QPS = 线程数 / 平均响应时间(s) = 200 / 0.2 = 1000 QPS。
   • 考虑到 CPU 利用率不超过 70%，以及非纯计算型接口，打个 5 折，单机安全 QPS ≈ 500。
2. 算所需机器数：
   • 假设秒杀峰值 QPS 为 5000，单机支撑 500，则至少需要 5000 / 500 = 10 台应用服务器。
   • 再考虑一台挂掉的容灾情况，向上取整并加 1~2 台冗余，最终报 12 ~ 15 台 是非常稳妥且专业的回答。

常见部署架构说法：

• 单体应用（1-3年经验）：Nginx 做反向代理和负载均衡，后端 2~4 台 Tomcat，MySQL 一主一从。简单、清晰、易维护。
• 微服务（3-5年经验）：Gateway 网关层 2 台；核心业务服务（如订单、支付）各 2~4 台；非核心服务（如通知、日志）1~2 台。共 8~12 台。使用 Nacos 做注册中心，Sentinel 做限流。
• 容器化（5年以上经验）：K8s 集群，Master 节点 3 台（高可用），Node 节点 10+ 台。应用打成 Docker 镜像，通过 Deployment 管理副本数，HPA 根据 CPU/内存自动扩缩容。

常见追问及应对：

• 问：“你们用的是什么服务器？物理机还是云服务器？” 答：绝大多数互联网项目使用云服务器（阿里云 ECS、腾讯云 CVM）。开发测试环境用低配共享型，生产环境用独享型或计算型。如果项目对数据安全要求极高（如金融、政务），可能会采用私有云或自有机房物理机。
• 问：“你们的带宽是多少？够用吗？” 答：根据业务类型。普通 Web/API 接口，按峰值 QPS * 平均响应体大小（如 5KB）计算。5000 QPS * 5KB = 25MB/s，即约 200Mbps（25MB/s * 8）。所以报 100M ~ 200M 带宽是合理的。如果是图片/视频类业务，带宽需求会大得多，通常配合 CDN 和对象存储（OSS）来使用。
• 问：“你们有没有做异地多活？” 答：中小型项目通常是“异地灾备”而非“异地多活”，即另一个城市有备份机房，平时不对外提供服务，主机房挂了再切换。大型项目（如支付宝、12306）才会做真正的异地多活，成本和复杂度极高。如果你包装的不是顶级大厂项目，回答“同城双活 + 异地灾备”是比较稳妥的。
• 问：“你们的监控和报警怎么做的？” 答：基础监控用 Prometheus + Grafana 采集服务器 CPU、内存、磁盘、网络；应用监控用 SkyWalking 或 Pinpoint 做链路追踪；日志收集用 ELK（Elasticsearch + Logstash + Kibana）或 Loki；报警用 Alertmanager 或企业微信/钉钉/飞书机器人推送。关键是要体现“出问题能先知道，再快速定位”。

人员规模类

一、项目周期与团队分工类问题回答参考（开发周期 / 团队人数 / 个人职责）：

核心原则：

1. 周期与项目规模匹配：不要一个小模块说做了半年，也不要一个完整的电商平台说只做了一个月。周期要符合常理。
2. 人数与工作量匹配：团队人数要能覆盖需求分析、UI设计、前端、后端、测试、运维等工作。不要出现一个 10 人团队却只有 1 个后端开发的情况。
3. 突出个人贡献：说清楚自己在团队中的角色，负责了哪些核心模块，解决了什么技术难点，避免说“我们团队做了”而面试官听不出你具体干了什么。

参考数据（根据工作经验调整）：

工作经验	项目总周期	团队总人数	后端开发人数	个人负责模块数	开发模式
1-3 年	3 ~ 6 个月	5 ~ 10 人	2 ~ 3 人	2 ~ 4 个模块	敏捷开发（2周一个迭代）
3-5 年	6 个月 ~ 1 年	10 ~ 20 人	3 ~ 6 人	3 ~ 6 个模块，或一个子系统	敏捷开发，有专职运维/测试
5 年以上	1 年 ~ 2 年	20 人以上	6 ~ 15 人	一个核心系统或技术负责人	敏捷 + 部分瀑布，多团队协作

如何解释“开发周期为什么这么久”： 面试官问这个问题，通常是怀疑你的项目不真实，或者想考察你对项目复杂度的理解。不要只说“需求多”或“老板要求的”，要从技术或业务角度给出合理拆分：

1. 需求调研与评审占 20%：前期需要和产品经理反复确认业务流程，特别是电商的库存、优惠、退款规则，医疗的医保对接、病历规范，这些都需要和多方确认。
2. 技术选型与架构设计占 15%：团队需要论证技术方案，比如选型微服务还是单体，数据库是否分库分表，缓存策略怎么设计，这些都需要做技术评审和压测验证。
3. 核心功能开发占 40%：这是主要工期。可以强调某些模块的复杂度，例如支付对接第三方支付渠道（微信、支付宝）、退款原路返回、对账；或者秒杀场景下的库存扣减、防超卖、限流降级。
4. 测试与修复占 20%：包括单元测试、接口测试、集成测试、性能测试（压测）、安全测试（渗透测试、SQL 注入扫描）。生产环境的 Bug 修复和回滚方案演练也算在内。
5. 上线与验收占 5%：灰度发布、数据迁移、线上监控配置、用户培训等。
6. 多产品端迭代占额外周期：项目上线后，业务方要求拓展多端场景，例如从主站 Web 扩展到微信小程序、H5、App、商家管理后台、运营后台等。每个端都需要独立的接口适配、权限设计、UI 联调和发布流程，相当于把同一套业务逻辑重复实现多次，显著拉长了整体维护周期。
7. 人员变动与兼项导致周期碎片化：项目进入稳定期后，团队其他成员被抽调去做新项目，后期主要由我一个人负责核心维护。同时我也需要兼顾公司其他项目的需求开发和线上问题处理，很难把所有时间投入在一个项目上。此外，还会参与一部分运营侧工作，比如配合运营人员配置活动规则、处理数据报表、排查用户投诉相关的数据问题，这些事务性工作虽然不直接产出代码，但也占用了大量时间。

团队角色分工（让面试官感觉团队是正规的）：

• 产品经理（1-2人）：负责需求文档（PRD）、原型图、和业务方对接。
• UI/前端工程师（2-3人）：负责页面设计、H5/小程序/App 界面开发。
• 后端工程师（2-6人）：负责接口开发、数据库设计、核心业务逻辑。
• 测试工程师（1-2人）：负责写测试用例、接口测试、性能测试、回归测试。
• 运维/DevOps（1人，3年以上项目通常有）：负责服务器搭建、CI/CD 流水线、线上监控、故障处理。
• 项目经理（可选，大厂或外包项目常有）：负责排期、跟进进度、协调资源。

个人职责描述模板（STAR 法则）：

• Situation（背景）：这个项目是一个 XXX 平台，主要解决 XXX 问题，团队共 X 人，我负责后端开发。
• Task（任务）：我主要负责 XXX 模块（如：订单系统、支付系统、用户中心），需要完成 XXX 功能（如：秒杀下单、退款审核、第三方登录）。
• Action（行动）：我使用了 XXX 技术（如：Spring Cloud、Redis 分布式锁、RocketMQ），做了 XXX 设计（如：数据库分库分表、接口限流、异步解耦）。
• Result（结果）：最终该模块支撑了 XXX 并发（如：5000 QPS），上线后运行稳定，没有出现 P0 级故障。

常见追问及应对：

• 问：“这个项目你具体做了什么？有没有遇到什么难点？” 答：挑一个你最有把握的模块详细讲，重点讲技术难点和如何解决。例如：“我负责秒杀模块，难点是防超卖和限流。我使用了 Redis 分布式锁 + 令牌桶限流，最终压测通过了 5000 QPS，且库存数据一致性没有问题。”

• 问：“你们是怎么协作的？用的是什么工具？” 答：需求管理用 Jira 或禅道；代码管理用 Git + GitLab，采用 Git Flow 或主干开发分支发布模式；接口文档用 Swagger 或 YApi；沟通用钉钉/飞书/企业微信，每天早上站会同步进度。

• 问：“如果需求变更了怎么办？” 答：小需求变更在当前迭代内评估工时，如果影响大则移到下一个迭代；大需求变更需要产品重新出 PRD，技术重新评估，走变更审批流程。我们团队一般不允许无审批的临时插入需求，否则会打乱开发节奏。

• 问：“你们有没有加班？怎么看待加班？” 答：项目上线前或紧急 Bug 修复时会加班，这是正常的。但平时我们讲究效率，通过合理的迭代计划和需求评审来减少无效加班。如果面试官追问“996吗”，可以回答“项目紧的时候会有阶段性加班，但不是常态”，既真实又不得罪人。

• 问：“如果重新做这个项目，你会怎么优化？” 答：这是一个送分题，可以从技术债、架构设计、开发流程三个角度说。例如：“如果重新做，我会在初期就引入分布式链路追踪，方便后续排查问题；会把某些强耦合的模块提前拆成微服务；会在设计阶段就把压测方案定下来，而不是上线前才压测。”

• 问：“你对团队做过哪些贡献？” 答：这个问题考察你的主动性、技术影响力和团队协作意识。不要只说自己“写了很多代码”或“加班很多”，要体现技术价值和团队价值。以下是不同经验层次可以参考的方向：

  • 技术优化与性能提升：
    • 初级（1-3年）：“我发现订单查询接口响应很慢，通过分析慢 SQL 发现缺少索引，添加索引后查询时间从 2 秒降到 50 毫秒。”
    • 中级（3-5年）：“我主导了 Redis 缓存改造，把热点数据接入缓存，数据库查询压力降低了 60%，接口平均响应时间从 500ms 降到 80ms。”
    • 高级（5年以上）：“我推动全链路压测常态化，建立了性能基线，每次大促前必须压测通过才能上线，避免了两次线上因容量不足导致的故障。”
  • 代码质量与规范：
    • “我发现团队代码风格不统一，提交了 Checkstyle 规则文件并集成到 CI 流水线，代码 Review 效率提升了 30%。”
    • “我整理了团队常见的 20 个 SQL 注入和 XSS 漏洞案例，组织了安全编码培训，后续安全测试发现的漏洞数减少了 50%。”
  • 工具与效率提升：
    • “我搭建了一套基于 Jenkins + Docker 的自动化部署流水线，把原来手动部署 30 分钟缩短到 5 分钟，且避免了人为操作失误。”
    • “我写了一个接口文档自动生成工具，替代了原来手写文档的方式，前后端沟通成本降低了很多。”
  • 知识沉淀与分享：
    • “我整理了项目的核心业务逻辑文档和数据库字典，新人入职后上手时间从 2 周缩短到 3 天。”
    • “我在团队内部组织了 5 次技术分享，主题包括分布式锁、消息队列幂等设计、JVM 调优等。”
  • 跨团队协作：
    • “我主动对接了第三方支付和物流接口，梳理了对接文档和异常处理清单，避免了因第三方接口变动导致的线上故障。”
    • “我协助运维团队制定了数据库备份和恢复方案，并参与了两次灾备演练。”
  • 带新人与培养：
    • “我作为导师带了两名实习生/应届生，帮助他们快速熟悉项目和技术栈，其中一名在 3 个月后能独立负责模块开发。” 关键点：无论说哪类贡献，尽量用数据量化（时间降低 XX%、效率提升 XX%、Bug 减少 XX%），并且确保这个贡献是真实的、你能讲清楚细节的。面试官很可能会追问“具体怎么做的”“遇到什么困难”。

• 问：“你们是怎么测试和发布上线部署的？” 答：这是一个综合性问题，面试官想考察你对软件工程流程、质量控制和风险控制的理解。回答时要体现出流程的规范性和对线上事故的敬畏心。可以按“测试流程 → 环境管理 → 发布策略 → 回滚预案”四个层次来组织语言。

  测试流程（层层把关）：

  1. 单元测试（开发阶段）：开发人员在写业务代码的同时编写 JUnit 单元测试，要求核心逻辑的覆盖率不低于 60%~80%，通过 SonarQube 做静态代码扫描，阻断明显的问题（如空指针、SQL 注入风险）。
  2. 接口测试（联调阶段）：前后端联调完成后，使用 Postman 或 Apifox 编写接口测试集，覆盖正常流程和异常流程（如参数缺失、权限不足、重复提交）。
  3. 集成测试（提测阶段）：测试环境把各个模块串联起来跑主流程，例如电商的“下单 → 支付 → 减库存 → 发消息”全流程，验证模块间数据一致性。
  4. 性能测试（上线前）：对核心接口做压测，使用 JMeter 或阿里云 PTS，目标是验证系统是否能支撑之前说的峰值 QPS，同时观察 CPU、内存、数据库连接池、Redis 连接数是否健康。
  5. 安全测试（上线前）：使用 Burp Suite 或公司安全团队提供的扫描工具，检查 SQL 注入、XSS、越权访问等常见漏洞。
  6. 回归测试（每次发版前）：测试团队维护一套核心的回归用例集，每次发版前必须全部跑通，防止新功能影响旧功能。
  7. UAT 验收测试（可选）：部分 B 端项目或外包项目需要客户/业务方在预发布环境实际操作验收，确认无误后才允许上线。

  环境管理（四道关卡）：

  • 开发环境：开发人员本地或共享开发机，数据随意，用于日常开发和自测。
  • 测试环境（SIT）：与生产环境架构一致但配置略低，用于测试团队执行系统测试和集成测试。
  • 预发布环境（Staging/UAT）：与生产环境完全一致（同版本数据库、同版本中间件、同配置），用于最终验收和发布前的彩排。部分公司会直接使用生产环境的只读副本或影子库。
  • 生产环境（Production）：正式对外提供服务的机器，严格管控权限，开发人员通常只有日志查看权限，没有操作权限。

  发布上线策略（由低到高，对应不同经验层次）：

  • 手动发布（1-3年经验，小公司常见）：开发打包后发给运维，运维手动替换 jar 包、改配置、重启服务。缺点是容易出错，优点是简单直接。
  • 脚本化发布（1-3年经验）：使用 Shell 脚本或 Python 脚本，一键完成备份、停服务、替换包、启动服务。降低了人为失误，但缺乏回滚机制和审计。
  • 蓝绿部署（3-5年经验）：准备两套完全一样的环境（蓝环境和绿环境），一套对外提供服务，另一套部署新版本。验证通过后，通过 Nginx 或 Gateway 瞬间切换流量。优点是回滚极快（切回来即可），缺点是资源成本翻倍。
  • 滚动发布（3-5年经验）：集群中有 10 台机器，先逐台重启 2 台部署新版本，观察没问题再继续下一批，直到全部更新。优点是节省资源，缺点是发布过程中新老版本共存，可能出现兼容性问题。
  • 灰度发布 / 金丝雀发布（3-5年以上经验）：先切 5% 的流量到新版本，观察监控指标（错误率、响应时间、业务数据）30 分钟~几小时，没有问题再逐步扩大到 20%、50%、100%。这是目前大厂最常用的方式，风险最小，发现问题时影响面可控。

  回滚预案（必须准备）：

  • 任何上线操作前，必须先备份（代码包备份、数据库备份、配置文件备份）。
  • 蓝绿部署：流量切回旧版本即可。
  • 滚动/灰度发布：如果问题严重，立即停止扩大灰度范围，紧急回滚到上一个稳定版本的镜像或代码包。
  • 数据库变更是最危险的：DDL 操作（如加字段、加索引）尽量采用 Online DDL 工具（如 pt-online-schema-change），且必须在业务低峰期执行；DML 变更（如初始化数据）必须提前在预发布环境验证。
  • 上线后观察期：通常保留 30 分钟~2 小时的观察期，期间核心开发人员必须在线，监控报警群里没有异常告警才算发布成功。

  上线 Checklist（面试时可以提一下，显得专业）：

  • [ ] 代码已合并到发布分支，且 CI 流水线全部通过
  • [ ] 测试用例（含回归用例）全部通过
  • [ ] 核心接口压测通过，性能基线未下降
  • [ ] 数据库变更脚本已在预发布环境执行并验证
  • [ ] 配置中心（如 Nacos/Apollo）的参数已确认
  • [ ] 回滚方案已明确，回滚包/回滚脚本已准备
  • [ ] 业务方/产品经理已确认可以上线
  • [ ] 上线期间值班人员已安排