Serverless/Edge 面试题

本题库共收录 65 道面试题（基础 14 / 进阶 26 / 深入 16 / 架构 9）。本文件收录 Serverless/Edge 相关面试题，目标题量 150 道。题型覆盖：概念题、场景设计题、系统设计题、工程化题、性能优化题、安全题、软技能题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（8 道）

FB-35-CO-B-001：什么是 Serverless/FaaS？它解决了什么问题？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：Serverless、FaaS、函数即服务、无服务器 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Serverless 和 FaaS 的概念，并说明它们相比传统服务器的优势。

参考答案：

Serverless 是一种云计算模型，开发者无需管理服务器，按需运行代码并按调用/资源计费。FaaS（Function as a Service）是 Serverless 的一种实现形式，以函数为部署单元。

解决的问题：

运维减负：无需采购、配置、维护服务器和操作系统。
弹性伸缩：根据请求量自动扩缩容，应对流量峰值。
按需付费：无请求时不产生计算费用，适合低频或突发业务。
快速上线：聚焦业务代码，缩短交付周期。

代表服务：AWS Lambda、Vercel Functions、Cloudflare Workers、阿里云函数计算、腾讯云 SCF。

评分维度：

概念准确（40%）：Serverless vs FaaS
优势（40%）：免运维、弹性、按需付费
代表服务（20%）：能举例

常见错误：

认为 Serverless 真的不需要服务器，忽略底层仍有服务器。
把 Serverless 等同于 FaaS，忽略 BaaS、容器 Serverless 等形态。

延伸追问：

Serverless 适合哪些类型的应用？不适合哪些？
FaaS 中的函数有什么限制？

相关题目：

FB-35-CO-B-003 冷启动与热启动
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

AWS Lambda

口头回答版：

Serverless 是开发者不用管服务器，按需运行代码并按调用计费。FaaS 是函数即服务。它解决了运维负担、弹性伸缩和按需付费问题。代表有 AWS Lambda、Vercel、Cloudflare Workers、国内阿里云函数计算。

FB-35-CO-B-002：Edge Computing 与传统 CDN 有什么区别？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：Edge Computing、CDN、边缘计算、边缘函数 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请比较 Edge Computing 与传统 CDN 的能力差异，并说明前端能从 Edge 获得哪些能力。

参考答案：

传统 CDN：

主要缓存和分发静态资源（图片、JS、CSS、视频）。
请求到达源站前由边缘节点返回缓存内容。
能力集中在“分发”。

Edge Computing：

在靠近用户的边缘节点运行代码，如 Cloudflare Workers、Vercel Edge Functions。
除了缓存，还能做动态处理：路由改写、A/B 测试、身份校验、SSR、边缘聚合。
距离用户近，延迟低。

前端获得的能力：

边缘渲染：在边缘节点执行 SSR/SSG，减少回源。
动态个性化：根据用户位置、语言、设备在边缘改写响应。
边缘 API：轻量 BFF 逻辑下沉到边缘。
安全：WAF、Bot 管理、DDoS 防护在边缘执行。

评分维度：

CDN 能力（30%）：静态缓存、分发
Edge 能力（40%）：动态代码、低延迟
前端收益（30%）：边缘渲染、个性化、安全

常见错误：

认为 Edge 只是更快的 CDN，忽略其可编程性。
把所有后端逻辑都搬到 Edge，导致状态管理复杂。

延伸追问：

Edge 函数和普通 FaaS 函数有什么区别？
在 Edge 上可以做数据库操作吗？

相关题目：

FB-35-CO-A-001 SSR at Edge
FB-35-SD-R-002 设计 Edge 网关

参考资源：

Cloudflare Workers

口头回答版：

传统 CDN 主要是缓存静态资源；Edge Computing 是在靠近用户的边缘节点跑代码，可以做动态路由、A/B、鉴权、SSR。前端能获得边缘渲染、个性化响应、边缘 API 和安全防护。

FB-35-CO-B-003：Serverless 中的冷启动与热启动是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：冷启动、热启动、FaaS、延迟、预热 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Serverless 函数的冷启动和热启动，以及影响冷启动的因素。

参考答案：

冷启动：函数长时间未执行后，平台需要分配资源、加载运行时、初始化代码、建立连接，导致首次调用延迟高。
热启动：函数实例仍在内存中，直接复用，延迟低。

影响冷启动的因素：

运行时：Node.js/Python 启动较快，Java/.NET 启动较慢。
依赖体积：node_modules 越大，加载越慢。
网络初始化：数据库、Redis、外部 API 连接建立时间。
VPC 配置：在 VPC 中需要创建弹性网卡，增加延迟。
内存大小：内存越大，CPU 配额越高，启动越快。
平台差异：Edge Runtime 通常冷启动更低。

优化方向：

精简依赖、代码分割。
初始化外置（连接池、客户端复用）。
使用 Provisioned Concurrency / 预热策略。
边缘函数降低延迟。

评分维度：

概念（40%）：冷启动 vs 热启动
影响因素（40%）：运行时、依赖、网络、VPC、内存
优化（20%）：精简、预热、边缘

常见错误：

认为冷启动只与代码大小有关，忽略运行时和依赖。
忽视连接初始化对冷启动的影响。

延伸追问：

如何测量和监控冷启动时间？
Edge Runtime 为什么冷启动更低？

相关题目：

FB-35-CO-A-004 冷启动优化
FB-35-CO-B-001 Serverless 概念

参考资源：

AWS Lambda Cold Starts

口头回答版：

冷启动是函数长时间没执行后平台重新分配资源和加载运行时的延迟；热启动是复用已有实例。影响因素有运行时、依赖体积、网络初始化、VPC、内存。优化可以精简依赖、复用连接、预热、用边缘函数。

FB-35-CO-B-004：Serverless 中的事件驱动与触发器有哪些？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：事件驱动、触发器、FaaS、事件源 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请列举 Serverless 函数的常见触发方式，并说明前端场景中的应用。

参考答案：

常见触发器：

HTTP 请求：API Gateway / 边缘路由触发，最常见。
定时触发：Cron 任务，如数据备份、报表生成。
对象存储事件：文件上传后触发压缩、转码。
消息队列：SQS、Kafka、RabbitMQ 消息触发消费。
数据库变更：DynamoDB Streams、CDC 触发。
Webhook：第三方服务回调。
认证事件：用户注册/登录触发欢迎邮件、日志。

前端场景：

表单提交后触发邮件通知或数据处理。
图片上传后触发压缩和水印。
构建完成后触发 CDN 刷新、缓存预热。
Edge 函数在请求到达时动态改写响应。

评分维度：

触发器类型（50%）：HTTP、定时、存储、队列、DB、Webhook
前端应用（30%）：上传、提交、构建、边缘
事件驱动理解（20%）：异步、解耦

常见错误：

只把 Serverless 当 HTTP API 用，忽略事件驱动场景。
在事件处理函数中做长时间同步任务。

延伸追问：

事件驱动架构中如何保证消息至少被处理一次？
前端如何订阅 Serverless 处理结果？

相关题目：

FB-35-CO-B-001 Serverless 概念
FB-35-CD-A-001 边缘函数路由改写

参考资源：

AWS Lambda Event Sources

口头回答版：

Serverless 触发器有 HTTP、定时、对象存储、消息队列、数据库变更、Webhook。前端场景如表单提交发邮件、图片上传压缩、构建后刷新 CDN、Edge 请求改写。它本质是事件驱动的。

FB-35-CO-B-005：Serverless 函数为什么要尽量无状态？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：无状态、FaaS、状态外置、可扩展 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释为什么 Serverless 函数推荐无状态设计，以及有状态需求应如何处理。

参考答案：

无状态原因：

实例不固定：函数每次调用可能由不同实例处理，无法保证状态一致。
自动扩缩容：多实例同时运行，内存中的状态无法共享。
快速恢复：无状态函数更容易重启、迁移、水平扩展。

有状态需求处理：

外置状态：使用 Redis、DynamoDB、Cloudflare KV、D1 等存储。
会话：JWT/Token 替代服务端 Session；或把 Session 存到共享缓存。
上传文件：直接写入对象存储，不在函数内存中保存。
长连接：WebSocket 等长连接不适合 FaaS，可用 API Gateway WebSocket 或专用服务。
临时状态：可利用实例复用（热启动）缓存连接，但要做好失效处理。

评分维度：

无状态原因（50%）：实例不固定、扩缩容、恢复
状态外置（40%）：数据库、缓存、对象存储、Token
边界（10%）：临时缓存与失效

常见错误：

把用户 Session 存在函数内存中，导致多实例登录态不一致。
把大文件存在内存，导致 OOM。

延伸追问：

边缘函数是否可以做有状态？
如何利用热启动做连接复用？

相关题目：

FB-35-CO-A-003 状态持久化
FB-35-CO-B-003 冷启动与热启动

参考资源：

AWS Lambda Best Practices

口头回答版：

Serverless 函数推荐无状态是因为实例不固定、会水平扩展。有状态要外置到 Redis、数据库、对象存储，会话用 JWT，文件直接存对象存储。WebSocket 长连接不适合普通 FaaS。

FB-35-CO-B-006：Serverless 有哪些优势和劣势？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：Serverless、优缺点、成本、 Vendor Lock-in 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请客观分析 Serverless 的优势与劣势，并说明适用场景。

参考答案：

优势：

免运维、自动扩缩容。
按调用付费，低频场景成本低。
快速迭代，函数粒度部署。
高可用由平台保证。
事件驱动天然解耦。

劣势：

冷启动延迟：对延迟敏感场景需优化或预热。
Vendor Lock-in：深度绑定云平台 API 和运行时。
调试复杂：本地难以完全模拟云环境。
执行时长限制：多数平台有超时限制（如 15 分钟）。
状态与外设限制：长连接、大文件、本地文件系统受限。
可观测性：分布式 tracing 和日志聚合需额外配置。

适用：

API、定时任务、事件处理、SSR、边缘计算。
不适合：长时间运行、强状态、低延迟强一致性、大规模计算。

评分维度：

优势（30%）：免运维、弹性、成本
劣势（40%）：冷启动、锁定、调试、限制
适用场景（30%）：能区分适合与不适合

常见错误：

只讲优势不讲劣势。
认为所有应用都应 Serverless。

延伸追问：

如何降低 Vendor Lock-in 风险？
Serverless 和 Kubernetes 各适合什么阶段？

相关题目：

FB-35-CO-B-001 Serverless 概念
FB-35-SD-R-003 Serverless 与容器对比

参考资源：

Serverless Framework

口头回答版：

Serverless 优势是免运维、弹性、按调用付费、快速迭代。劣势是冷启动、Vendor Lock-in、调试复杂、执行时长和状态限制。适合 API、定时任务、事件、SSR、边缘；不适合长运行、强状态、大规模计算。

FB-35-CO-B-007：Serverless 本地开发与调试有哪些方式？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：本地开发、调试、Serverless Framework、Miniflare、Emulator 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 Serverless 函数的本地开发、调试、测试方法。

参考答案：

本地开发方式：

框架 CLI：Serverless Framework、Vercel CLI、Wrangler、SLS 提供本地模拟。
运行时模拟器：如 lambda-local、miniflare、localstack 模拟云环境。
容器化：用 Docker 运行与生产一致的环境。
单元测试：把业务逻辑抽成纯函数，脱离运行时测试。
集成测试：调用本地 API 模拟器或 staging 环境。

调试技巧：

打印结构化日志，使用云平台的日志查询。
本地 attach debugger（Node.js --inspect）。
使用 X-Ray/OpenTelemetry 做分布式追踪。
对冷启动、依赖加载做 profiling。

最佳实践：

代码分层，核心逻辑与运行时入口解耦。
使用环境变量区分本地、staging、生产。
Mock 外部依赖（数据库、第三方 API）。

评分维度：

本地工具（40%）：CLI、模拟器、容器
调试方法（30%）：日志、debugger、tracing
分层测试（30%）：单元、集成、mock

常见错误：

只在云端调试，开发效率低。
业务逻辑与运行时入口耦合，难以本地测试。

延伸追问：

如何模拟云端事件触发器？
本地模拟器与生产环境差异可能带来哪些问题？

相关题目：

FB-35-CO-B-006 Serverless 优缺点
FB-35-CO-A-006 Serverless 可观测性

参考资源：

Serverless Framework Local Testing

