fullstack git:20260908.a2a662cA

Immutable. This exact content is served forever at /api/v1/blob/ef105c49c85380de.

---
name: fullstack
description: 全栈开发出题：前后端协作边界与 BFF、鉴权与会话、API 设计、部署与 DevOps 基础、全链路性能与监控。岗位或简历出现全栈、Full Stack、Node.js 后端 + 前端、独立负责整条功能链路时加载。
keywords: [全栈, fullstack, full stack, 全栈工程师, bff, node.js, next.js, nestjs, express, restful, graphql, jwt, oauth, docker, 前后端分离]
layer: domain
---

## 岗位职责与考察重点

全栈工程师的定义在不同公司差异很大：初创公司和外企里通常是"一个人把功能从数据库到页面做完并上线"，大厂里更多是"前端为主、能写 BFF 和轻后端"或"后端为主、能改页面"。真实面试里最常被问的不是两边各自多深，而是"边界怎么划"：接口谁定、数据在哪一层聚合、鉴权在哪一层做、出了问题从哪端开始查。面试官最在意三件事：一是有没有独立交付过完整链路（需求、接口、数据、部署、监控），二是遇到跨端问题（比如接口慢、登录态丢失、缓存不一致）能否在前后端之间正确归因而不是甩锅，三是知不知道自己在哪一侧薄弱以及怎么补。

校招侧重基础扎实和动手：HTTP 与浏览器基础、能用 Node/Next/Spring 等搭一个带登录和 CRUD 的小系统并说清每一层做什么；社招侧重工程判断：BFF 该不该建、SSR 还是 CSR、JWT 还是 session、微服务还是单体、监控告警怎么配、线上故障怎么定位。这个方向简历最常见的问题是"什么都会一点"但每样都答不到排查层，所以要用具体故障场景把候选人逼到某一层深挖。

## 主题

### 前后端协作边界与接口契约
- 阶梯：接口文档谁写、什么时候定 → OpenAPI/TypeScript 类型共享、mock 与契约测试如何让两端并行 → 上线后前端发现字段语义和文档不一致，怎么防止再发生 → 契约先行的成本（改动慢）与灵活性之间怎么按团队规模取舍
- 好题：一个列表页需要用户信息、订单、推荐三个服务的数据，前端说"给我一个接口"，后端说"你自己调三个"，你会怎么定？这个决定在数据量翻十倍、字段频繁变更时分别会遇到什么问题？
- 危险信号：只会说"前后端分离"；接口靠口头约定和 Postman 截图；没做过接口变更的兼容处理
- 期望信号：区分面向资源的 API 与面向页面的 API；提到版本、默认值、字段废弃策略；有用 schema 生成类型或做契约测试的经历；能说清"聚合放哪一层"的判断依据

### BFF 与数据聚合层
- 阶梯：BFF 是什么、和网关有什么区别 → 聚合、裁剪、缓存、鉴权放 BFF 哪些合适哪些不合适 → BFF 变成"胖中间层"、逻辑重复、一个页面改动要动三层，怎么治理 → 多端（Web/小程序/App）一套 BFF 还是各自一套，团队边界怎么划
- 好题：你们的 Node BFF 上线半年后 P99 从 80ms 涨到 600ms，请求量没大变，你怀疑什么？怎么定位是下游慢、串行调用还是 BFF 自身（事件循环阻塞、内存泄漏）？
- 危险信号：把 BFF 当万能层塞业务逻辑；下游多个接口串行 await 却不知道；不知道 Node 单线程阻塞的表现
- 期望信号：并行请求与超时熔断；按端拆 BFF 的边界理由；用 trace 看串行/并行；对 Node 事件循环延迟有监控概念

