这篇原本是一些零散面试题笔记。问题本身不差但如果只是把答案堆在一起读者很难带走东西。我把它重新整理成一套面试回答框架遇到问题时先确认现象再分层定位最后说清楚影响范围和解决价值。下面按常见面试题来整理。1. 如何确认一个 Bug不要一上来就说“页面报错了”“接口挂了”。确认 Bug 至少要回答四个问题能不能稳定复现是否符合需求预期问题属于哪一层影响范围有多大稳定复现一个合格的 Bug 描述应该包含操作步骤输入数据环境信息前置条件实际结果预期结果比如环境测试环境 v1.3.2账号普通用户步骤1. 登录系统2. 进入订单页3. 选择已取消订单4. 点击再次支付预期按钮不可点击或提示订单状态不允许支付实际进入支付页提交后接口返回 500这样的描述开发、测试、产品都能复现和讨论。如果只写订单支付有问题这个信息量太低。是否符合需求不是所有“看起来不对”的现象都是 Bug。要确认需求文档怎么写接口文档怎么定义历史版本行为是什么产品有没有特殊规则比如按钮置灰可能不是 Bug而是产品定义未实名认证用户不能发起提现。所以确认 Bug 的第一步不是甩锅而是确认“实际行为”和“预期行为”是否真的不一致。2. 如何定位一个 Bug 属于哪一层排查问题时可以按层次走前端页面- 请求参数- 接口返回- 后端日志- 数据库数据- 缓存/MQ/第三方服务- 环境配置举个例子登录失败。不要只说“登录不了”可以这样排1. 前端是否真的发起请求2. 请求地址和请求方法是否正确3. 参数是否包含 username/password/captcha/token4. 接口返回的是 401、403、400 还是 5005. 后端日志有没有异常6. 数据库里账号状态是否正常7. Redis 里的验证码/session/token 是否过期8. 是否只有某个环境失败这就是“分层排查”。面试时这样答比直接背“看日志、看接口”更有条理。3. HTTP 状态码怎么区分常见几个状态码可以这样理解| 状态码 | 含义 | 常见场景 || --- | --- | --- || 400 | 请求参数有问题 | 参数缺失、格式错误、字段类型不对 || 401 | 未认证 | 没登录、token 过期、没有携带凭证 || 403 | 已认证但无权限 | 登录了但角色权限不够 || 500 | 服务端程序异常 | 空指针、SQL 异常、代码未处理异常 || 503 | 服务暂时不可用 | 服务维护、限流、依赖服务不可用 |最容易混的是401和403401 你是谁我不知道。403 我知道你是谁但你不能访问。比如未登录访问后台接口 - 401普通用户访问管理员接口 - 403这个区分在登录、权限、网关排查里很常见。4. 登录功能无法登录怎么排查登录问题很适合用分层思路。可以按这个顺序页面输入- 前端校验- 请求参数- 验证码/session- 账号密码校验- token 生成- cookie/localStorage 写入- 后续接口是否携带凭证常见问题前端没有发请求请求参数字段名错了验证码过期账号被禁用密码加密方式前后端不一致后端生成 token 失败浏览器没有写入 cookie跨域导致 cookie 没带上面试回答可以这样组织我会先看浏览器 Network确认请求有没有发出去再看请求参数和响应状态码如果接口返回异常就结合后端日志和数据库账号状态排查如果登录接口成功但后续仍然未登录就重点看 token/cookie 是否写入以及后续请求是否携带凭证。这比一句“看日志”更像真实做过排查。5. left join、right join、inner join 怎么讲可以先用一句话inner join 取匹配成功的数据left join 保留左表全部数据right join 保留右表全部数据。假设有两张表userid name1 Tom2 Jackorderid user_id amount10 1 99inner joinselect *from user uinner join order o on u.id o.user_id;只返回能匹配上的数据Tom 有订单所以返回 Tom order。Jack 没订单所以不返回。left joinselect *from user uleft join order o on u.id o.user_id;左表user全保留Tom 有订单返回订单数据。Jack 没订单order 字段为 null。right joinselect *from user uright join order o on u.id o.user_id;右表order全保留。实际开发里left join更常见因为我们通常会从“主表”出发把关联表补上。6. 数据库索引怎么讲索引不是“让所有查询都变快”的魔法。更准确地说索引用额外的数据结构帮助数据库减少扫描范围。MySQL InnoDB 常见索引结构是 BTree。它适合磁盘存储的原因是树高相对低范围查询方便叶子节点有序每次查询可以减少大量无效扫描。常见索引类型主键索引 primary key唯一索引 unique普通索引 index联合索引 composite index全文索引 fulltext索引优点提高查询速度提高排序/分组效率提高连接查询效率保证唯一性索引缺点占用磁盘空间降低写入性能增加维护成本可能因为写法不当失效常见索引失效场景索引列上使用函数隐式类型转换like 以 % 开头联合索引不满足最左匹配OR 条件使用不当字段区分度太低使用 ! 或 导致优化器不走索引面试时不要只背“索引能加快查询”。最好补一句索引提升读性能但会牺牲写性能和空间所以要围绕高频查询、过滤条件、排序字段来设计。7. 印象最深的 Bug 怎么讲这个问题不要随便讲一个小 Bug。好的回答应该体现问题背景排查过程定位方法解决方案复盘收益可以套这个结构当时遇到的问题是……现象是……我先通过……确认复现路径然后从前端请求、接口返回、后端日志、数据库数据几层排查最后定位到……解决后我们补了……这件事让我意识到……重点不是 Bug 多复杂而是你能不能展示自己的排查思路。8. 总结这些题看起来很杂其实底层都在考同一件事你遇到问题时有没有结构化定位能力。可以记住这条主线先确认现象再判断预期然后分层定位最后评估影响和复盘。不管是 Bug、登录失败、状态码、SQL Join 还是索引面试官真正想看的都不是背诵而是你能不能把问题讲清楚。