口头回答版：

Serverless 本地开发可用框架 CLI、运行时模拟器、Docker，单元测试把业务逻辑抽出来，集成测调用本地 API。调试用结构化日志、debugger、分布式追踪。代码要和运行时入口解耦，mock 外部依赖。

FB-35-CO-B-008：常见的 Serverless/Edge 平台有哪些？各有什么特点？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：Serverless 平台、Vercel、Cloudflare、AWS Lambda、函数计算 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请比较 AWS Lambda、Vercel Functions、Cloudflare Workers、阿里云函数计算等平台的差异。

参考答案：

平台	类型	特点
AWS Lambda	FaaS	生态最全，事件源丰富，冷启动相对较高
Vercel Functions	FaaS/Edge	与 Next.js 深度集成，部署简单
Cloudflare Workers	Edge Runtime	全球边缘节点、V8 Isolate、低延迟、KV/D1/R2
阿里云函数计算	FaaS	国内生态，触发器丰富，与阿里云产品集成
腾讯云 SCF	FaaS	国内可用区多，与微信生态结合
Deno Deploy	Edge Runtime	TypeScript 原生、V8 Isolate、边缘部署

选型考虑：

延迟要求：Edge Runtime 更低。
生态绑定：是否与现有云厂商/框架绑定。
语言支持：Cloudflare Workers 支持 JS/TS/Rust/Go 等编译为 WASM。
成本模型：调用次数、CPU 时间、出站流量。

评分维度：

平台特点（50%）：能区分 Lambda、Vercel、Cloudflare
选型维度（30%）：延迟、生态、语言、成本
国内/国际（20%）：阿里云、腾讯云

常见错误：

认为所有平台都支持任意语言运行时。
忽略 Edge 与传统 FaaS 的架构差异。

延伸追问：

Cloudflare Workers 的 V8 Isolate 与传统容器有什么区别？
多平台部署如何统一管理？

相关题目：

FB-35-CO-B-002 Edge Computing 与 CDN
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

Vercel Edge Functions

口头回答版：

AWS Lambda 生态最全但冷启动高；Vercel 与 Next.js 集成好；Cloudflare Workers 在边缘节点跑 V8 Isolate，延迟低；国内用阿里云函数计算、腾讯云 SCF。选型看延迟、生态、语言、成本。

进阶题（8 道）

FB-35-CO-A-001：什么是 SSR at Edge？它解决了什么问题？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：SSR at Edge、边缘渲染、Next.js、Vercel、Cloudflare 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请解释 SSR at Edge 的概念、优势和实现方式。

参考答案：

SSR at Edge 是在靠近用户的边缘节点执行服务端渲染，而不是回源到中心服务器。

优势：

低延迟：用户请求在边缘节点处理，减少网络往返。
高可用：边缘节点多，故障影响面小。
动态个性化：根据用户位置、语言、设备在边缘生成页面。
成本优化：边缘计算通常比中心服务器更便宜。

实现方式：

Next.js on Vercel：edge runtime 标记的 API/页面在边缘执行。
Cloudflare Pages + Workers：用 Workers 做边缘渲染。
Nuxt / SvelteKit：支持 edge 部署目标。

限制：

边缘运行时有 CPU/内存限制，不能执行重逻辑。
某些 Node.js API 不可用。
与中心数据库连接可能不稳定或延迟高。

评分维度：

概念（30%）：边缘节点 SSR
优势（30%）：低延迟、高可用、个性化
实现方式（30%）：Next.js、Cloudflare
限制（10%）：资源、API、数据库

常见错误：

把所有 SSR 逻辑放 Edge，导致性能下降。
忽略 Edge Runtime 与 Node.js 的 API 差异。

延伸追问：

Edge SSR 与 ISR 如何结合？
在 Edge 上渲染时如何获取用户认证信息？

相关题目：

FB-35-CO-B-002 Edge Computing 与 CDN
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

Next.js Edge Runtime

口头回答版：

SSR at Edge 是在靠近用户的边缘节点做服务端渲染，延迟低、可用性高、支持动态个性化。Next.js 和 Vercel、Cloudflare Workers 都支持。但要注意边缘运行时有资源限制，不能跑重逻辑。

FB-35-CD-A-001：Edge 函数如何实现路由改写与 A/B 测试？

题型：场景设计题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：Edge 路由、A/B 测试、重写、重定向 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请设计一个 Edge 函数，根据用户特征做路由改写或 A/B 分流。

参考答案：

实现思路：

在 Edge 拦截 HTTP 请求。
根据 Cookie、请求头、URL、用户 ID 哈希决定分组。
改写请求 URL 或返回 302/307 重定向。

示例逻辑：

export default {
  async fetch(request) {
    const url = new URL(request.url);
    const exp = request.headers.get('Cookie')?.match(/exp=([^;]+)/)?.[1];
    const group = exp || (Math.random() < 0.5 ? 'A' : 'B');
    url.pathname = `/variant-${group}${url.pathname}`;
    return fetch(url, request);
  }
};

要点：

分组应稳定（基于 userId 哈希），避免用户每次刷新看到不同版本。
使用 Cookie 记录分组，便于分析。
对搜索引擎蜘蛛返回 canonical 版本，避免 SEO 分散。
监控各组指标，自动判断胜出版本。

评分维度：

路由改写（40%）：URL 改写、重定向
A/B 设计（30%）：分组稳定、Cookie、蜘蛛处理
可观测性（30%）：指标、归因

常见错误：

随机分组导致用户体验不一致。
未处理爬虫，导致 SEO 权重分散。

延伸追问：

Edge A/B 与客户端 A/B 有什么区别？
如何保证 A/B 分组在多个边缘节点一致？

相关题目：

FB-35-CO-A-001 SSR at Edge
FB-35-SD-R-002 设计 Edge 网关

参考资源：

Cloudflare A/B Testing

口头回答版：

Edge 函数拦截请求，根据 Cookie 或 userId 哈希决定 A/B 分组，然后改写 URL 或重定向。分组要稳定，给蜘蛛返回 canonical 版本，监控指标。Edge A/B 比客户端更早生效，延迟更低。

FB-35-CO-A-002：边缘缓存策略如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：边缘缓存、Cache-Control、CDN、Cache Key、ISR 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明在 Edge/Serverless 场景下如何设计缓存策略，平衡实时性与性能。

参考答案：

缓存层级：

浏览器缓存：Cache-Control、ETag、Last-Modified。
CDN/Edge 缓存：根据 URL、Cookie、Header 生成 Cache Key。
源站/应用缓存：Redis、应用内存缓存。

Edge 缓存策略：

静态资源：长期缓存 + 文件名 hash，更新时 URL 变。
页面：
- 全静态页面：长时间缓存。
- 半动态页面：ISR，设置 stale-while-revalidate，边缘返回旧版本并在后台刷新。
- 全动态页面：短缓存或不缓存。
Cache Key 设计：
- 不要把用户敏感信息放进 Cache Key。
- 按 locale、device、AB 分组区分缓存。
清除缓存：
- API 调用 CDN purge。
- 版本化 URL。
- 低 TTL + stale-while-revalidate。

评分维度：

缓存层级（30%）：浏览器、Edge、源站
页面策略（30%）：静态、ISR、动态
Cache Key（20%）：分组、安全
清除（20%）：purge、版本化、SWR

常见错误：

所有页面都设 no-cache，性能差。
Cache Key 包含用户 ID，导致缓存命中率低。

延伸追问：

ISR 与 SSR at Edge 的缓存区别？
如何处理边缘缓存中的个性化内容？

相关题目：

FB-35-CO-A-001 SSR at Edge
FB-35-SD-R-002 设计 Edge 网关

参考资源：

MDN Cache-Control

口头回答版：

边缘缓存分浏览器、Edge、源站三层。静态资源长期缓存，半动态用 ISR 加 stale-while-revalidate，全动态短缓存。Cache Key 按 locale、device、AB 分组，不要放敏感信息。清除缓存可 purge 或版本化 URL。

FB-35-SE-A-001：Serverless 安全与权限如何管理？

题型：安全题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：Serverless 安全、IAM、权限、密钥、最小权限 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明 Serverless 应用中的安全风险和权限管理最佳实践。

参考答案：

安全风险：

函数权限过大，可访问不必要资源。
密钥硬编码在代码或环境变量中。
事件注入、SQL 注入等常规 Web 风险。
公共 API Gateway 未做认证/限流。
供应链攻击（依赖包、CI 环境）。

最佳实践：

最小权限 IAM：每个函数只授予所需资源权限。
密钥管理：使用 KMS、Secrets Manager、Vault，不在代码中硬编码。
输入校验：对所有事件输入做校验和消毒。
认证授权：API Gateway + OAuth/JWT/签名。
网络隔离：敏感函数放 VPC/PrivateLink，限制出站。
日志审计：开启 CloudTrail/审计日志，监控异常调用。
依赖安全：定期扫描依赖，锁定版本。

Edge 安全：

边缘函数也可做 WAF、Bot 检测、DDoS 缓解。
注意 Edge 代码暴露给客户端的风险（不要泄露密钥）。

评分维度：

风险识别（30%）：权限、密钥、注入、公共 API
权限管理（30%）：IAM 最小权限、密钥管理
防护实践（40%）：输入校验、认证、审计、依赖

常见错误：

给所有函数同一个超级权限角色。
把数据库密码直接放环境变量，不轮换。

延伸追问：

Edge 函数如何安全调用私有 API？
Serverless 中如何进行 secrets 轮换？

相关题目：

FB-31-CO-B-005 前端敏感数据存储
FB-35-SD-R-002 设计 Edge 网关

参考资源：

OWASP Serverless Top 10

口头回答版：

Serverless 安全风险有权限过大、密钥泄露、注入、公共 API 未限流。最佳实践是最小权限 IAM、密钥放 KMS、输入校验、API 认证、网络隔离、日志审计、依赖扫描。Edge 可以做 WAF 和 Bot 检测，但别把密钥暴露出去。

FB-35-CO-A-003：Serverless 中的状态持久化有哪些方案？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：状态持久化、Serverless、KV、D1、对象存储、数据库 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明 Serverless/Edge 函数中持久化状态的常用方案及选型依据。

参考答案：

方案：

对象存储：S3/R2/OSS，适合文件、图片、日志。
键值存储：Cloudflare KV、DynamoDB、Redis，适合会话、缓存、计数。
Serverless 数据库：Cloudflare D1、PlanetScale、FaunaDB、Supabase，适合关系/文档数据。
消息队列：SQS/SNS、Kafka，适合异步任务和解耦。
中心数据库：RDS/Aurora 通过 connection pooler（如 RDS Proxy）连接。

选型依据：

延迟：Edge KV 低延迟但全球一致弱；D1 提供 SQLite 兼容。
一致性：强一致选关系型数据库；最终一致选 KV。
数据模型：结构化数据用 SQL，非结构化用文档/KV。
成本：按读写次数、存储、出站流量计费。

Edge 注意：

Edge 函数通常不支持长连接，优先用 HTTP 协议的数据库或 KV。
写操作跨地域复制可能有延迟。

评分维度：

方案覆盖（40%）：对象存储、KV、数据库、队列
选型依据（30%）：延迟、一致性、模型、成本
Edge 限制（30%）：HTTP 协议、复制延迟

常见错误：

在函数中直连传统数据库，导致连接数耗尽。
用 KV 做事务性操作，导致数据不一致。

延伸追问：

Edge KV 的全球一致性问题如何解决？
Serverless 数据库和传统数据库的连接方式有什么不同？

相关题目：

FB-35-CO-B-005 无状态设计
FB-35-CO-A-004 冷启动优化

参考资源：

Cloudflare D1

口头回答版：

Serverless 状态持久化可用对象存储、KV、Serverless 数据库、消息队列、中心数据库加连接池。选型看延迟、一致性、数据模型、成本。Edge 优先用 HTTP 协议存储，注意跨地域复制延迟。不要函数直连传统数据库。

FB-35-PE-A-001：Serverless 冷启动如何优化？

题型：性能优化题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：冷启动优化、Provisioned Concurrency、精简依赖、预热 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明降低 Serverless 函数冷启动时间的方法。

参考答案：

优化方法：