### 鉴权与会话管理
- 阶梯：cookie session 与 JWT 各自怎么工作 → 无状态 token 怎么做注销与续期、refresh token 的存储与轮换、CSRF 与 XSS 对两种方案的影响差异 → 用户报"隔一会儿就掉登录"或"换设备后老设备没被踢下线"，怎么排查 → 单体、多域名、第三方登录（OAuth2/OIDC）场景下方案怎么选，安全与体验怎么平衡
- 好题：你的应用前端在 app.example.com、API 在 api.example.com，用 JWT 放在哪、怎么防 XSS 拿走 token、怎么实现"修改密码后所有设备下线"？如果换成 session 方案这三个问题分别怎么变？
- 危险信号：JWT 存 localStorage 且说"没问题"；不知道 JWT 无法主动失效；把 SameSite、HttpOnly、Secure 混为一谈；OAuth 授权码流程说不清 code 换 token 在哪一侧做
- 期望信号：HttpOnly cookie + SameSite + CSRF token 的组合；短期 access token + 可撤销 refresh token；黑名单/版本号实现强制下线；知道 PKCE 用在哪

### API 设计：REST、GraphQL 与 RPC
- 阶梯：REST 资源建模与状态码语义 → 分页（offset vs cursor）、过滤、批量、幂等键的设计 → GraphQL N+1、over-fetching 解决了什么又带来了什么（缓存难、复杂度攻击）→ 内部服务用 gRPC/tRPC、对外用 REST 的组合怎么定，什么时候不该上 GraphQL
- 好题：设计一个"批量导入 1 万条商品"的接口，要考虑幂等、部分失败、进度查询与超时。同步还是异步？状态怎么存？客户端断网重试会发生什么？
- 危险信号：所有接口都是 POST 且返回 200 带 code；分页只会 offset；说 GraphQL 就是"前端想要什么拿什么"却没提 dataloader 与限深
- 期望信号：幂等键与去重表；长任务改异步 + 任务 ID 轮询或推送；错误响应结构统一；对 GraphQL 有明确的适用场景判断

### 渲染策略：SSR / CSR / SSG / 流式
- 阶梯：SSR 与 CSR 的差别与各自首屏指标 → hydration 做什么、为什么会不一致（时间、随机数、用户态）→ SSR 页面 TTFB 高、服务端 CPU 打满、缓存击穿怎么排查 → 按页面类型选渲染模式，SEO、个性化、成本三者取舍
- 好题：电商商品页要 SEO、又有个性化推荐和实时库存，你怎么拆哪部分 SSR、哪部分客户端拉取、哪部分静态化并配缓存？活动期间流量十倍时哪一段最先出问题？
- 危险信号：认为 SSR 一定更快；不知道 hydration 错误怎么来的；所有页面一个模式
- 期望信号：区分 TTFB/FCP/LCP/TTI 谁受影响；静态壳 + 动态岛的思路；CDN 缓存与 stale-while-revalidate；服务端渲染的并发与内存代价

### 数据层与 ORM 使用
- 阶梯：ORM 解决什么、隐藏了什么 → N+1、隐式事务、连接池耗尽的成因 → 接口偶发 500，日志显示 "too many connections" 或查询超时，怎么从应用层排查 → 什么时候绕过 ORM 写 SQL，读写分离与缓存该由哪一层做
- 好题：用 Prisma/TypeORM/SQLAlchemy 写的列表接口，本地 50ms、线上 3s，数据量差一百倍，你怎么定位？拿到执行计划后可能看到什么、分别怎么改？
- 危险信号：不知道 ORM 生成了什么 SQL；不会看执行计划；连接池大小随便填
- 期望信号：打印 SQL 与 explain；索引与分页改法；连接池与实例数的乘积概念；缓存放 BFF 还是服务层的理由

