全栈开发面试深挖 15 题
涵盖端到端架构、前后端契约、全链路性能调优、安全防御与高并发实战。
题目为高频真实问法;①②③ 三层答案为模拟示范,非真实面经
① 简历常见平淡回答
「后端写好 Swagger 接口文档发给前端,前端对着文档自己用 TypeScript 声明接口类型。」
手动维护两份契约极易发生数据模型漂移,缺少以单一事实来源(SSOT)自动生成端到端类型与运行时校验的工业化方案。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
我们采用 tRPC 或基于 OpenAPI / Protobuf 的代码生成工具作为单一事实源。后端更新接口 Schema 后,CI 自动提取类型并推送至前端共享 npm 包或 Monorepo 内部包,配合 Zod 在运行时做边界校验。一旦字段增删或类型变更,前端编译阶段直接红线报错,彻底终结了接口文档陈旧和生产环境 undefined 异常。
① 简历常见平淡回答
「把客户端不一样的逻辑放在 useEffect 里面跑,或者加个 suppressHydrationWarning 压制警告。」
盲目压制警告会掩盖客户端与服务端 DOM 树结构不一致导致的事件绑定失效或页面闪烁,缺乏对时间、本地缓存及动态布局差异的根因治理。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
水合失败的本质是服务端生成的静态 HTML 与客户端初次渲染时的虚拟 DOM 树不一致。典型场景如本地时间戳格式化、客户端独有的 LocalStorage 主题读取以及浏览器插件对 DOM 的篡改。我的治理策略是:区分渲染阶段,将依赖客户端环境的动态状态前置为单向初始状态,或封装两阶段挂载钩子;对于确定仅在客户端渲染的非 SEO 交互模块,使用 Dynamic Import 开启 ssr: false 隔离渲染,杜绝警告泛滥。
① 简历常见平淡回答
「把 JWT 存在 localStorage 里,前端每次发请求都在 header 带上 Authorization。」
LocalStorage 无法防范 XSS 窃取令牌,且无状态 JWT 在面对主动踢人下线或权限即时吊销时存在先天的黑名单开销缺陷。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
我们采用双 Token 结合 HttpOnly Cookie 的防御架构:短时 Access Token 配合 HttpOnly、Secure、SameSite=Lax 的 Cookie 存储,阻断 JavaScript 脚本读取并防御 CSRF;长时 Refresh Token 存入服务端 Redis 白名单,支持即时吊销。敏感业务操作强制二次验证,并在网关层核验 Origin 与 CSRF Token,既保留了轻量无状态校验优势,又保障了异常登录能在一分钟内主动熔断。
① 简历常见平淡回答
「前端用 Lighthouse 测一下分数把图片压缩压缩,后端把慢 SQL 优化一下,该加索引的加索引。」
割裂的前后端优化无法解决全链路木桶效应,缺乏以 Web Vitals 为入口结合分布式链路追踪(APM)的闭环排查能力。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
全链路性能治理核心是建立「端到端统一追踪视界」。在前端以 LCP、INP、CLS 核心指标为基准,采集真实用户体验监控(RUM)并注入统一 TraceId;网络层推行 HTTP/3、CDN 边缘动静态分流与资源预加载;后端网关将 TraceId 串联分布式链路,定位微服务调用拓扑中的慢调用与数据库 N+1 查询。通过前后端协同压降,成功将高频页面的 P95 LCP 从 2.8 秒缩减至 850 毫秒,后端首包 TTFB 控制在 120 毫秒内。
① 简历常见平淡回答
「实时消息肯定用 WebSocket,功能最强大,前后端都能实时发消息,连上了就不会断。」
盲目选用 WebSocket 忽视了其协议复杂性、代理中间件兼容问题以及无天然重连机制,忽视了单向流式场景下 SSE 的原生优势。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
选型取决于交互的「对称性与协议成本」。对于多人协作协同编辑、多人即时通讯等高频全双工场景,采用 WebSocket 配合心跳保活与二进制协议压缩;而对于类似 ChatGPT 流式输出、实时看板推送等纯下行场景,优先选择基于 HTTP 的 SSE。SSE 天生具备断线自动重连、原生基于事件流解析且能完美复用 HTTP/2 多路复用和鉴权网关基础设施,运维与中间件支持成本远低于长连接网关。
① 简历常见平淡回答
「打包时给 JS 文件名加个 hash 后缀,后端部署时直接覆盖旧版本,更新完了刷新一下页面。」
直接覆盖后端会导致灰度发布期间接口参数不兼容引发前端白屏,缺乏对多版本共存、增量发布与回滚机制的工业级考量。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
全栈零停机遵循「先上资源、兼容多版、平滑切流」。前端构建产物以内容哈希命名并上传 CDN 设置永久缓存,HTML 设为 no-cache;发布时优先上传静态静态资源,此时旧版本页面仍可正常运行;后端服务严格遵守接口向后兼容原则(API 变更只增不减),通过 Kubernetes 滚动更新逐批替换 Pod;新旧版本共存期间网关根据版本头平滑路由,即便遭遇突发异常也能在秒级切回历史 HTML 快速止损。
① 简历常见平淡回答
「用 iframe 把各个小系统拼起来,或者用乾坤框架,用 class 前缀避免样式冲突。」
iframe 隔离割裂了路由与弹窗体验,缺乏对沙箱运行环境、样式作用域(Shadow DOM / CSS Modules)及跨应用共享状态总线的系统化设计。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
我们采用基于 Module Federation 的微前端底座配合宿主应用编排。在 JS 运行环境上,利用 Proxy 代理全局 window 对象实现沙箱隔离,确保子应用卸载时自动清理副作用;样式层面严格推行 CSS Modules 或 Shadow DOM,防止全局样式污染;状态协同上,避免过度跨应用共享状态,仅在宿主应用定义轻量全局 EventBus 或使用定制状态总线同步用户登录凭证与多语言切换,子应用内部状态完全自治。
① 简历常见平淡回答
「前端把按钮置灰防止重复点击,后端加个 Redis 缓存数据,接口用消息队列排队。」
仅停留在组件防抖和后端加缓存,缺少从 CDN 边缘静态化、动静分离、网关令牌桶限流到分布式锁减库存的立体化防护。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
高并发防护必须层层削峰。最外层将活动详情页全量静态化并下沉至 CDN 边缘节点,动态请求通过验证码阻断高频机器人;网关层配置基于 IP 与用户维度的滑动窗口限流;应用层先查询本地只读缓存(Caffeine / Go Cache),未命中再穿透至 Redis 集群;核心库存扣减使用 Lua 脚本保障原子校验与预扣,随后异步发送 MQ 消息排队落库生成订单。层层拦截后,最终到达关系型数据库的写流量不足原始请求的 2%。
① 简历常见平淡回答
「数据库每张表都加个 tenant_id 字段,查询的时候都带上这个条件,前端按租户显示不同 logo。」
共享数据库字段隔离存在数据越权泄露的巨大安全隐患,缺少多级隔离模式(独立 Schema / 独立 DB)与前端微定制方案。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
多租户架构采用分层治理模型:在接入层,网关根据二级域名或请求头精准解析租户上下文并注入上下文 Trace;数据层根据客户等级采用混合隔离策略:中小型客户采用共享数据库加行级安全隔离(PostgreSQL RLS),金融级 KA 客户采用独立数据库物理隔离;前端基于主题引擎与动态配置中心,在运行时异步注入租户专属主题色、Logo 与动态菜单权限,既保证了多租户代码同构,又彻底防范了跨租户越权。
① 简历常见平淡回答
「没网的时候把数据存在浏览器的 IndexedDB 里面,等有网了拿出来发接口发给后端。」
缺乏网络状态恢复时的批量同步时序控制、分布式多设备并发编辑冲突检测(CRDTs / 乐观锁版本号)与最终一致性保证。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
离线优先系统采用「本地优先写入、日志增量同步、确定性冲突仲裁」架构。客户端基于 IndexedDB 或 SQLite 构建本地响应层,所有读写均在本地毫秒级完成,并将写动作打包为带单调递增版本号的操作日志(OpLog);网络重连时,Service Worker 唤醒后台同步队列,按序向服务端推送增量变更;若检测到多端并发冲突,根据业务性质采用无冲突复制数据类型(CRDTs)自动合并,或通过最后写入获胜(LWW)结合业务时间戳进行仲裁。
① 简历常见平淡回答
「前端用 DOMPurify 过滤一下富文本内容防 XSS,后端对所有的 SQL 参数做预编译防注入。」
点状安全措施无法抵御现代立体化攻防,缺乏内容安全策略(CSP)、权限模型(RBAC/ABAC)、安全审计与传输层硬化的完整纵深防御。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
纵深防御强调层层设防:在最外层,配置严格的内容安全策略(CSP)阻断外部非受信脚本执行,全站开启 HSTS 与 DNS 劫持防护;在应用交互层,富文本使用白名单过滤,表单提交强制参数类型校验并自动转义;后端持久层全面推行 ORM 参数化查询,根绝 SQL 注入;API 网关层集成基于属性的访问控制(ABAC),并在全链路推行敏感字段脱敏与加密传输,配合 WAF 实时识别防范 CC 攻击与暴力破解。
① 简历常见平淡回答
「先看控制台报错日志,如果是前端代码问题就赶快发代码修复,如果是后端服务挂了就重启容器。」
缺乏生产级事故的止血优先级思维,在未排查事故根因前盲目重启可能导致日志现场被抹除或引发更大面积的故障穿透。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
生产事故遵循「先止血、再排查、后复盘」。报警发生时,第一动作并非盲目查代码,而是查看监控大盘与报错趋势:若集中在特定静态资源 Chunk 404,往往是刚发布导致版本漂移,立刻在 CDN 回退上一版 HTML 止血;若接口 502,排查 Pod 资源负载,若是内存泄漏导致 OOM,先扩容实例保证服务可用,并保留一份堆转储(Heap Dump)保留现场。止血后再通过 TraceId 聚合慢请求与异常栈,复现根因并在灰度环境验证修复。
① 简历常见平淡回答
「老代码太乱了很难改,最好是推翻重写,重新搭一套最新的前后端框架重写一遍。」
推翻重写是典型的工程灾难做法,不仅耗时漫长、无法快速交付商业价值,而且老系统隐藏的边界业务逻辑极易丢失。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
治理技术债务坚持「小步快跑、绞杀者模式(Strangler Pattern)」。我们不会贸然推翻重写,而是先在系统外层架设反向代理网关:新业务完全采用现代前后端技术栈独立开发,老业务保持稳定运行;针对老系统中的核心痛点模块,先梳理测试用例补齐端到端回归测试,然后在网关层做流量按比例灰度切流至新服务;经过数个迭代周期逐步迁移老模块,最终实现无缝平稳退役,既保障了业务持续交付,又渐进式完成了技术栈升级。
① 简历常见平淡回答
「告诉产品经理这个做不了,技术上不支持,强行做以后系统肯定会崩掉。」
简单拒绝会激化产研矛盾,缺乏站在产品商业目标角度倾听真实诉求并提供兼顾工程底线的替代方案的沟通智慧。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
遇到别扭需求,关键是「探寻真实商业目的,提供替代路径」。产品提出的往往是其推导出的特定操作方案,而非本质诉求。我会先与其深度沟通:「这个功能背后希望帮助用户解决什么问题?期望达到的核心业务指标是什么?」搞清楚业务本质后,我会明确指出原方案在数据模型与扩展性上的隐性代价,并主动提供两个工程更优雅的替代设计:方案 A 能满足 80% 核心场景且改造成本极小,方案 B 支持未来扩展但需分两期实现,把对立摩擦转化为共同权衡。
① 简历常见平淡回答
「哪个技术热门就学哪个,业余时间多看 GitHub 开源项目和技术博客,多刷技术社区。」
盲目追逐框架热点容易陷入走马观花的半瓶水困境,缺乏以计算机底层底层基石为锚、以业务价值为导向的学习闭环。
② 面试官追问逻辑
③ 深挖后可量化的高分示范
全栈工程师的护城河是「T 型知识结构」:横向保持对全链路技术生态的敏锐度,纵向在核心领域建立深水区理解。我把精力分为两部分:70% 投入到底层永不过期的基石知识——网络协议、操作系统、数据结构、数据库事务与分布式一致性,这些底层原理十几年不曾改变;30% 跟踪上层框架生态演化,关注它们如何解决特定工程痛点。学习新技术坚持「输入—验证—输出」闭环,通过搭建最小原型验证其生产落地边界,绝不盲目技术崇拜。
换个岗位,继续练
练完全栈开发工程师,通常接着练这些相邻岗位
前端开发面试深挖 15 题
核心技术 · 工程架构 · BQ
查看题库
同技术栈后端开发面试深挖 15 题
核心技术 · 分布式 · BQ
查看题库
能力延伸DevOps与SRE面试深挖 15 题
CI/CD 流水线 · 稳定性治理 · 容灾架构 · BQ
查看题库
没找到你的岗位? 查看全部 25 个岗位 →