精简依赖：移除未使用包，使用 bundler（esbuild/webpack）打包并 tree-shaking。
初始化外置：把数据库连接、HTTP 客户端放在处理函数外，利用热启动复用。
延迟加载：非必要模块在首次使用时导入。
增加内存/CPU：更大的内存通常对应更快的 CPU。
避免 VPC：如无必要，不在 VPC 中运行函数。
使用轻量运行时：Node.js 18/20 启动较快。
Provisioned Concurrency：预置并发，保持函数实例热备。
Keep-alive：定时触发（ping）保持实例活跃。
Edge Runtime：将延迟敏感逻辑迁移到 Edge。

监控：

记录 Init Duration、Billed Duration。
分析依赖加载耗时。

评分维度：

依赖优化（30%）：精简、tree-shaking、延迟加载
运行时优化（30%）：初始化外置、内存、VPC
预热策略（30%）：Provisioned Concurrency、ping、Edge
监控（10%）：Init Duration

常见错误：

每次调用都重新创建数据库连接。
为降低冷启动而无限预热，成本飙升。

延伸追问：

Provisioned Concurrency 与 Keep-alive 的成本对比？
如何在不预热的情况下降低 Java 函数冷启动？

相关题目：

FB-35-CO-B-003 冷启动与热启动
FB-35-CO-A-003 状态持久化

参考资源：

AWS Lambda Provisioned Concurrency

口头回答版：

优化冷启动要精简依赖、初始化外置、延迟加载、加大内存、避免 VPC、用轻量运行时。关键业务可用 Provisioned Concurrency 或定时 ping 预热，延迟敏感逻辑放 Edge。还要监控 Init Duration。

FB-35-CO-A-004：Serverless 成本模型与计费如何评估？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：Serverless 成本、计费、按调用、GB-秒、成本优化 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明 Serverless 的计费维度，以及如何控制和优化成本。

参考答案：

计费维度：

调用次数：每次函数调用计费。
执行时间：按毫秒计费，与内存大小相关。
资源用量：GB-秒 = 内存大小 × 执行时间。
出站流量：响应数据、访问外部服务产生的流量。
存储/数据库：KV、对象存储、数据库按容量和请求计费。
边缘请求：Edge 函数按请求数或 CPU 时间计费。

成本控制：

优化函数执行时间，减少无效循环和重试。
合理选择内存，避免过大浪费。
使用缓存减少重复计算和数据库访问。
设置并发上限和超时时间，防止无限循环。
监控账单，设置预算告警。
对高流量静态内容使用 CDN 而非函数。

评估方法：

建立成本模型，按 QPS、平均执行时间估算。
对比传统服务器 TCO。

评分维度：

计费维度（40%）：调用、时间、资源、流量、存储
成本控制（40%）：执行时间、内存、缓存、上限
评估方法（20%）：成本模型、预算告警

常见错误：

只关注调用次数，忽略执行时间和出站流量。
未设置并发上限，被 DDoS 或重试导致高额账单。

延伸追问：

如何防止 Serverless 账单失控？
高并发场景下 Serverless 是否一定比服务器便宜？

相关题目：

FB-35-CO-B-006 Serverless 优缺点
FB-35-SD-R-005 Serverless 成本控制策略

参考资源：

AWS Lambda Pricing

口头回答版：

Serverless 计费包括调用次数、执行时间、资源用量 GB-秒、出站流量、存储。成本控制要优化执行时间、合理内存、用缓存、设并发和超时、监控预算。高流量静态内容用 CDN 而不是函数。

FB-35-CO-A-005：Serverless 可观测性如何建设？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：Serverless 可观测性、日志、指标、Tracing、监控 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请说明 Serverless 场景下的日志、指标、链路追踪方案。

参考答案：

可观测性挑战：

函数生命周期短，实例销毁后日志需及时采集。
调用链涉及 API Gateway、函数、数据库、第三方服务。
Edge 函数分布式在全球节点。

方案：

日志：
- 输出结构化日志（JSON）。
- 集中收集到 CloudWatch Logs、Datadog、Sentry、Grafana Loki。
指标：
- 监控调用次数、错误率、延迟、冷启动率、并发数、成本。
- 使用平台自带指标或自定义指标。
链路追踪：
- 使用 OpenTelemetry、AWS X-Ray、Jaeger。
- 在请求头传递 trace context。
告警：
- 错误率突增、P99 延迟、冷启动率、成本超预算。
Edge 监控：
- 分地区监控延迟和错误。
- 采集 CSP 报告、边缘缓存命中率。

评分维度：

日志（25%）：结构化、集中收集
指标（25%）：调用、错误、延迟、成本
链路追踪（25%）：OpenTelemetry、trace context
告警与 Edge（25%）：阈值、分地区

常见错误：

只打印文本日志，无法聚合分析。
忽略冷启动和成本指标。

延伸追问：

如何在多个云厂商间统一可观测性？
Edge 函数日志如何快速聚合？

相关题目：

FB-30-SD-R-001 可观测性体系设计
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

OpenTelemetry Serverless

口头回答版：

Serverless 可观测性要输出结构化日志，集中收集；监控调用、错误、延迟、冷启动、成本；用 OpenTelemetry 做链路追踪，传递 trace context；设置错误率和延迟告警。Edge 还要分地区监控。

深入题（7 道）

FB-35-CO-P-001：边缘函数与微服务边界如何划分？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：边缘函数、微服务、边界、BFF、职责 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明 Edge 函数、FaaS 函数、传统微服务之间的职责边界，以及如何划分。

参考答案：

职责边界：

层级	职责	代表
Edge 函数	请求路由改写、A/B、认证前置、缓存、轻量 SSR	Cloudflare Workers
FaaS 函数	业务 API、事件处理、编排、轻量计算	AWS Lambda
微服务/容器	复杂业务逻辑、长事务、重计算、状态服务	Kubernetes
数据库/存储	持久化状态	RDS、DynamoDB、R2

划分原则：

延迟敏感放 Edge：如 GEO 重定向、缓存、简单鉴权。
有状态/重逻辑放后端：复杂计算、事务、长连接。
FaaS 做胶水层：聚合多个后端服务、格式化响应。
避免在 Edge 做重计算：资源受限，影响响应时间。
安全边界：Edge 可做 WAF、Bot 检测，不暴露内部服务。

演进路径：

早期可用 Edge/FaaS 快速验证。
业务复杂后，把重逻辑下沉到微服务。

评分维度：

边界清晰（40%）：Edge、FaaS、微服务、存储
划分原则（40%）：延迟、状态、安全、演进
实践案例（20%）：举例说明

常见错误：

在 Edge 函数中实现全部业务逻辑。
所有请求都穿透到中心微服务，浪费 Edge 价值。

延伸追问：

边缘函数调用中心服务时如何保证低延迟？
何时应该把 FaaS 升级为容器微服务？

相关题目：

FB-35-CO-A-001 SSR at Edge
FB-35-SD-R-002 设计 Edge 网关

参考资源：

Cloudflare Workers Patterns

口头回答版：

Edge 函数做路由改写、A/B、轻量鉴权和缓存；FaaS 做业务 API 和事件处理；复杂有状态逻辑放微服务。划分看延迟、状态和安全。不要在 Edge 做重计算，也不要让请求都回源。

FB-35-CO-P-002：多区域部署与一致性如何权衡？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：多区域、一致性、边缘、CAP、复制延迟 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请分析 Serverless/Edge 应用在全球多区域部署时面临的一致性问题与解决方案。

参考答案：

挑战：

用户写入一个区域，其他区域读取可能读到旧数据（复制延迟）。
不同区域的函数实例可能同时修改同一数据。
强一致跨区访问延迟高。

解决方案：

数据分区：按用户/区域把数据存储在离用户最近的区域，减少跨区访问。
最终一致：对非关键数据接受短暂不一致，使用 CRDT/LWW 合并。
强一致场景：
- 使用全球分布式数据库（如 CockroachDB、Spanner、Fauna）。
- 或把写操作路由到单一主区域。
读写分离：读就近，写集中。
冲突解决：版本向量、时间戳、业务规则。
用户体验：对写操作给出本地成功反馈，异步同步。

CAP 权衡：

边缘场景通常优先 AP（可用 + 分区容错），必要时在特定操作上牺牲可用性保证一致。

评分维度：

一致性问题（30%）：复制延迟、并发写
解决方案（40%）：分区、最终一致、强一致、读写分离
权衡（30%）：CAP、用户体验

常见错误：

所有操作都追求强一致，导致全球延迟高。
忽略跨区域网络分区的可能性。

延伸追问：

如何设计一个全球可用的购物车？
Edge KV 的多区域一致性如何评估？

相关题目：

FB-35-CO-A-003 状态持久化
FB-35-SD-R-004 边缘与中心协同

参考资源：

CAP Theorem

口头回答版：

多区域部署面临复制延迟和并发写。可以按区域分区数据、非关键数据接受最终一致、关键写路由到主区或用全球数据库、读写分离。边缘通常优先 AP，强一致操作要集中处理。

FB-35-CO-P-003：Serverless 框架选型与部署如何决策？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：Serverless Framework、SST、Pulumi、Terraform、部署 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请比较常见 Serverless 部署工具（Serverless Framework、SST、Pulumi、Terraform、SAM），并给出选型建议。

参考答案：

工具	特点	适用
Serverless Framework	老牌、插件多、YAML 配置	快速上手、中小项目
AWS SAM	AWS 官方、与 CloudFormation 集成	纯 AWS 环境
SST	基于 AWS CDK，TypeScript 友好，本地开发体验好	AWS + 现代前端
Pulumi	多语言基础设施即代码	多云、团队偏好编程语言
Terraform	多云、状态管理强	已有 Terraform 实践
AWS CDK	AWS 原生、编程式 IaC	AWS 深度用户

选型考虑：

云厂商绑定：单云可用官方工具，多云用 Pulumi/Terraform。
团队技能：熟悉 TypeScript 选 SST/CDK，熟悉 Go/Python 选 Pulumi。
本地体验：SST 的 Live Lambda Development 便于调试。
基础设施复杂度：简单函数用 Serverless Framework，复杂系统用 CDK/Pulumi。

最佳实践：

基础设施即代码，版本控制。
分环境（dev/staging/prod）管理。
敏感配置用 Secrets Manager 而非硬编码。

评分维度：

工具对比（40%）：特点与适用
选型维度（30%）：云绑定、技能、体验
实践（30%）：IaC、分环境、密钥

常见错误：

手动在控制台创建资源，不可复现。
选择工具时忽视团队学习成本。

延伸追问：

如何实现 Serverless 资源的多环境隔离？
部署回滚策略如何设计？

相关题目：

FB-35-CO-B-007 本地开发与调试
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

SST Documentation

口头回答版：

Serverless Framework 老牌简单；SAM 适合 AWS；SST 基于 CDK、TypeScript 体验好；Pulumi 多云多语言；Terraform 多云状态管理好。选型看云绑定、团队技能、本地调试体验。要用 IaC、分环境、密钥不硬编码。

FB-35-SE-P-001：Edge 上的认证与授权如何设计？

题型：安全题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：Edge 认证、JWT、OAuth、零信任、边缘鉴权 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请设计一个在 Edge 节点完成的认证与授权方案。

参考答案：

方案：

JWT 校验：
- Edge 函数验证 JWT 签名和过期时间。
- 无需回源到认证服务，降低延迟。
- 注意 JWT 不应在 Edge 暴露密钥，使用 JWKS 或预置公钥。
Token 刷新：
- Refresh Token 通常由中心认证服务处理，Edge 可代理。
- 短有效期 Access Token 适合 Edge 校验。
OAuth/OIDC：
- Edge 作为 OAuth Resource Server，校验 Bearer Token。
- 登录流程仍由中心 IdP 处理。
ABAC/RBAC：
- 将角色/权限嵌入 JWT claims。
- Edge 根据 claims 决定是否放行或改写请求。
零信任：
- 每个请求都校验，不信任内网。
- 结合设备指纹、IP 风险评分。

安全注意：

Edge 代码可被反编译，不要存放长期密钥。
对敏感操作仍需中心服务二次鉴权。

评分维度：

JWT/Token（40%）：校验、刷新、claims
架构（30%）：Edge 与中心 IdP 分工
安全（30%）：密钥、零信任、二次鉴权

常见错误：

Edge 函数中硬编码 JWT 密钥。
把登录会话状态存在 Edge 内存。

延伸追问：

如何在 Edge 实现单点登录？
Edge 校验失败时如何优雅降级？