### 构建、部署与 DevOps 基础
- 阶梯：前后端各自怎么打包、产物是什么 → Docker 多阶段构建、环境变量与配置注入、镜像层缓存 → 部署后"本地好的线上不行"怎么排查（环境变量、时区、依赖版本、构建产物差异）→ 单机 Docker Compose、云托管（Vercel/云函数）、K8s 三种方案对团队的成本与上限
- 好题：你要把一个 Next.js + Node API + Postgres 的项目从"手动 scp 到服务器"改成可重复的部署流程，CI 里跑什么、镜像怎么分层、数据库迁移放在哪一步、回滚怎么做？
- 危险信号：靠 SSH 上服务器 git pull；数据库迁移手工执行；不知道 CI 和 CD 的区别；镜像里塞进 node_modules 的 devDependencies 且不觉得有问题
- 期望信号：多阶段构建与 .dockerignore；迁移与代码版本绑定并可回滚；健康检查与零停机发布；对不同托管方案的适用规模有判断

### 全链路性能定位
- 阶梯：用户说"页面慢"你先看什么 → 前端（资源、渲染、请求瀑布）、网络（DNS/TLS/CDN）、后端（接口、DB、外部依赖）各自的观测手段 → 只有部分用户慢、只有某个时段慢、只有首次慢，分别指向哪里 → 优化顺序怎么排：先修最大头还是先修最便宜的
- 好题：运营反馈"下午两点后页面明显变慢"，前端监控 LCP 正常、接口 P99 升高但平均正常，你按什么顺序缩小范围？哪些指标能让你区分是慢 SQL、下游依赖还是资源争抢？
- 危险信号：只会加缓存；不区分平均值与 P99；不看 waterfall 就说"后端慢"
- 期望信号：从 RUM/浏览器 timing 切到服务端 trace；用 traceId 串起前后端；找到慢的那一段再看它的下钻指标；有"一次优化前后对比数据"

### 缓存与一致性（跨端视角）
- 阶梯：浏览器缓存、CDN、BFF 内存缓存、Redis、DB 缓存分别缓什么 → 缓存 key 设计、失效策略、穿透与雪崩 → 用户改了资料后有的页面更新了有的没更新，怎么查是哪一层缓存 → 多层缓存的一致性代价与"允许多久不一致"的业务谈判
- 好题：用户修改头像后，个人页更新了但评论区还显示旧头像，且过一小时才恢复。请列出可能的缓存层，你怎么定位是哪一层、怎么修，并说明修完后要不要保留那层缓存。
- 危险信号：所有东西都塞 Redis；HTTP 缓存头一问三不知；把"缓存更新"和"缓存删除"当一回事
- 期望信号：按数据变化频率与容忍度分层；Cache-Control/ETag 的使用；写后删 + 短 TTL 的兜底；有从 URL 上加版本号解决静态资源缓存的经验

### 监控、日志与故障响应
- 阶梯：上线后你怎么知道系统健康 → 前端错误上报、后端结构化日志、指标、trace 各自回答什么问题 → 半夜告警"错误率升高"你先看哪三个面板、怎么判断影响面与是否回滚 → 告警阈值怎么定才不会噪音太多或漏报，谁 on-call
- 好题：你负责的功能上线后用户反馈"偶尔报错"，但后端日志没有 5xx。可能原因有哪些（前端异常、网络、CORS、第三方脚本、灰度差异）？你需要哪些数据才能不靠猜？
- 危险信号：只有 console.log；出问题先重启；不知道自己的错误率基线是多少
- 期望信号：前后端共用 traceId；错误按版本/浏览器/接口维度聚合；有 SLO 或至少有基线；能说出一次真实故障的时间线

### 安全基础（全栈视角）
- 阶梯：XSS/CSRF/SQL 注入的本质区别 → 输入校验放哪一层、输出编码、CSP、参数化查询 → 安全扫描报了一个"敏感信息泄露"，怎么从前端打包、接口返回、日志三处排查 → 安全投入的优先级：先修什么、什么可以接受风险
- 好题：你的富文本编辑器允许用户发帖，前端做了过滤，安全团队仍然打出了存储型 XSS，可能漏在哪？修复方案里哪些放后端、哪些放前端、CSP 能兜住多少？
- 危险信号：认为前端校验够了；接口按 ID 查数据不做归属校验（越权）；把密钥打进前端包
- 期望信号：服务端校验为准；白名单式富文本清洗；越权检查在数据访问层；环境变量与构建时注入的区分