相关题目：

FB-31-CO-A-002 JWT 安全使用
FB-35-SD-R-002 设计 Edge 网关

参考资源：

Cloudflare Access

口头回答版：

Edge 认证可以用 JWT 本地校验，避免回源；Token 刷新找中心 IdP；角色权限放 claims 里。Edge 不放长期密钥，敏感操作回中心二次鉴权。结合零信任，每个请求都校验。

FB-35-CO-P-004：Serverless 中的隐私合规如何处理？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：隐私合规、GDPR、数据本地化、Serverless、Edge 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请说明在 Serverless/Edge 架构下如何满足 GDPR、个人信息保护法等合规要求。

参考答案：

合规要点：

数据最小化：函数只处理和传输必要数据，不记录敏感信息到日志。
同意管理：
- Edge 函数根据用户同意状态决定是否加载分析/广告脚本。
- Consent 信息通过 Cookie/请求头传递。
数据本地化：
- 按用户地区选择数据存储区域。
- 边缘缓存避免把敏感数据缓存到非授权区域。
访问与删除权：
- 提供 API 让用户导出、删除个人数据。
- 函数调用记录审计日志。
日志与监控：
- 日志脱敏，不在边缘日志中保存 PII。
- 设置日志保留期限。
供应商协议：
- 与云厂商签署 DPA（数据处理协议）。
- 明确数据出境方式和责任。

架构调整：

边缘节点只处理匿名化或已授权数据。
敏感写操作路由到合规区域。

评分维度：

合规措施（50%）：最小化、同意、本地化、删除权、日志
架构调整（30%）：区域路由、敏感数据处理
供应商治理（20%）：DPA、出境

常见错误：

把所有用户数据在全局边缘缓存。
日志中打印用户敏感信息。

延伸追问：

如何在 Edge 实现按地区的数据隔离？
用户删除请求如何在无服务器架构中传播？

相关题目：

FB-31-CO-P-003 隐私合规技术要求
FB-33-CP-R-003 合规与本地化法律要求

参考资源：

GDPR Official Text

口头回答版：

Serverless 合规要数据最小化、按同意状态加载脚本、数据本地化存储、提供导出删除接口、日志脱敏、签 DPA。边缘节点处理匿名数据，敏感写路由到合规区域。

FB-35-CO-P-005：函数编排与 workflow 在 Serverless 中如何实现？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：函数编排、Workflow、Step Functions、事件驱动、Saga 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请说明 Serverless 中多函数协作的编排方式，以及事务一致性处理。

参考答案：

编排方式：

编排器模式：使用 AWS Step Functions、Azure Durable Functions，由中心服务调度函数。
编舞模式（Choreography）：函数通过事件总线（EventBridge、SNS）互相触发，去中心化。
工作流引擎：Temporal、Camunda、Airflow 等编排长流程。
函数内编排：简单顺序调用多个服务，适合短流程。

事务一致性：

Serverless 函数通常避免分布式事务。
使用 Saga 模式：每个步骤本地事务 + 补偿操作。
使用事件溯源记录状态变化，便于回溯和补偿。
对关键业务使用幂等设计 + 唯一键，防止重复执行。

选型：

简单流程：函数内顺序调用。
复杂长流程：Step Functions / Temporal。
高解耦：事件总线 + Choreography。

评分维度：

编排模式（40%）：编排器、编舞、工作流引擎
事务一致性（40%）：Saga、补偿、幂等
选型（20%）：按流程复杂度

常见错误：

在函数间使用同步调用链过长，导致超时和耦合。
没有补偿机制，部分失败无法回滚。

延伸追问：

如何保证跨函数调用的幂等性？
Step Functions 与简单 Lambda 调用链的成本对比？

相关题目：

FB-35-CO-B-004 事件驱动与触发器
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

AWS Step Functions

口头回答版：

Serverless 编排可用中心编排器如 Step Functions，或事件总线编舞模式，或工作流引擎 Temporal。事务用 Saga 本地事务加补偿，关键业务做幂等。不要函数间同步长链调用。

FB-35-CO-P-006：边缘 AI 推理有哪些应用场景与挑战？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：35 Serverless/Edge 标签：边缘 AI、推理、WASM、ONNX、TensorFlow.js 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请说明在 Edge 运行 AI 推理的场景、技术栈和挑战。

参考答案：

应用场景：

实时内容审核（图片、文本）。
个性化推荐排序。
智能输入提示、搜索补全。
设备端图像识别、OCR。

技术栈：

WASM + ONNX Runtime：跨平台运行轻量模型。
TensorFlow.js：浏览器/Node 端推理。
Cloudflare Workers AI：托管模型 API。
边缘 GPU/TPU：部分边缘节点支持硬件加速。

挑战：

模型大小：边缘网络带宽和存储有限，需模型压缩（量化、剪枝）。
延迟：首次加载模型慢，需预加载/缓存。
精度与性能权衡：量化后精度下降。
隐私：模型和输入数据保护。
可观测性：推理延迟、准确率、资源使用监控。

评分维度：

场景（30%）：审核、推荐、识别
技术栈（30%）：WASM、ONNX、TensorFlow.js
挑战（40%）：模型大小、延迟、精度、隐私

常见错误：

把大模型直接部署到 Edge，超出资源限制。
忽视模型更新和版本管理。

延伸追问：

如何在 Edge 上保护模型不被窃取？
模型量化对业务指标有什么影响？

相关题目：

FB-18-CO-A-001 前端集成 LLM
FB-35-SD-R-004 边缘与中心协同

参考资源：

ONNX Runtime Web

口头回答版：

边缘 AI 可用于内容审核、推荐、OCR 等。技术栈有 WASM+ONNX、TensorFlow.js、Workers AI。挑战是模型大小、首次加载延迟、量化精度损失、隐私和监控。要做模型压缩和预加载。

架构题（42 道）

FB-35-SD-R-001：如何设计一个 Serverless 前端架构？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：Serverless 架构、前端、Edge、BFF、CDN 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请为一个现代 Web 应用设计基于 Serverless/Edge 的前端架构，涵盖托管、渲染、API、存储、安全。

参考答案：

架构分层：

边缘层：
- Edge 函数：路由、A/B、认证前置、缓存、简单 SSR。
- CDN：静态资源、缓存页面。
托管层：
- 静态站点托管：Vercel、Cloudflare Pages、S3+CloudFront。
- 构建与部署：Git 触发 CI/CD，自动分发。
API 层：
- FaaS 函数处理业务 API、BFF 聚合。
- 事件触发异步任务。
存储层：
- 对象存储放静态资源、用户上传。
- Serverless 数据库/KV 放状态。
安全层：
- Edge WAF、DDoS 防护、Bot 管理。
- IAM 最小权限、Secrets 管理。
可观测性：
- 日志、指标、Tracing、成本监控。

数据流：

用户请求 -> Edge 函数（路由/缓存/鉴权）。
命中缓存则直接返回；否则调用 FaaS 或回源。
FaaS 访问数据库/第三方 API，返回 JSON 或渲染页面。
客户端 SPA/ islands hydrate。

评分维度：

分层完整（30%）：边缘、托管、API、存储、安全、可观测
数据流（30%）：请求生命周期
选型合理（20%）：Edge/FaaS/存储
可扩展性（20%）：CI/CD、多区域

常见错误：

所有逻辑放在 Edge，超出资源限制。
忽略安全层设计。

延伸追问：

这种架构下如何进行本地开发？
多环境如何隔离？

相关题目：

FB-35-CO-A-001 SSR at Edge
FB-35-SD-R-002 设计 Edge 网关

参考资源：

Vercel Architecture

口头回答版：

Serverless 前端架构边缘层做路由、A/B、鉴权、缓存；托管层放静态站点；API 层用 FaaS 处理业务和 BFF；存储用对象存储和 Serverless 数据库；安全用 WAF、IAM、Secrets；还要可观测。请求先到 Edge，命中缓存直接返回，否则调 FaaS 或回源。

FB-35-SD-R-002：如何设计一个 Edge 网关？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：Edge 网关、路由、限流、认证、缓存 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个部署在全球边缘节点的网关，支持路由、认证、限流、缓存、灰度。

参考答案：

网关职责：

路由：根据路径、方法、Host 路由到不同后端或函数。
认证：JWT/OAuth 校验、API Key 校验。
限流：按 IP、用户、API 维度限流，防止滥用。
缓存：页面/API 响应缓存，支持 Cache Key 定制。
灰度/A/B：按用户特征分流。
改写：URL 重写、请求头增删、响应头处理。
可观测：日志、指标、Tracing。

实现：

Edge Runtime（Cloudflare Workers / Vercel Edge / Lambda@Edge）。
配置中心下发路由规则，支持热更新。
全球分布式部署，就近处理请求。

扩展性：

规则按优先级匹配，支持通配符和正则。
插件化：认证、限流、缓存作为独立插件。
多区域后端健康检查与故障转移。

安全：

WAF 规则、Bot 检测、DDoS 缓解。
mTLS 与后端通信。
敏感操作回源到中心服务。

评分维度：

职责完整（30%）：路由、认证、限流、缓存、灰度
实现方式（30%）：Edge Runtime、配置中心
扩展性（20%）：插件、规则匹配
安全（20%）：WAF、mTLS

常见错误：

网关承担业务逻辑，导致职责不清。
规则过多影响匹配性能。

延伸追问：

Edge 网关与 API Gateway 的关系？
如何保证全球规则一致性？

相关题目：

FB-35-CO-A-001 SSR at Edge
FB-35-SE-A-001 Serverless 安全

参考资源：

Cloudflare Workers KV

口头回答版：

Edge 网关做路由、认证、限流、缓存、灰度和改写。用 Cloudflare Workers 或 Vercel Edge 实现，配置中心热更新规则。要插件化、多区域健康检查、WAF 和 mTLS。不要把业务逻辑放网关。

FB-35-SD-R-003：Serverless 与容器/传统服务器如何取舍？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：Serverless、容器、Kubernetes、传统服务器、取舍 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请分析 Serverless、容器（Kubernetes）、传统服务器各自的适用场景和取舍标准。

参考答案：

维度	Serverless	容器/K8s	传统服务器
运维	最少	中等	最多
弹性	自动	需配置 HPA	手动
启动速度	毫秒-秒级	秒-分钟级	分钟级
运行时长	受限	不受限	不受限
成本模式	按调用	按资源	按资源
控制度	低	高	最高
延迟	可能有冷启动	稳定	稳定

取舍：

Serverless：事件驱动、低频、突发、快速迭代、前端 BFF/SSR。
容器：需要自定义运行时、长服务、复杂依赖、团队有 K8s 能力。
传统服务器：强合规、遗留系统、需要裸机性能。

混合架构：

前端/边缘/网关用 Serverless。
核心业务服务用容器。
数据库、消息队列用托管服务。

评分维度：

对比清晰（40%）：运维、弹性、成本、控制
取舍能力（30%）：场景匹配
混合架构（30%）：组合使用

常见错误：

全站 Serverless，忽视长期运行和复杂调试需求。
为使用 K8s 而过早引入容器。

延伸追问：

如何从单体服务逐步迁移到 Serverless？
Serverless 和 K8s 的成本在什么流量拐点会反转？

相关题目：

FB-35-CO-B-006 Serverless 优缺点
FB-35-SD-R-001 设计 Serverless 前端架构

参考资源：

AWS Container vs Serverless

口头回答版：

Serverless 运维最少、自动弹性、按调用付费，适合事件驱动和前端场景；容器控制度高、适合长服务和复杂依赖；传统服务器适合强合规和遗留系统。实际常混合：前端用 Serverless，核心服务用容器，数据库用托管服务。

FB-35-SD-R-004：如何设计边缘与中心协同架构？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：边缘、中心、协同、缓存、一致性、数据同步 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个边缘处理与中心服务协同的架构，说明数据流、一致性和故障处理。

参考答案：

协同原则：

边缘负责近用户、轻量、延迟敏感：缓存、鉴权、路由、简单计算、SSR。
中心负责重逻辑、状态、一致性：业务核心、数据库、事务、批量处理。

数据流：

用户请求 -> 边缘节点。
边缘判断：命中缓存/可本地处理 -> 直接响应。
否则边缘调用中心 API，可聚合多个请求。
中心返回数据，边缘按需缓存。
写请求：边缘校验后转发中心，或异步处理。

一致性：

读操作优先本地缓存，TTL 控制。
写操作回中心，成功后失效边缘缓存。
对强一致读，绕过缓存直接回中心。

故障处理：

边缘缓存作为中心故障时的降级。
中心不可用时，边缘返回过期数据或静态页面。
写操作失败时排队重试或通知用户。

同步机制：

消息队列/EventBridge 异步同步中心状态到边缘缓存。
版本号/Etag 校验缓存有效性。

评分维度：

职责划分（30%）：边缘 vs 中心
数据流（30%）：请求生命周期、缓存
一致性（20%）：读写策略、缓存失效
故障处理（20%）：降级、重试

常见错误：

边缘和中心职责重叠，导致数据不一致。
写操作在边缘本地处理，无法同步。

延伸追问：

如何设计边缘缓存的失效策略？
边缘与中心网络分区时怎么办？

相关题目：

FB-35-CO-A-002 边缘缓存策略
FB-35-CO-P-002 多区域一致性

参考资源：

Cloudflare Cache API

口头回答版：

边缘做缓存、鉴权、路由、轻量 SSR，中心做业务核心和数据库。请求先到边缘，命中缓存直接返回；否则调中心并缓存结果。写回中心后失效缓存。中心故障时边缘可降级返回缓存。一致性通过 TTL、版本号、消息队列保证。

FB-35-CP-R-001：组织级 Serverless 治理如何推进？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：Serverless 治理、规范、平台、成本、安全 出现频率：中频 预计回答时长：10-15 分钟

题目描述：作为架构师，你如何推动公司多团队规范使用 Serverless/Edge？

参考答案：

治理框架：

统一平台：
- 统一 Serverless/Edge 部署平台、账号、IAM 角色。
- 提供脚手架、CI/CD 模板、可观测性套件。
规范与基线：
- 函数命名、目录结构、日志格式、超时、内存、并发上限。
- 安全基线：最小权限、Secrets 管理、输入校验。
成本治理：
- 按团队/项目分账，设置预算告警。
- 定期清理废弃函数和资源。
可观测性：
- 统一日志、指标、Tracing、告警。
- 监控冷启动、错误率、P99、成本。
培训与社区：
- Serverless 最佳实践培训、案例分享。
- 内部技术委员会评审架构。
治理工具：
- Policy as Code（OPA、AWS Config）检查违规。
- 成本 Dashboard、函数健康评分。

推进策略：

从试点项目证明价值。
解决团队痛点（如部署慢、调试难）。
用数据说话，展示成本和效率收益。

评分维度：

治理框架（40%）：平台、规范、成本、可观测
安全与成本（30%）：IAM、预算、清理
推进策略（30%）：试点、痛点、数据

常见错误：

各团队各自为政，函数散落，成本失控。
规范过于严格，阻碍业务创新。

延伸追问：

如何处理团队对 Vendor Lock-in 的担忧？
Serverless 函数数量爆炸后如何管理？

相关题目：

FB-35-SD-R-001 设计 Serverless 前端架构
FB-35-SD-R-005 Serverless 成本控制策略

参考资源：

AWS Well-Architected Serverless

口头回答版：

组织级 Serverless 治理要统一平台和部署流程，制定命名、安全、成本基线，统一可观测，按团队分账和预算告警。用 Policy as Code 检查违规，培训分享。先试点证明价值，再推广。

FB-35-CP-R-002：Serverless 成本控制策略有哪些？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：Serverless 成本、优化、计费、预算、FinOps 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一套 Serverless 成本控制体系，防止账单失控并持续优化。

参考答案：

成本控制体系：

预算与告警：
- 按项目/团队设置月度预算。
- 超阈值时邮件/短信/IM 告警，必要时自动限流。
资源配额：
- 限制函数内存、超时、并发上限。
- 限制出站流量和第三方 API 调用。
成本归因：
- 使用标签/命名空间标记函数归属。
- Dashboard 展示各团队成本。
优化措施：
- 精简依赖，减少执行时间。
- 合理配置内存，避免浪费。
- 使用缓存降低重复调用。
- 对低频函数降低调用频率或合并。
- 用 Edge/CDN 替代函数处理静态/缓存请求。
定期审计：
- 清理无调用函数、废弃版本。
- 评估 Provisioned Concurrency 是否必要。
FinOps 文化：
- 让团队了解成本构成，把成本作为工程指标。

评分维度：

预算告警（30%）：阈值、通知、自动限流
资源配额（20%）：内存、超时、并发
优化措施（30%）：依赖、缓存、Edge
审计文化（20%）：清理、FinOps

常见错误：

只看总账单，不拆分到函数和团队。
无限预热导致 Provisioned Concurrency 成本飙升。

延伸追问：

如何量化某个优化措施节省的成本？
成本异常时如何快速定位根因？

相关题目：

FB-35-CO-A-004 Serverless 成本模型
FB-35-CP-R-001 组织级 Serverless 治理

参考资源：

AWS Cost Explorer

口头回答版：

Serverless 成本控制要设预算和告警、限制资源配额、用标签归因、优化执行时间和内存、用缓存和 Edge 减少调用、定期清理废弃函数。还要建立 FinOps 文化，让团队关注成本。

FB-35-CP-R-003：全球化边缘渲染平台如何设计？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：35 Serverless/Edge 标签：全球化、边缘渲染、SSR、CDN、多区域 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个面向全球用户的边缘渲染平台，支持 SSR、ISR、个性化和合规。

参考答案：

架构：

边缘节点：
- 全球分布的 Edge Runtime（Cloudflare Workers / Vercel Edge）。
- 处理请求路由、鉴权、A/B、SSR、缓存。
构建系统：
- CI/CD 构建多语言/多地区页面。
- 产物分发到全球 CDN。
缓存策略：
- 静态页面长期缓存。
- ISR 页面 stale-while-revalidate。
- 个性化内容按 Cookie/Header 生成 Cache Key。
数据源：
- 边缘 KV/Cache 存储配置和热点数据。
- 中心 CMS/API 提供动态内容。
合规：
- 按地区选择数据存储和渲染节点。
- 敏感数据不缓存到未授权区域。

关键能力：

就近渲染，降低 TTFB。
多语言、多货币、多时区自动适配。
灰度发布和快速回滚。
全链路监控（分地区延迟、错误、缓存命中）。

评分维度：

边缘架构（30%）：Edge Runtime、CDN
缓存与个性化（30%）：ISR、Cache Key
合规与数据（20%）：区域、敏感数据
可观测性（20%）：分地区监控

常见错误：

个性化内容没有单独 Cache Key，导致用户看到他人数据。
忽视数据本地化合规。

延伸追问：

如何处理边缘节点与中心 CMS 的数据一致性？
全球化平台如何支持快速回滚？

相关题目：

FB-35-SD-R-001 设计 Serverless 前端架构
FB-33-SD-R-001 设计全球化前端架构

参考资源：

Vercel Edge Network

口头回答版：

全球化边缘渲染平台在全球 Edge Runtime 处理路由、鉴权、A/B、SSR 和缓存。构建系统产出多语言页面分发 CDN，ISR 用 stale-while-revalidate，个性化按 Cookie/Header 分 Cache Key。敏感数据按地区处理，全链路分地区监控。

FB-35-CO-B-009：什么是 Serverless？它的优缺点是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：Serverless、FaaS、CDN、边缘函数、预热 出现频率：中频 预计回答时长：3-5 分钟

题目描述：什么是 Serverless？它的优缺点是什么。

参考答案：

Serverless 是一种云计算模式，开发者编写函数，由平台自动管理服务器和扩缩容。优点是无需运维、按需付费、快速上线；缺点是冷启动、执行时长限制、调试复杂、供应商锁定。

补充说明：

在实际落地 Serverless它的优缺点是什么时，建议结合 Serverless、FaaS、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

定义（40%）
优点（30%）
缺点（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

Serverless 是一种云计算模式，开发者编写函数，由平台自动管理服务器和扩缩容。优点是无需运维、按需付费、快速上线；缺点是冷启动、执行时长限制、调试复杂、供应商锁定。

FB-35-SC-B-001：Edge 计算适合哪些前端场景？

题型：场景设计题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless/Edge 标签：Serverless、FaaS、CDN、边缘函数、预热 出现频率：中频 预计回答时长：3-5 分钟

题目描述： Edge 计算适合哪些前端场景。

参考答案：

边缘 SSR、A/B 测试、灰度分流、地理位置个性化、安全网关、请求改写、边缘缓存。

补充说明：

在实际落地 Edge 计算适合哪些前端场景时，建议结合 Serverless、FaaS、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 补充说明：

在实际落地 Edge 计算适合哪些前端场景时，建议结合 Serverless、FaaS、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

场景覆盖（60%）
原因说明（40%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

边缘 SSR、A/B 测试、灰度分流、地理位置个性化、安全网关、请求改写、边缘缓存。

FB-35-CO-B-010：什么是冷启动？如何缓解？

题目描述：什么是冷启动？如何缓解。

参考答案：

冷启动是函数长时间未调用后首次调用时的初始化延迟。缓解方法：减少依赖、使用轻量运行时、预留实例、保持活跃、使用 Edge 函数降低延迟。

补充说明：

在实际落地冷启动如何缓解时，建议结合 Serverless、FaaS、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

原因（40%）
缓解方法（60%）

二、进阶题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

冷启动是函数长时间未调用后首次调用时的初始化延迟。缓解方法：减少依赖、使用轻量运行时、预留实例、保持活跃、使用 Edge 函数降低延迟。

FB-35-CO-A-006：Serverless 架构下如何做好可观测性？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：35 Serverless/Edge 标签：Serverless、FaaS、CDN、边缘函数、预热 出现频率：中频 预计回答时长：5-8 分钟

题目描述： Serverless 架构下如何做好可观测性。

参考答案：

结构化日志输出。
接入分布式追踪。
监控调用次数、错误率、延迟、冷启动次数。
设置告警阈值。

补充说明：

在实际落地 Serverless 架构下如何做好可观测性时，建议结合 Serverless、FaaS、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

日志（25%）
指标（25%）
追踪（25%）
告警（25%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

结构化日志输出。 - 接入分布式追踪。 - 监控调用次数、错误率、延迟、冷启动次数。

FB-35-CO-A-007：如何避免 Serverless 供应商锁定？

题目描述：如何避免 Serverless 供应商锁定。

参考答案：

抽象函数入口和事件模型。
避免使用供应商特有的 API。
使用开源框架（如 Serverless Framework、OpenFaaS）。
核心逻辑与部署配置分离。

补充说明：

在实际落地避免 Serverless 供应商锁定时，建议结合 Serverless、FaaS、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

抽象层（40%）
避免专有 API（30%）
工具选择（30%）

三、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

抽象函数入口和事件模型。 - 避免使用供应商特有的 API。 - 使用开源框架（如 Serverless Framework、OpenFaaS）。 - 核心逻辑与部署配置分离。

FB-35-CO-B-011：什么是 Serverless，它解决了什么问题

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、FaaS、BaaS、运维、成本 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Serverless 的核心概念及前端应用场景。

参考答案：

核心思路如下：

Serverless 让开发者只关注业务代码，无需管理服务器
FaaS：函数即服务，按调用计费
BaaS：后端即服务，如数据库、认证
前端应用：BFF、SSR、边缘渲染、API 聚合
优势：弹性、按需付费、快速上线

需要避免的典型误区：

认为 Serverless 没有服务器
把所有后端逻辑都放函数
忽略冷启动

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Serverless 让开发者只关注业务代码，无需管理服务器、FaaS 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为 Serverless 没有服务器
把所有后端逻辑都放函数
忽略冷启动

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Serverless 让开发者只关注业务代码，无需管理服务器；FaaS；BaaS；前端应用；优势。同时要避免认为 Serverless 没有服务器。

FB-35-CO-A-008：边缘计算与 Serverless 的关系

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：边缘计算、Serverless、CDN、低延迟、Worker 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请比较边缘计算和传统 Serverless/FaaS 的差异。

参考答案：

核心思路如下：

边缘计算运行在 CDN 边缘节点，离用户更近
Serverless FaaS 通常运行在中心云
边缘适合：A/B 测试、个性化渲染、地理路由、API 聚合
FaaS 适合：复杂业务逻辑、长任务、数据库操作
两者可组合：边缘处理请求，FaaS 处理后台