### 前后端类型与代码共享
- 阶梯：为什么想共享类型与校验逻辑 → monorepo、共享包、schema 驱动代码生成 → 共享包一改全站构建、版本地狱、循环依赖怎么治 → 共享的收益和耦合的成本，哪些该共享哪些坚决不共享
- 好题：你们前后端各维护一套 DTO 与校验规则，经常对不上。给出一个统一方案，说明改动流程、发布顺序、老版本客户端怎么兼容。
- 危险信号：把后端实体直接暴露给前端；没有版本策略；monorepo 就是"放一个仓库"
- 期望信号：schema（zod/OpenAPI）为唯一事实来源；生成而非手写；兼容期字段可选；工具链（构建缓存、affected 检测）的认知

## 好题 / 坏题对比

- 坏：说说 JWT 和 session 的区别。
- 好：前端在 app 域、API 在 api 域，用 JWT 你会存哪、怎么防 XSS 拿走、怎么实现"改密码后全设备下线"？如果换 session，这三个问题分别怎么变？哪一种你会推荐给一个 5 人团队并说明理由。

- 坏：什么是 BFF？有什么好处？
- 好：你的 Node BFF 上线半年后 P99 从 80ms 涨到 600ms 但请求量没变，你怀疑哪些原因？怎么用 trace 区分是下游慢、串行 await 还是事件循环被阻塞？如果是串行，改并行后有哪些新风险？

- 坏：SSR 和 CSR 有什么区别？
- 好：商品页要 SEO、有个性化推荐和实时库存，你怎么拆哪部分服务端渲染、哪部分客户端拉、哪部分静态化配缓存？大促流量十倍时哪一段先崩、你会提前做什么？

## 项目结合钩子

- 简历出现"独立完成前后端" → 追接口文档在哪、怎么测、部署到哪、出过什么线上问题、怎么发现的；只能讲功能不能讲事故的降一档
- 简历出现 BFF / 中间层 → 追它聚合了几个下游、有没有超时熔断、最慢的接口是哪个、为什么不让前端直接调
- 简历出现登录 / 鉴权模块 → 追 token 存哪、怎么续期、怎么强制下线、第三方登录用的哪个流程、有没有处理过 CSRF
- 简历出现 Next.js / Nuxt / Remix → 追哪些页面 SSR 哪些 CSR、hydration 报过什么错、部署在哪、服务端渲染的成本谁付
- 简历出现 Docker / CI/CD → 追镜像多大、构建多久、迁移怎么跑、回滚过没有、环境变量怎么注入
- 简历出现"性能优化 X%" → 追指标是什么、在哪测的、优化前后数据、是前端还是后端改动、有没有对照
- 简历出现 GraphQL → 追为什么选它、N+1 怎么解决、限深与复杂度控制、缓存怎么做、后悔过没有
- 简历出现 monorepo / 共享类型 → 追共享了什么、一次改动影响面怎么控制、构建时间、有没有循环依赖

## 出题原则

- 用一个跨端故障场景逼候选人选边深挖：先问"你先查前端还是后端、为什么"，再顺着他选的那一侧追到排查层，防止"两边都懂一点"的浮面回答。
- 每个架构选择都要追"团队规模与阶段"：BFF、微服务、GraphQL、K8s 对 3 人团队和 300 人团队答案不同，只会说"最佳实践"而不结合规模的是危险信号。
- 部署与监控必问：全栈的核心价值是端到端交付，没上过线、没看过监控面板、没处理过故障的候选人无论代码多熟都要标记。
- 不考具体框架 API 细节的时效性（某版本的路由写法），考的是"这一层为什么存在、坏了怎么查"。