需要避免的典型误区：

边缘函数做复杂计算
忽略边缘节点限制
所有请求都走边缘

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：边缘计算运行在 CDN 边缘节点，离用户更近、Serverless FaaS 通常运行在中心云等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

边缘函数做复杂计算
忽略边缘节点限制
所有请求都走边缘

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

边缘计算运行在 CDN 边缘节点，离用户更近；Serverless FaaS 通常运行在中心云；边缘适合；FaaS 适合；两者可组合。同时要避免边缘函数做复杂计算。

FB-35-SC-A-001：前端如何使用边缘函数做 A/B 测试

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：边缘函数、A/B、灰度、Vercel、Cloudflare 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计一个基于边缘函数的 A/B 测试方案。

参考答案：

核心思路如下：

边缘函数根据用户 cookie/id 分桶
返回不同 HTML 或注入不同配置
保证分桶一致：同一用户始终同一版本
实验指标上报到分析平台
失败回退到默认版本

需要避免的典型误区：

分桶随机导致用户跳动
边缘函数无状态难做复杂逻辑
A/B 版本资源不隔离

补充说明：

在实际落地前端如何使用边缘函数做 A/B 测试时，建议结合边缘函数、A/B、灰度的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：边缘函数根据用户 cookie/id 分桶、返回不同 HTML 或注入不同配置等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

分桶随机导致用户跳动
边缘函数无状态难做复杂逻辑
A/B 版本资源不隔离

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

边缘函数根据用户 cookie/id 分桶；返回不同 HTML 或注入不同配置；保证分桶一致；实验指标上报到分析平台；失败回退到默认版本。同时要避免分桶随机导致用户跳动。

FB-35-CO-A-009：边缘函数的限制与最佳实践

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：边缘函数、限制、冷启动、CPU、内存 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明边缘函数相比传统服务器的限制。

参考答案：

核心思路如下：

执行时间和 CPU 受限
不支持所有 Node API，环境轻量
无状态，不能依赖本地文件系统
网络请求可能受限
调试和日志相对困难
适合轻量、快速、低延迟任务

需要避免的典型误区：

在边缘函数做数据库长连接
边缘函数执行重计算
忽略平台限制导致报错

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：执行时间和 CPU 受限、不支持所有 Node API，环境轻量等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

在边缘函数做数据库长连接
边缘函数执行重计算
忽略平台限制导致报错

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

执行时间和 CPU 受限；不支持所有 Node API，环境轻量；无状态，不能依赖本地文件系统；网络请求可能受限；调试和日志相对困难；适合轻量、快速、低延迟任务。同时要避免在边缘函数做数据库长连接。

FB-35-SC-P-001：设计一个基于边缘的 SSR 渲染方案

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：边缘、SSR、渲染、缓存、Vercel 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请设计在边缘节点执行 SSR 的架构。

参考答案：

核心思路如下：

框架支持：Next.js、Nuxt、SvelteKit 边缘运行时
边缘函数渲染页面并返回 HTML
缓存：渲染结果按 URL + 参数缓存
数据获取：边缘直接调 API 或缓存
降级：渲染失败回退到静态或中心 SSR

需要避免的典型误区：

在边缘做复杂数据库查询
缓存策略过短失去意义
框架不支持边缘运行时

补充说明：

在实际落地设计一个基于边缘的 SSR 渲染方案时，建议结合边缘、SSR、渲染的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：框架支持、边缘函数渲染页面并返回 HTML 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

在边缘做复杂数据库查询
缓存策略过短失去意义
框架不支持边缘运行时

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

框架支持；边缘函数渲染页面并返回 HTML；缓存；数据获取；降级。同时要避免在边缘做复杂数据库查询。

FB-35-CO-P-007：Serverless 冷启动与温启动

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、冷启动、温启动、容器、性能 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请解释冷启动的原因、影响和优化方法。

参考答案：

核心思路如下：

冷启动：函数首次调用需初始化运行时
影响因素：运行时大小、依赖数量、VPC、语言
优化：减小包体积、复用连接、provisioned concurrency
边缘函数冷启动通常更低
对延迟敏感路径预热

需要避免的典型误区：

完全不考虑冷启动
函数包体积过大
每次调用新建数据库连接

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：冷启动、影响因素等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

完全不考虑冷启动
函数包体积过大
每次调用新建数据库连接

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

冷启动；影响因素；优化；边缘函数冷启动通常更低；对延迟敏感路径预热。同时要避免完全不考虑冷启动。

FB-35-SC-A-002：前端 BFF 放在 Serverless 的考量

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：BFF、Serverless、FaaS、API 聚合、成本 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请分析把前端 BFF 迁移到 Serverless 的利弊。

参考答案：

核心思路如下：

利：弹性扩缩、按需付费、快速部署
弊：冷启动、调试复杂、供应商锁定
适合：流量波动大、请求处理轻
不适合：长连接、重计算、强状态
设计：函数拆分、共享连接、缓存

需要避免的典型误区：

把整个单体后端搬上函数
函数间大量同步调用
忽略成本模型

补充说明：

在实际落地前端 BFF 放在 Serverless 的考量时，建议结合 BFF、Serverless、FaaS 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：利、弊等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

把整个单体后端搬上函数
函数间大量同步调用
忽略成本模型

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

利；弊；适合；不适合；设计。同时要避免把整个单体后端搬上函数。

FB-35-CO-A-010：什么是 Edge Side Includes

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：ESI、边缘、缓存、动态内容、CDN 出现频率：低频 预计回答时长：3-5 分钟

题目描述：请解释 ESI 及其在边缘动态渲染中的作用。

参考答案：

核心思路如下：

ESI 是在 CDN 边缘组装页面的标记语言
静态部分缓存，动态部分通过 ESI 请求填充
适合：个性化推荐、用户登录态
减少全页 SSR 压力
不是所有 CDN 都支持

需要避免的典型误区：

在复杂场景滥用 ESI
ESI 接口未做缓存
不支持的平台硬用

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：ESI 是在 CDN 边缘组装页面的标记语言、静态部分缓存，动态部分通过 ESI 请求填充等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

在复杂场景滥用 ESI
ESI 接口未做缓存
不支持的平台硬用

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

ESI 是在 CDN 边缘组装页面的标记语言；静态部分缓存，动态部分通过 ESI 请求填充；适合；减少全页 SSR 压力；不是所有 CDN 都支持。同时要避免在复杂场景滥用 ESI。

FB-35-SC-P-002：Serverless 下如何管理环境变量和密钥

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、密钥、环境变量、KMS、安全 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Serverless 函数中密钥和环境变量的最佳实践。

参考答案：

核心思路如下：

使用平台密钥管理服务或 KMS
敏感变量不提交代码
按环境隔离变量
最小权限原则
定期轮换密钥
审计访问日志

需要避免的典型误区：

密钥硬编码在代码
所有环境共用密钥
函数权限过大

补充说明：

在实际落地 Serverless 下如何管理环境变量和密钥时，建议结合 Serverless、密钥、环境变量的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：使用平台密钥管理服务或 KMS、敏感变量不提交代码等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

密钥硬编码在代码
所有环境共用密钥
函数权限过大

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

使用平台密钥管理服务或 KMS；敏感变量不提交代码；按环境隔离变量；最小权限原则；定期轮换密钥；审计访问日志。同时要避免密钥硬编码在代码。

FB-35-SD-R-006：设计一个 Serverless 前端部署架构

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：35 Serverless 与边缘计算标签：Serverless、部署、静态托管、CDN、边缘 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请为前端应用设计完整的 Serverless 部署架构。

参考答案：

核心思路如下：

静态资源托管：将构建产物上传至对象存储，通过 CDN 全球分发；配置长期缓存、文件名哈希、Brotli/Gzip 压缩与回源策略。
边缘函数：在 CDN 边缘节点部署 Edge Functions，处理路由重写、A/B 实验、简单鉴权、地理位置内容分发与边缘缓存。
渲染策略：对纯静态页面使用 SSG，对千人千面内容使用 SSR/ISR，通过边缘缓存与按需失效降低后端压力。
API 聚合层：使用 FaaS 函数聚合微服务接口，避免前端直接访问过多后端；函数按业务拆分，设置超时、重试与熔断。
域名与证书：统一域名管理，使用自动化 DNS 与 SSL 证书续期；CI/CD 流水线集成构建、测试、部署与回滚。
可观测与回滚：集中化日志、指标监控、告警与链路追踪；部署采用蓝绿或金丝雀策略，确保异常时可快速回滚。

需要避免的典型误区：

忽略缓存策略
所有逻辑放边缘函数
没有回滚策略

补充说明：

在实际落地设计一个 Serverless 前端部署架构时，建议结合 Serverless、部署、静态托管的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：静态资源托管、边缘函数等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

忽略缓存策略
所有逻辑放边缘函数
没有回滚策略

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

静态资源托管；边缘函数；SSR/ISR；API；域名、SSL、CI/CD 自动化；监控。同时要避免忽略缓存策略。

FB-35-CO-P-008：Serverless 的供应商锁定如何应对

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、供应商锁定、可移植、标准 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何降低 Serverless 对云厂商的依赖。

参考答案：

核心思路如下：

业务逻辑与平台 SDK 解耦
使用标准运行时和框架
封装适配层隐藏平台差异
避免深度绑定专有 API
多云部署预案
基础设施即代码便于迁移

需要避免的典型误区：

大量使用厂商专属服务
业务逻辑里调云 SDK
无迁移成本评估

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：业务逻辑与平台 SDK 解耦、使用标准运行时和框架等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

大量使用厂商专属服务
业务逻辑里调云 SDK
无迁移成本评估

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

业务逻辑与平台 SDK 解耦；使用标准运行时和框架；封装适配层隐藏平台差异；避免深度绑定专有 API；多云部署预案；基础设施即代码便于迁移。同时要避免大量使用厂商专属服务。

FB-35-SC-A-003：边缘函数如何做地理位置定向

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：边缘、地理、CDN、路由、个性化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计基于用户地理位置的边缘处理方案。

参考答案：

核心思路如下：

边缘平台提供请求来源国家/地区信息
根据地理位置返回不同内容或路由
结合 CDN 缓存按地区隔离
合规：按地区限制内容
A/B 实验按地区分组

需要避免的典型误区：

IP 地理位置不准确未处理
缓存未按地区区分
合规规则放在前端

补充说明：

在实际落地边缘函数如何做地理位置定向时，建议结合边缘、地理、CDN 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：边缘平台提供请求来源国家/地区信息、根据地理位置返回不同内容或路由等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

IP 地理位置不准确未处理
缓存未按地区区分
合规规则放在前端

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

边缘平台提供请求来源国家/地区信息；根据地理位置返回不同内容或路由；结合 CDN 缓存按地区隔离；合规；A/B 实验按地区分组。同时要避免IP 地理位置不准确未处理。

FB-35-CO-A-011：ISR 与 SSG 的区别

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：ISR、SSG、Next.js、静态生成、增量更新 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请解释 ISR 的概念及与 SSG、SSR 的差异。

参考答案：

核心思路如下：

SSG：构建时生成所有页面
ISR：按需生成并缓存，后台增量更新
SSR：每次请求实时渲染
ISR 兼顾静态性能和动态内容
适合内容更新不频繁的站点

需要避免的典型误区：

ISR 用于强实时数据
不配置重新验证策略
首次访问冷渲染慢

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：SSG、ISR 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

ISR 用于强实时数据
不配置重新验证策略
首次访问冷渲染慢

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

SSG；ISR；SSR；ISR 兼顾静态性能和动态内容；适合内容更新不频繁的站点。同时要避免ISR 用于强实时数据。

FB-35-PE-A-002：Serverless 成本优化策略

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、成本、计费、缓存、优化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明如何控制和优化 Serverless 成本。

参考答案：

核心思路如下：

减少冷启动：provisioned concurrency、keep-warm
缓存：边缘缓存、结果缓存
减少函数执行时间和内存
避免函数间循环调用
监控账单，设置预算告警
选择合适运行时

需要避免的典型误区：

完全不监控费用
每个请求都触发函数
过度预置资源

补充说明：

在实际落地 Serverless 成本优化策略时，建议结合 Serverless、成本、计费的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：减少冷启动、缓存等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

完全不监控费用
每个请求都触发函数
过度预置资源

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

减少冷启动；缓存；减少函数执行时间和内存；避免函数间循环调用；监控账单，设置预算告警；选择合适运行时。同时要避免完全不监控费用。

FB-35-SC-P-003：Serverless 函数的测试策略

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、测试、本地、模拟、集成 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Serverless 函数的测试方法。

参考答案：

核心思路如下：

单元测试：业务逻辑与 handler 解耦
本地模拟：serverless-offline、miniflare
集成测试：部署到测试环境调用
事件模拟：API Gateway、定时触发器
监控和日志验证线上行为

需要避免的典型误区：

只本地测试不上线验证
业务逻辑与平台强耦合难测
忽略事件格式差异

补充说明：

在实际落地 Serverless 函数的测试策略时，建议结合 Serverless、测试、本地的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：单元测试、本地模拟等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只本地测试不上线验证
业务逻辑与平台强耦合难测
忽略事件格式差异

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

单元测试；本地模拟；集成测试；事件模拟；监控和日志验证线上行为。同时要避免只本地测试不上线验证。

FB-35-CO-B-012：什么是 Jamstack

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Jamstack、静态、CDN、无头、Serverless 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Jamstack 架构及其优势。

参考答案：

核心思路如下：

Jamstack：预渲染页面 + CDN + API
优势：高性能、高可用、安全、可扩展
静态生成 + 客户端 API 调用
CMS 无头化提供内容
现代框架：Next.js、Gatsby、Astro

需要避免的典型误区：

所有页面都静态生成
忽略动态需求
API 过多影响体验

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Jamstack、优势等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有页面都静态生成
忽略动态需求
API 过多影响体验

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Jamstack；优势；静态生成 + 客户端 API 调用；CMS 无头化提供内容；现代框架。同时要避免所有页面都静态生成。

FB-35-SC-A-004：如何在 Serverless 中实现用户鉴权

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、鉴权、JWT、Cookie、边缘 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计 Serverless 环境下的前端鉴权方案。

参考答案：

核心思路如下：

使用 JWT 或 session token
边缘函数验证 token 并决定是否放行/渲染
敏感 API 在 FaaS 层再次校验
刷新 token 逻辑放在安全函数
登出失效 token

需要避免的典型误区：

鉴权只在前端
Token 长期有效
边缘和函数鉴权不一致

补充说明：

在实际落地在 Serverless 中实现用户鉴权时，建议结合 Serverless、鉴权、JWT 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：使用 JWT 或 session token、边缘函数验证 token 并决定是否放行/渲染等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

鉴权只在前端
Token 长期有效
边缘和函数鉴权不一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

使用 JWT 或 session token；边缘函数验证 token 并决定是否放行/渲染；敏感 API 在 FaaS 层再次校验；刷新 token 逻辑放在安全函数；登出失效 token。同时要避免鉴权只在前端。

FB-35-CO-P-009：边缘渲染与中心 SSR 的取舍

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：边缘渲染、SSR、延迟、成本、复杂度 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请比较边缘渲染和传统中心 SSR。

参考答案：

核心思路如下：

边缘渲染：低延迟、高可用、轻量计算
中心 SSR：完整能力、易调试、状态重
选择：内容型站点偏边缘，复杂业务偏中心
可混合：边缘处理路由和缓存，中心做重逻辑
注意边缘运行时限制

需要避免的典型误区：

边缘做所有 SSR
忽略边缘缓存
复杂页面强行边缘渲染

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：边缘渲染、中心 SSR 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

边缘做所有 SSR
忽略边缘缓存
复杂页面强行边缘渲染

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

边缘渲染；中心 SSR；选择；可混合；注意边缘运行时限制。同时要避免边缘做所有 SSR。

FB-35-SC-P-004：Serverless 下的数据库连接管理

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、数据库、连接池、RDS Proxy、无状态 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Serverless 函数如何高效使用数据库。

参考答案：

核心思路如下：

函数无状态，连接不能长期保持
使用数据库代理：RDS Proxy、PlanetScale
连接池在函数实例内复用
优先使用无服务器数据库
异常时优雅关闭连接

需要避免的典型误区：

每个请求新建连接
连接数打满数据库
事务跨多个函数

补充说明：

在实际落地 Serverless 下的数据库连接管理时，建议结合 Serverless、数据库、连接池的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：函数无状态，连接不能长期保持、使用数据库代理等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

每个请求新建连接
连接数打满数据库
事务跨多个函数

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

函数无状态，连接不能长期保持；使用数据库代理；连接池在函数实例内复用；优先使用无服务器数据库；异常时优雅关闭连接。同时要避免每个请求新建连接。

FB-35-CO-A-012：什么是 Function as a Service 的触发器

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：FaaS、触发器、API Gateway、定时、事件 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请列举常见的 FaaS 触发器类型。

参考答案：

核心思路如下：

HTTP/API Gateway 触发
定时触发
对象存储事件
消息队列触发
数据库变更触发
CDN 日志触发

需要避免的典型误区：

触发器配置错误导致重复执行
忽略事件格式
未做幂等

补充说明：

在实际落地 Function as a Service 的触发器时，建议结合 FaaS、触发器、API Gateway 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：HTTP/API Gateway 触发、定时触发等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

触发器配置错误导致重复执行
忽略事件格式
未做幂等

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

HTTP/API Gateway 触发；定时触发；对象存储事件；消息队列触发；数据库变更触发；CDN 日志触发。同时要避免触发器配置错误导致重复执行。

FB-35-SC-A-005：Serverless 应用如何做本地开发

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、本地开发、模拟、调试、热更新 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Serverless 项目的本地开发体验优化。

参考答案：

核心思路如下：

使用 serverless-offline、miniflare、wrangler
Mock 平台服务：数据库、认证
统一环境变量配置
本地 HTTPS 和域名模拟
远程调用真实服务做集成测试

需要避免的典型误区：

完全依赖线上调试
本地与线上环境差异大
缺少 mock

补充说明：

在实际落地 Serverless 应用如何做本地开发时，建议结合 Serverless、本地开发、模拟的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：使用 serverless-offline、miniflare、wrangler、Mock 平台服务等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

完全依赖线上调试
本地与线上环境差异大
缺少 mock

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

使用 serverless-offline、miniflare、wrangler；Mock 平台服务；统一环境变量配置；本地 HTTPS 和域名模拟；远程调用真实服务做集成测试。同时要避免完全依赖线上调试。

FB-35-PE-A-003：边缘函数的缓存策略

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：边缘、缓存、TTL、Vary、失效 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明边缘函数如何设计缓存。

参考答案：

核心思路如下：

按 URL + header/cookie 生成缓存 key
设置合适的 Cache-Control 和 TTL
Vary 头控制缓存变体
主动清除或版本化缓存
缓存动态内容的渲染结果

需要避免的典型误区：

缓存用户私有数据
TTL 过长导致更新延迟
Vary 过多降低命中率

补充说明：

在实际落地边缘函数的缓存策略时，建议结合边缘、缓存、TTL 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：按 URL + header/cookie 生成缓存 key、设置合适的 Cache-Control 和 TTL 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

缓存用户私有数据
TTL 过长导致更新延迟
Vary 过多降低命中率

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

按 URL + header/cookie 生成缓存 key；设置合适的 Cache-Control 和 TTL；Vary 头控制缓存变体；主动清除或版本化缓存；缓存动态内容的渲染结果。同时要避免缓存用户私有数据。

FB-35-CO-P-010：什么是分布式跟踪在 Serverless 中的挑战

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、分布式跟踪、Trace、无状态、冷启动 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请说明在 Serverless 环境中实现 trace 的挑战。

参考答案：

核心思路如下：

函数无状态，trace 上下文需在调用间传递
冷启动影响 trace 初始化
平台服务之间 trace 需兼容
异步触发链路长
采样和成本控制

需要避免的典型误区：

忽略函数间 trace 传递
全量采样成本爆炸
不关联前端 trace

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：函数无状态，trace 上下文需在调用间传递、冷启动影响 trace 初始化等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

忽略函数间 trace 传递
全量采样成本爆炸
不关联前端 trace

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

函数无状态，trace 上下文需在调用间传递；冷启动影响 trace 初始化；平台服务之间 trace 需兼容；异步触发链路长；采样和成本控制。同时要避免忽略函数间 trace 传递。

FB-35-SC-R-001：设计一个 Serverless 实时数据处理前端展示

题型：场景设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：35 Serverless 与边缘计算标签：Serverless、实时、WebSocket、FaaS、数据流 出现频率：低频 预计回答时长：8-15 分钟

题目描述：请设计一个基于 Serverless 的实时数据展示系统。

参考答案：

核心思路如下：

数据源 -> FaaS 处理 -> 消息队列/WebSocket -> 前端
使用 Serverless WebSocket API 管理连接
函数处理数据转换和过滤
前端订阅并展示
降级：长轮询或 SSE

需要避免的典型误区：

用 FaaS 维持大量长连接
不处理函数超时
实时性要求过高忽略成本

补充说明：

在实际落地设计一个 Serverless 实时数据处理前端展示时，建议结合 Serverless、实时、WebSocket 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据源 -> FaaS 处理 -> 消息队列/WebSocket -> 前端、使用 Serverless WebSocket API 管理连接等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

用 FaaS 维持大量长连接
不处理函数超时
实时性要求过高忽略成本

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据源 -> FaaS 处理 -> 消息队列/WebSocket -> 前端；使用 Serverless WebSocket API 管理连接；函数处理数据转换和过滤；前端订阅并展示；降级。同时要避免用 FaaS 维持大量长连接。

FB-35-CO-A-013：Serverless 下的日志与可观测性

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、日志、监控、可观测、冷启动 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 Serverless 应用的日志和监控方案。

参考答案：

核心思路如下：

平台原生日志服务或转发到统一日志平台
结构化日志，包含 requestId
指标：调用次数、错误率、冷启动、耗时
分布式 trace 串联函数调用
告警：错误率、延迟、成本

需要避免的典型误区：

无结构化日志
不监控冷启动
日志保留过短

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：平台原生日志服务或转发到统一日志平台、结构化日志，包含 requestId 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

无结构化日志
不监控冷启动
日志保留过短

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

平台原生日志服务或转发到统一日志平台；结构化日志，包含 requestId；指标；分布式 trace 串联函数调用；告警。同时要避免无结构化日志。

FB-35-SC-A-006：Serverless 下的 CI/CD 流程

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、CI/CD、部署、回滚、基础设施 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计 Serverless 项目的持续交付流程。

参考答案：

核心思路如下：

基础设施即代码定义函数、触发器、权限
多环境：dev/test/prod
自动化测试后部署
版本别名和流量切换
回滚：切换别名到旧版本
预览环境：分支部署

需要避免的典型误区：

手动修改云控制台
无环境隔离
回滚复杂

补充说明：

在实际落地 Serverless 下的 CI/CD 流程时，建议结合 Serverless、CI/CD、部署的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：基础设施即代码定义函数、触发器、权限、多环境等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

手动修改云控制台
无环境隔离
回滚复杂

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

基础设施即代码定义函数、触发器、权限；多环境；自动化测试后部署；版本别名和流量切换；回滚；预览环境。同时要避免手动修改云控制台。

FB-35-CO-P-011：什么是 OCI 容器与 Serverless 容器

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：35 Serverless 与边缘计算标签：Serverless、容器、OCI、镜像、弹性 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请比较函数计算与 Serverless 容器。

参考答案：

核心思路如下：

函数计算：事件驱动、粒度细、受限运行时
Serverless 容器：可运行任意容器、适合既有应用
代表：AWS Lambda vs Fargate / Google Cloud Run
选择：新应用用函数，迁移应用用容器
两者计费模型不同

需要避免的典型误区：

所有应用都用函数
忽略容器启动时间
成本未对比

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：函数计算、Serverless 容器等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有应用都用函数
忽略容器启动时间
成本未对比

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

函数计算；Serverless 容器；代表；选择；两者计费模型不同。同时要避免所有应用都用函数。

FB-35-CO-B-013：什么是 FaaS

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：35 Serverless 与边缘计算标签：FaaS、函数计算、Serverless、事件驱动 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 FaaS 的概念和特点。

参考答案：

核心思路如下：

FaaS：函数即服务，开发者只写函数
事件驱动，按需执行
自动扩缩容
按调用次数和执行时间计费
代表：AWS Lambda、Vercel Functions

需要避免的典型误区：

FaaS 等同于 Serverless
用 FaaS 跑长任务
忽略冷启动

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：FaaS、事件驱动，按需执行等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

FaaS 等同于 Serverless
用 FaaS 跑长任务
忽略冷启动

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

FaaS；事件驱动，按需执行；自动扩缩容；按调用次数和执行时间计费；代表。同时要避免FaaS 等同于 Serverless。

FB-35-SC-A-007：Serverless 下前端部署流程

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：Serverless、部署、CI/CD、静态资源、函数 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明前端应用在 Serverless 平台的部署流程。

参考答案：

核心思路如下：

构建静态资源和函数
上传对象存储/CDN
部署边缘函数/FaaS
配置域名和路由
灰度和回滚

需要避免的典型误区：

函数与静态资源版本不一致
无环境隔离
忽略回滚

补充说明：

在实际落地 Serverless 下前端部署流程时，建议结合 Serverless、部署、CI/CD 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：构建静态资源和函数、上传对象存储/CDN 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

函数与静态资源版本不一致
无环境隔离
忽略回滚

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

构建静态资源和函数；上传对象存储/CDN；部署边缘函数/FaaS；配置域名和路由；灰度和回滚。同时要避免函数与静态资源版本不一致。

FB-35-CO-A-014：边缘函数的限制

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：35 Serverless 与边缘计算标签：边缘函数、限制、运行时、CPU、内存 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明边缘函数相比传统函数的限制。

参考答案：

核心思路如下：

执行时间短
CPU/内存受限
支持的 API 有限
无状态
部分不支持原生 Node 模块
调试较困难

需要避免的典型误区：

在边缘做重计算
依赖 Node 原生模块
需要持久化状态

补充说明：

在实际落地边缘函数的限制时，建议结合边缘函数、限制、运行时的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：执行时间短、CPU/内存受限等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

在边缘做重计算
依赖 Node 原生模块
需要持久化状态

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

执行时间短；CPU/内存受限；支持的 API 有限；无状态；部分不支持原生 Node 模块；调试较困难。同时要避免在边缘做重计算。

Serverless/Edge 面试题 ​

目录 ​

基础题（8 道） ​

FB-35-CO-B-001：什么是 Serverless/FaaS？它解决了什么问题？ ​

FB-35-CO-B-002：Edge Computing 与传统 CDN 有什么区别？ ​

FB-35-CO-B-003：Serverless 中的冷启动与热启动是什么？ ​

FB-35-CO-B-004：Serverless 中的事件驱动与触发器有哪些？ ​

FB-35-CO-B-005：Serverless 函数为什么要尽量无状态？ ​

FB-35-CO-B-006：Serverless 有哪些优势和劣势？ ​

FB-35-CO-B-007：Serverless 本地开发与调试有哪些方式？ ​

FB-35-CO-B-008：常见的 Serverless/Edge 平台有哪些？各有什么特点？ ​

进阶题（8 道） ​

FB-35-CO-A-001：什么是 SSR at Edge？它解决了什么问题？ ​

FB-35-CD-A-001：Edge 函数如何实现路由改写与 A/B 测试？ ​

FB-35-CO-A-002：边缘缓存策略如何设计？ ​

FB-35-SE-A-001：Serverless 安全与权限如何管理？ ​

FB-35-CO-A-003：Serverless 中的状态持久化有哪些方案？ ​

FB-35-PE-A-001：Serverless 冷启动如何优化？ ​

FB-35-CO-A-004：Serverless 成本模型与计费如何评估？ ​

FB-35-CO-A-005：Serverless 可观测性如何建设？ ​

深入题（7 道） ​

FB-35-CO-P-001：边缘函数与微服务边界如何划分？ ​

FB-35-CO-P-002：多区域部署与一致性如何权衡？ ​

FB-35-CO-P-003：Serverless 框架选型与部署如何决策？ ​

FB-35-SE-P-001：Edge 上的认证与授权如何设计？ ​

FB-35-CO-P-004：Serverless 中的隐私合规如何处理？ ​

FB-35-CO-P-005：函数编排与 workflow 在 Serverless 中如何实现？ ​

FB-35-CO-P-006：边缘 AI 推理有哪些应用场景与挑战？ ​

架构题（42 道） ​

FB-35-SD-R-001：如何设计一个 Serverless 前端架构？ ​

FB-35-SD-R-002：如何设计一个 Edge 网关？ ​

FB-35-SD-R-003：Serverless 与容器/传统服务器如何取舍？ ​

FB-35-SD-R-004：如何设计边缘与中心协同架构？ ​

FB-35-CP-R-001：组织级 Serverless 治理如何推进？ ​

FB-35-CP-R-002：Serverless 成本控制策略有哪些？ ​

FB-35-CP-R-003：全球化边缘渲染平台如何设计？ ​

FB-35-CO-B-009：什么是 Serverless？它的优缺点是什么？ ​

FB-35-SC-B-001：Edge 计算适合哪些前端场景？ ​

FB-35-CO-B-010：什么是冷启动？如何缓解？ ​

二、进阶题 ​

FB-35-CO-A-006：Serverless 架构下如何做好可观测性？ ​

FB-35-CO-A-007：如何避免 Serverless 供应商锁定？ ​

三、高级题 ​

FB-35-CO-B-011：什么是 Serverless，它解决了什么问题 ​

FB-35-CO-A-008：边缘计算与 Serverless 的关系 ​

FB-35-SC-A-001：前端如何使用边缘函数做 A/B 测试 ​

FB-35-CO-A-009：边缘函数的限制与最佳实践 ​

FB-35-SC-P-001：设计一个基于边缘的 SSR 渲染方案 ​

FB-35-CO-P-007：Serverless 冷启动与温启动 ​

FB-35-SC-A-002：前端 BFF 放在 Serverless 的考量 ​

FB-35-CO-A-010：什么是 Edge Side Includes ​

FB-35-SC-P-002：Serverless 下如何管理环境变量和密钥 ​

FB-35-SD-R-006：设计一个 Serverless 前端部署架构 ​

FB-35-CO-P-008：Serverless 的供应商锁定如何应对 ​

FB-35-SC-A-003：边缘函数如何做地理位置定向 ​

FB-35-CO-A-011：ISR 与 SSG 的区别 ​

FB-35-PE-A-002：Serverless 成本优化策略 ​

FB-35-SC-P-003：Serverless 函数的测试策略 ​

FB-35-CO-B-012：什么是 Jamstack ​

FB-35-SC-A-004：如何在 Serverless 中实现用户鉴权 ​

FB-35-CO-P-009：边缘渲染与中心 SSR 的取舍 ​

FB-35-SC-P-004：Serverless 下的数据库连接管理 ​

FB-35-CO-A-012：什么是 Function as a Service 的触发器 ​

FB-35-SC-A-005：Serverless 应用如何做本地开发 ​

FB-35-PE-A-003：边缘函数的缓存策略 ​

FB-35-CO-P-010：什么是分布式跟踪在 Serverless 中的挑战 ​

FB-35-SC-R-001：设计一个 Serverless 实时数据处理前端展示 ​

FB-35-CO-A-013：Serverless 下的日志与可观测性 ​

FB-35-SC-A-006：Serverless 下的 CI/CD 流程 ​

FB-35-CO-P-011：什么是 OCI 容器与 Serverless 容器 ​

FB-35-CO-B-013：什么是 FaaS ​

FB-35-SC-A-007：Serverless 下前端部署流程 ​

FB-35-CO-A-014：边缘函数的限制 ​

Serverless/Edge 面试题

目录

基础题（8 道）

FB-35-CO-B-001：什么是 Serverless/FaaS？它解决了什么问题？

FB-35-CO-B-002：Edge Computing 与传统 CDN 有什么区别？

FB-35-CO-B-003：Serverless 中的冷启动与热启动是什么？

FB-35-CO-B-004：Serverless 中的事件驱动与触发器有哪些？

FB-35-CO-B-005：Serverless 函数为什么要尽量无状态？

FB-35-CO-B-006：Serverless 有哪些优势和劣势？

FB-35-CO-B-007：Serverless 本地开发与调试有哪些方式？

FB-35-CO-B-008：常见的 Serverless/Edge 平台有哪些？各有什么特点？

进阶题（8 道）

FB-35-CO-A-001：什么是 SSR at Edge？它解决了什么问题？

FB-35-CD-A-001：Edge 函数如何实现路由改写与 A/B 测试？

FB-35-CO-A-002：边缘缓存策略如何设计？

FB-35-SE-A-001：Serverless 安全与权限如何管理？

FB-35-CO-A-003：Serverless 中的状态持久化有哪些方案？

FB-35-PE-A-001：Serverless 冷启动如何优化？

FB-35-CO-A-004：Serverless 成本模型与计费如何评估？

FB-35-CO-A-005：Serverless 可观测性如何建设？

深入题（7 道）

FB-35-CO-P-001：边缘函数与微服务边界如何划分？

FB-35-CO-P-002：多区域部署与一致性如何权衡？

FB-35-CO-P-003：Serverless 框架选型与部署如何决策？

FB-35-SE-P-001：Edge 上的认证与授权如何设计？

FB-35-CO-P-004：Serverless 中的隐私合规如何处理？

FB-35-CO-P-005：函数编排与 workflow 在 Serverless 中如何实现？

FB-35-CO-P-006：边缘 AI 推理有哪些应用场景与挑战？

架构题（42 道）

FB-35-SD-R-001：如何设计一个 Serverless 前端架构？

FB-35-SD-R-002：如何设计一个 Edge 网关？

FB-35-SD-R-003：Serverless 与容器/传统服务器如何取舍？

FB-35-SD-R-004：如何设计边缘与中心协同架构？

FB-35-CP-R-001：组织级 Serverless 治理如何推进？

FB-35-CP-R-002：Serverless 成本控制策略有哪些？

FB-35-CP-R-003：全球化边缘渲染平台如何设计？

FB-35-CO-B-009：什么是 Serverless？它的优缺点是什么？

FB-35-SC-B-001：Edge 计算适合哪些前端场景？

FB-35-CO-B-010：什么是冷启动？如何缓解？

二、进阶题

FB-35-CO-A-006：Serverless 架构下如何做好可观测性？

FB-35-CO-A-007：如何避免 Serverless 供应商锁定？

三、高级题

FB-35-CO-B-011：什么是 Serverless，它解决了什么问题

FB-35-CO-A-008：边缘计算与 Serverless 的关系

FB-35-SC-A-001：前端如何使用边缘函数做 A/B 测试

FB-35-CO-A-009：边缘函数的限制与最佳实践

FB-35-SC-P-001：设计一个基于边缘的 SSR 渲染方案

FB-35-CO-P-007：Serverless 冷启动与温启动

FB-35-SC-A-002：前端 BFF 放在 Serverless 的考量

FB-35-CO-A-010：什么是 Edge Side Includes

FB-35-SC-P-002：Serverless 下如何管理环境变量和密钥

FB-35-SD-R-006：设计一个 Serverless 前端部署架构

FB-35-CO-P-008：Serverless 的供应商锁定如何应对

FB-35-SC-A-003：边缘函数如何做地理位置定向

FB-35-CO-A-011：ISR 与 SSG 的区别

FB-35-PE-A-002：Serverless 成本优化策略

FB-35-SC-P-003：Serverless 函数的测试策略

FB-35-CO-B-012：什么是 Jamstack

FB-35-SC-A-004：如何在 Serverless 中实现用户鉴权

FB-35-CO-P-009：边缘渲染与中心 SSR 的取舍

FB-35-SC-P-004：Serverless 下的数据库连接管理

FB-35-CO-A-012：什么是 Function as a Service 的触发器

FB-35-SC-A-005：Serverless 应用如何做本地开发

FB-35-PE-A-003：边缘函数的缓存策略

FB-35-CO-P-010：什么是分布式跟踪在 Serverless 中的挑战

FB-35-SC-R-001：设计一个 Serverless 实时数据处理前端展示

FB-35-CO-A-013：Serverless 下的日志与可观测性

FB-35-SC-A-006：Serverless 下的 CI/CD 流程

FB-35-CO-P-011：什么是 OCI 容器与 Serverless 容器

FB-35-CO-B-013：什么是 FaaS

FB-35-SC-A-007：Serverless 下前端部署流程

FB-35-CO-A-014：边缘函数的限制