部署策略与 CDN

• 健康检查的类型（可用性探针 vs 合成监控）
• 回滚触发条件与判定
• 自动回滚的权衡与人工兜底

健康检查分两层：基础探针（HTTP 状态码、首页 200、静态资源可达、关键 API 响应）与合成监控（Synthetic Monitoring，模拟真实用户访问关键路径，校验关键元素、交互与性能指标，跨可观测平台如 Datadog/Sentry 探测）。自动回滚策略：部署后先跑冒烟测试/合成探针，若在设定的观察窗口内健康阈值被突破（如错误率上升、关键路径 500、核心指标退化），则自动触发回滚到上一稳定版本。需设计分级：自动回滚针对明确的严重故障，疑似问题用灰度/告警人工介入，避免误回滚。

核心是"可量化的健康信号 + 明确的回滚阈值 + 窗口期观察"。自动回滚能快速止血，但需设置合理的判定条件与人工兜底，配合版本化部署（不可变 URL）保证回滚即时生效。

• 两种 CI/CD 的配置方式
• 构建、测试、部署流水线
• 环境与缓存、缓存还原

GitHub Actions 与 GitLab CI 都是基于 YAML 配置的 CI/CD。GitHub Actions 用 .github/workflows/*.yml，通过 jobs/steps 定义流水线，支持矩阵构建、缓存（actions/cache）、分支与事件触发（push、PR、tag）。GitLab CI 用 .gitlab-ci.yml，通过 stages/jobs 定义，支持 runner 与规则。前端流水线通常包含：install（依赖）、lint、test、build（产出 hash 静态资源）、deploy（按环境部署并做 CDN 预热/失效）。两者都支持多环境（dev/staging/prod）与 review app。

两者能力相当，选型取决于代码托管平台。关键工程点是依赖缓存、构建可复现、部署产物不可变与环境隔离。

• 原子部署的概念
• Deployment ID 的作用
• 回滚流程

Cloudflare Pages 每次部署都会生成独立的 Deployment ID，并以不可变快照形式存储，新部署只有在构建成功后才切换为生产版本，因此部署是原子的（要么全上新，要么保持旧版，不会出现半成品）。回滚时只需把 Deployment ID 指向某个历史版本，即可瞬间恢复该版本在 CDN 生效，无需重新构建。由于资源带 hash 且版本不可变，回滚不会产生"新 HTML 引旧资源"的错配。

原子部署 + 不可变版本（Deployment ID）是回滚安全的基础：版本不覆盖、可随时回退、即时生效，是现代化托管平台的核心能力。

• subtree 与 submodule 的机制差异
• 多仓协作与依赖管理
• 构建与部署的取舍

git-submodule 在父仓库中记录子仓库的提交引用，子仓库保持独立仓库，克隆时需 --recursive 拉取子模块，子模块更新需在父仓库提交新引用；git-subtree 把子仓库代码"分离"进父仓库目录，版本历史合并进父仓库，子仓库可向后推送。工程取舍：submodule 适合"子模块独立演进、多仓贡献"，但 clone 复杂、易出现引用不一致；subtree 适合"只需在父仓库内管理代码、部署简单"，但历史会有重复、双向同步较繁琐。前端多仓场景，若需共享组件库并独立发布，submodule 或更推荐 npm 包；若需整合部署，subtree 更轻。

核心权衡是"独立性 vs 集成简便"。现代前端更多用包管理器（npm workspace）替代 submodule/subtree，但多仓协作时二者仍是可选方案。

• review app 的按 PR 动态生成
• 测试与协作
• 与环境隔离

按 {pr-N}.preview.example.com 的形式为每个 PR 生成独立预览环境，让开发者在合并前即可在真实托管环境（含 CDN、边缘函数、环境变量）查看该 PR 的效果。工程价值：无头端到端可测试、设计师/PM/QA 可共享预览链接反馈、多 PR 并行不互相干扰、可结合 CI 在预览环境跑集成测试。平台（Vercel/Netlify/Cloudflare）可通过 webhook 自动构建并生成唯一子域名，PR 关闭即销毁。

它是"左移测试"的关键实践，把验证从"合并后"提前到"PR 阶段"，降低回归风险，提升协作效率与部署信心。

• S3 对象版本管理的启用
• 历史回溯与版本回滚
• 生命周期清理策略

启用 S3 的版本管理（Versioning）后，每次覆盖同一对象都会保留一个版本 ID，可针对历史版本做回溯与回滚（删除当前版本标记即恢复旧版本）。前端可把"当前版本"与"历史版本"保留，配合 index.html 引用 hash 资源，发布新版本时只新增对象、不覆盖，回滚时切换 index.html 指向旧版本即可。但这会积累大量版本，需用生命周期策略（Lifecycle Policy）清理：如非当前版本保留 N 天或 N 个版本后自动转档/删除，设置过期规则控制成本。

版本管理提供"可回滚的不可变历史"，但需用生命周期策略控制存储成本与堆积。核心是区分"当前版本（保留）"与"历史版本（按策略清理）"。

• 旧 HTML 引新资源 / 新 HTML 引已删旧资源
• 资源多版本共存策略
• HTML 不缓存或短缓存

灰度发布时，若资源与 HTML 分开发布且旧资源被立即删除，会出现两类问题：旧 HTML 被用户缓存或延迟加载，引用新版本资源导致 404/白屏；或新 HTML 引用已被删除的旧资源导致 404。对策：一是资源多版本共存，发布时不删除旧资源（带 hash 的 JS/CSS 保留一段时间），让新旧 HTML 都能找到对应资源；二是 HTML 不缓存（Cache-Control: no-cache）或设置极短 TTL，让用户尽快拿到最新 HTML，避免旧 HTML 长期引用已删资源。灰度期保证所有版本资源在窗口内共存。

核心是"资源与 HTML 的发布节奏解耦要安全"。用 hash 资源不可变 + 多版本共存 + HTML 不缓存，从根上避免错配导致的 404/白屏。

• Docker 镜像的可移植性
• nginx:alpine 的轻量与静态托管
• 多阶段构建与一致性

在传统 VM 上，用 Docker 部署前端静态站：通过多阶段构建（先 node 构建，再拷贝产物到 nginx:alpine 镜像）可得到只有 nginx + 静态文件的极轻镜像，体积小、启动快、攻击面小。工程价值：镜像即产物，保证 VM 到 VM 环境一致，避免"本机行、服务器不行"；nginx 负责静态文件服务、gzip、缓存头、SPA fallback 与反向代理；容器化便于版本管理、滚动更新与回滚，与编排（如 docker compose）配合管理多服务。

核心价值是"一致性与极简"。多阶段构建把构建环境与运行环境解耦，nginx:alpine 提供高性能静态托管且镜像极小，是传统 VM 上可靠的前端部署方式。

• 国内边缘 CDN 与边缘计算的合规
• ESA/EdgeOne 的能力与差异
• 多区域加速与安全

在国内部署，CDN 与边缘计算需满足 ICP 备案、合规与内容安全要求。阿里云 ESA（边缘安全加速）与腾讯云 EdgeOne（边缘安全加速平台）都是集 CDN、边缘计算、DDoS/WAF 防护于一体的一体化平台，提供就近的静态资源加速、边缘函数（SSR/动态请求）、HTTPS 与安全防护。工程价值：国内节点覆盖与合规、低延迟加速、以及边缘函数让动态内容也靠近用户。二者差别在生态与 API，选型依赖团队已用云厂商。

国内边缘托管的重点是"合规 + 就近 + 安全"。ESA/EdgeOne 把 CDN、边缘计算与安全整合，适合需要国内低延迟与合规的站点。

• Pages 与 Workers 的互补
• Functions 与 Workers 的关系
• 全栈部署

Cloudflare Pages 面向静态站点与全栈应用，其 Functions 本质上是基于 Workers 的技术，可在 Pages 项目中编写服务端函数（处理 API、SSR、中间件），随 Pages 一起部署。此外 Page 项目也可通过 _worker.js 或绑定已有 Worker 复用能力，并可通过 wrangler pages 命令将 Pages 项目与 Workers 关联、共享边缘运行时（KV、D1、R2、Durable Objects）。集成价值在于：静态资源 + 边缘函数 + 数据存储一体化，一套代码同时覆盖静态托管与动态后端。

集成让"静态站点 + 边缘 API"统一部署，避免分开管理。Functions/Worker 共享边缘能力，是 Pages 从前端静态托管升级为全栈平台的关键。

• Netlify 自动构建与部署
• Edge Functions 的 Deno 运行时
• Netlify Forms 的表单处理

Netlify 提供持续部署：连接 Git 仓库后，push 到分支自动触发构建部署，支持 PR 预览环境、部署预览与回滚，通过 Netlify Functions 提供无服务器后端。Netlify Edge Functions 基于 Deno 运行时，可在边缘节点执行请求改写、鉴权、A/B 或地理路由，延迟低。Netlify Forms 是零后端表单方案：在 HTML 中声明表单属性即可接收表单提交，数据存到 Netlify 后台并支持通知与验证，无需自建表单服务。三者结合，前端可快速获得"构建部署 + 边缘逻辑 + 表单收件"的全栈能力。

Netlify 的价值是把"部署、边缘函数、表单/函数"整合进一体化的前端平台，降低后端运维成本，适合 Jamstack 与现代前端站点。

• 零配置部署与框架自动识别
• Edge Network 的全球边缘缓存
• 预览部署与回滚

Vercel 提供零配置部署：连接 Git 仓库后自动识别框架（Next、Nuxt、Vite 等）并生成对应构建配置，无需手写部署脚本，push 即部署。Edge Network 是 Vercel 的全球边缘网络，负责静态资源缓存、SSR 渲染与边缘函数执行，让内容靠近用户。预览部署为每个 PR 生成独立 URL，可测试与回滚，生产部署不可变、可一键回滚。三者结合提供"命令行式的一体化部署体验"，尤其与 Next.js 深度集成。

Vercel 的价值在"零配置 + 全球边缘 + 预览/回滚"的强一体化体验，降低部署开销，但需注意平台绑定（尤其是 Next.js 深度特性）。

• WebTransport 与传统 HTTP/WebSocket 的差异
• 低延迟实时通信
• 适用场景与约束

WebTransport 是基于 HTTP/3（QUIC）的新型传输协议，支持单向/双向流与数据报，具备低延迟、乱序传输、多路复用与连接迁移能力，相比 WebSocket 延迟更低、更灵活。在大型前端项目中的工程价值：游戏、实时协作、直播、大规模数据同步等场景需要更低延迟与更高吞吐；数据报（datagram）适合不需要可靠性的高频数据，流（stream）适合可靠的大数据。但 WebTransport 依赖 HTTP/3 与服务器支持，浏览器兼容与部署复杂度是主要约束。

价值在于"低延迟 + 多路复用 + 基于 QUIC 的灵活传输"。适合对延迟敏感、通信频繁的实时应用；常规请求仍用 HTTP，不必滥用。

• 预览环境与 PR 关联
• 协作与测试
• 与 CI 集成

Preview Deployments 为每个 PR 或分支生成可访问的独立部署 URL，团队成员、设计师、QA 与利益相关者可通过链接直接在真实环境查看该 PR 的界面与交互，无需本地运行。工程价值：加速代码评审（评审人可实际体验）、支持 UI 走查与功能测试、多 PR 并行隔离互不干扰、可与 CI 集成跑端到端测试、PR 关闭后自动清理。平台如 Vercel/Netlify/Cloudflare 均支持，通常提供子域名形式的预览 URL。

预览环境把"验证"从合并后提前到 PR 阶段，是协作与质量保障的关键左移实践，提升合并信心与交付速度。

• 蓝绿部署的双环境切换
• 灰度/金丝雀的逐步流量
• 平台的原生支持

蓝绿部署维护两套环境（蓝/绿），新版本部署到非活跃环境，验证通过后切换流量，切换可快速回滚；灰度/金丝雀发布让新版本逐步接收流量（如 5%→50%→100%），观察指标后再放量，失败可快速回退。Vercel/Netlify 等平台通过"不可变部署 + 即时切换 + 回滚"支持近似蓝绿，并提供预览/AB 试验（如 Vercel Edge Config、Netlify 的分支部署）实现灰度与金丝雀。静态前端因资源 hash 化，新老版本可共存，切换与回滚都很快。

现代平台把"部署不可变 + 切换即时 + 回滚即时"作为基础，蓝绿/灰度/金丝雀是不同力度的流量控制策略，按风险与验证需求选择。

• Cookie/Header 作为灰度分流依据
• 版本回滚与分流一致性
• 与 CDN 缓存键的配合

基于 Cookie/Header 的灰度：通过用户携带的 Cookie（如 variant=experimental）或请求头（如 X-Canary）在边缘函数/中间件中判定用户属于哪个版本，并据此返回对应页面或路由到对应版本。Cookie 适合"用户级别"的稳定分流（同一用户保持一致），Header 适合"请求级别"或测试工具注入。回滚时只需把分流逻辑切回全量旧版本，或修改 Cookie 值。关键是要把 Cookie/Header 纳入 CDN 缓存键（Vary），否则不同版本的 HTML 会被缓存混淆。

核心是"按用户信号分流 + 缓存键一致 + 快速切换回滚"。Cookie 提供黏性，Header 提供灵活性，Vary 保证缓存不串版本。

• 蓝绿部署的整组切换
• 金丝雀的逐步放量
• 风险与回滚粒度

蓝绿部署维护两套完整环境（蓝、绿），新版本整体部署到非活跃环境，验证后一次性切换流量，切换快、回滚快（切回旧环境），但需要双倍资源；金丝雀发布让新版本逐步接收流量（5%→…→100%），可观察真实用户指标，风险更小、可精确控制放量比例，回滚只需把流量切回旧版本，但放量过程较慢、需监控设施。适用：蓝绿适合"变更大、可整体验证"；金丝雀适合"变更影响面广、需渐进验证"的高风险场景。

本质是"切换粒度"：蓝绿是 0/1 整组切换，金丝雀是 0→100 渐进流量。选择取决于变更风险、资源成本与验证能力。

• OAC 与 OAI 的区别
• 限制源站只允许 CloudFront 访问
• 安全签名原理

Origin Access Control（OAC）是 CloudFront 用于安全限制源站访问的机制，替代旧的 Origin Access Identity（OAI）。OAC 通过让 CloudFront 使用 IAM 签名请求（SigV4）访问源站（如 S3），源站配合 bucket policy 只允许来自特定 OAC 的请求，从而禁止外部直接访问 S3 对象，保证资源只能通过 CDN 分发。相比 OAI，OAC 支持更多请求（如 POST、PUT）与更细的 IAM 权限控制，是当前推荐方案。

OAC 的核心是"认证 + 授权"的源站保护：CloudFront 以 IAM 身份签名访问，S3 策略只放行该身份，从而隔离源站直连与绕过 CDN。

• S3 + CloudFront 的架构
• OAC 与 OAI 的差异
• 企业级的最佳实践

企业级前端部署常用 S3 存静态资源 + CloudFront 作 CDN 分发：S3 提供可靠的存储与版本管理，CloudFront 提供全球边缘缓存、HTTPS、缓存与 WAF 防护。为安全，应优先使用 OAC（Origin Access Control）：它用 IAM SIGv4 签名限制只有 CloudFront 能访问 S3，支持更细权限与更多请求类型；OAI 是旧方案，仅用公开身份访问 S3，权限粒度粗且不支持 PUT 等。企业级还搭配：hash 资源长缓存、index.html no-cache、S3 生命周期清理、CloudFront 缓存失效与版本回滚。

核心是"S3 可靠存储 + CloudFront 边缘分发 + OAC 安全隔离"。OAC 是安全与功能上的演进，OAI 保留兼容旧系统。

• 两者定位与能力的差异
• WAF 与安全防护
• 成本与定制化

Akamai 是老牌企业级 CDN，节点覆盖广、定制化与 SLA 强、适合大型企业复杂流量与合规需求，但配置复杂、成本高；Cloudflare 是综合性 CDN + 安全平台，内置 WAF、DDoS 防护、边缘计算与零配置体验，性价比高、上手快，但深度定制与特定企业合规能力可能不如 Akamai。取舍上：需要极致覆盖、定制与严格 SLA 的企业选 Akamai；需要一体化、快速部署与成本优化的选 Cloudflare。两者都具备 WAF 与 DDoS 防护。

本质是"重量级定制 vs 一体化便捷"。工程上评估节点覆盖、WAF 规则、合规、成本与团队运维能力，而非只看价格。

• 多区域 CDN 缓存与回源
• 缓存一致性（TTL、失效、版本化）
• 边缘与源站的同步

多区域部署用 CDN 在多 PoP 缓存，回源到源站（或就近源站）。缓存一致性主要靠：版本化 URL（hash 资源）使不可变资源天然一致，无需失效；可变内容（HTML/API）用合理 TTL 与按需失效（cache purge、云厂商的缓存失效 API）保证更新；SAR（stale-while-revalidate）允许旧值兜底、后台刷新。边缘与源站间存在最终一致窗口，因此对必须实时一致的内容（如交易、登录态）应避免边缘缓存或用强一致存储（如 DO、数据库），并注意跨区域回源延迟。

一致性是"强一致 vs 最终一致"的取舍。静态 hash 资源零成本一致，动态内容用 TTL + 失效 + 版本控制，关键业务走强一致源站。

• GitHub Pages 的定位
• 部署方式与限制
• 适用场景

GitHub Pages 是 GitHub 提供的免费静态站点托管，可从仓库的特定分支（如 main）或目录部署，通常用于项目文档、个人博客、开源项目主页等静态站点，支持自定义域名与 HTTPS。它通过 GitHub Actions 或自动构建部署，适合纯静态（无数据库、无服务端逻辑）的站点。限制：仅静态内容、无后端函数、带宽与构建限制、不适合复杂应用。对简单静态站与文档，它是零成本、零运维的选择。

价值是"零成本、零运维、与仓库集成"。但仅限静态，动态功能需诉诸其他平台，适合内容型与文档型站点。

• Edge Config / Workers 的 A/B 分流
• 实验配置的即时更新
• 分流一致性与缓存

A/B Testing 需在边缘把用户分流到不同版本并记录结果。Vercel Edge Config 提供全球分布、可即时更新的键值配置，配合 Edge Middleware 在请求边缘读取实验配置、按规则分流，配置更新无需重新部署即可生效；Cloudflare Workers 可在边缘请求中根据 Cookie/Header/随机数分流到不同版本，并配合 KV 或边缘配置存储实验参数。工程价值：分流在边缘、延迟低、配置热更新、无需发版即可调整实验比例，且不影响现有缓存。

边缘 A/B 的价值是"低延迟分流 + 配置热更新 + 版本隔离"。需保证分流黏性（同一用户稳定）与缓存键正确，避免实验组串扰。

• Feature Flag 的作用
• 主流平台的差异
• 灰度、回滚与实验

Feature Flag（功能开关）让你在不重新部署的情况下开启/关闭功能，支持渐进发布、灰度、即时回滚与安全发布。LaunchDarkly 是专业的企业级平台，提供细粒度目标、实时更新与审计；Unleash 是开源方案，可自托管、灵活且成本可控；PostHog 侧重产品分析，也提供 feature flags 与实验结合。工程价值：降低发布风险、支持按用户/环境/百分比灰度、快速关停出问题的功能、与 A/B 实验结合。使用需注意 Flags 的清理（避免技术债）与客户端 SDK 的实时性。

核心价值是"发布与代码解耦"。用 Feature Flag 可实现"代码已上线但功能未激活"，配合灰度与检测，安全可控地发布。

• DNS 解析对首屏的影响
• CDN/源站连接复用（TCP/TLS 复用）
• 预热（pre-warm）手段

首屏包含 DNS 解析、TCP/TLS 连接、请求与渲染。DNS 解析若慢会延缓首字节；CDN 通过就近节点与连接复用（长连接、快 TLS）减少建立连接开销。预热（pre-warm）指部署新版本后主动请求关键资源/URL，让 CDN 提前缓存、源站提前就绪，避免上线后首批用户回源或遭遇缓存冷启动。手段：部署后脚本批量请求 URL、CDN 预热 API、预加载 dns-prefetch/preconnect/preload 关键资源、边缘函数预热。预热能显著降低上线后的 TTFB 与 404。

首屏是"网络+缓存"的叠加。预热把"冷"变"热"，配合 DNS 优化与连接复用，让新版本上线即快。上线后首个小时的缓存命中率与 TTFB 是预热效果的衡量指标。

• 原子部署的定义
• 版本不可变与即时切换
• 回滚与发布一致性

原子部署指新版本的文件作为一个整体一次性发布，要么全部生效、要么保持旧版，避免"部分文件更新"导致的中间状态。Netlify、Vercel 的实现是：每次部署生成不可变的版本快照，新版本构建完成后才切换为生产版本，整个目录以新版本形式原子替换；由于资源带 hash 且版本不可变，切换瞬间所有文件一致，不存在"新 HTML 引旧资源"的错配。回滚即切换回某个历史不可变版本，即时生效。

原子部署的核心是"不可变版本 + 整体切换"。这让部署与回滚都安全且即时，是现代托管平台避免半成品发布的关键机制。

• 版本化回滚与历史保留
• 缓存一致性
• 回滚的自动化

前端 CDN 部署的回滚实践：部署采用不可变版本（带 hash 的静态资源 + 版本化 HTML），回滚时把 index.html/路由切回历史版本即可，无需重新构建；保留多版本历史（如 S3 版本管理、平台历史部署）以便快速回退。回滚需处理缓存一致性：静态资源 hash 化天然免疫回滚（新旧资源并存），HTML 用 no-cache 保证回滚即时生效；若用 purge 失效，需注意 purge 延迟。工程上可自动化回滚（健康检查触发 + CDN 切换 API），并配合监控确认回滚后恢复正常。

现代回滚依赖"不可变版本 + 即时切换 + 缓存安全"。核心是让回滚快、安全、可验证，避免缓存导致旧版本迟迟不生效。

• On-Demand Revalidation 的机制
• revalidatePath/revalidateTag
• 与 CMS/事件驱动的结合

On-Demand Revalidation 让 Next.js 在事件发生后（而非按固定时间）重新验证缓存页面。通过 revalidatePath(path) 失效某个路径，或 revalidateTag(tag) 失效打了该标签的缓存数据，常用于 CMS 发布、数据库写入、webhook 触发时立即刷新页面。Next.js 15 还支持 revalidatePath 在 Server Action 或 Route Handler 中调用，配合 ISR 实现"静态页 + 事件驱动刷新"。现代应用把它与无头 CMS 深度集成：内容更新即触发 tag 失效，页面即时更新，而平时保持静态缓存。

价值是"按需精确失效"，比时间 revalidate 更及时、更精确。它把"何时更新"从固定周期改为事件驱动，兼顾性能与新鲜度。

• Pages 的边缘部署能力
• Functions 与边缘运行时
• 边界与限制

Cloudflare Pages 部署静态站点，并通过 Functions 在边缘执行服务端逻辑（API、SSR、中间件），运行在 Cloudflare 的全球边缘网络，提供低延迟。工程实践：静态资源 + Functions 一体部署、配合 KV/D1/R2 存储、通过 wrangler 管理、支持 PR 预览与回滚。现代边界：Functions 基于 Workers 运行时，受边缘约束（无完整 Node I/O、内存/CPU 限制、冷启动），不适合重计算或长任务；复杂后端或需要特定 Node 库的应用可能需用 Durable Objects 或传统 Node 服务兜底。

价值是"静态 + 边缘函数一体化"；边界是"边缘运行时约束"。评估应用是否能在受限运行时内工作，决定是否适合 Pages。

• Edge Network 的全球边缘缓存
• 边缘 SSR 与流式
• 缓存与性能

Vercel Edge Network 是分布全球的 CDN 与边缘运行时，负责静态资源缓存、SSR 渲染与边缘函数执行。工程价值：静态资源与可缓存页面在边缘命中，降低延迟；对 SSR 页面，Edge Network 可缓存整页 HTML（配合 ISR/增量），未命中时在边缘或就近执行 SSR 并流式返回，显著降低 TTFB。它让"全球用户就近访问 + 动态内容边缘渲染"结合，同时支持按需 revalidate 与缓存失效。对 Next.js 深度集成，是 Vercel 的核心性能优势。

价值是"全球边缘缓存 + 边缘 SSR + 流式 + 增量缓存"的一体化。适合需要全球低延迟与动态内容的站点，但绑定 Vercel 平台。

• Netlify Edge Functions 的 Deno 运行时
• 边缘请求处理能力
• 与 Netlify 平台集成

Netlify Edge Functions 运行在 Deno 运行时上，部署在 Netlify 的边缘网络，可在请求到达时执行改写、鉴权、重定向、A/B 分流、地理路由等逻辑。它使用 Deno 的 API（请求/响应、fetch），与 Netlify Functions（Node 无服务器）互补：Edge Functions 面向边缘轻量逻辑、低延迟，Functions 面向 Node 生态的重任务。工程上通过 netlify.toml 或 config 配置路径与函数，可结合环境变量、KV 与地理信息实现个性化与实验。

Deno 运行时提供了安全、轻量的边缘执行环境。价值在"边缘低延迟逻辑 + 与平台部署集成"，适合鉴权、分流、改写等边缘场景。

• 工作流与触发事件
• 缓存与构建优化
• 多环境部署与矩阵

GitHub Actions 是 GitHub 内置的 CI/CD，通过 .github/workflows/*.yml 定义工作流。前端工程实践：用 npm ci 保证可复现、actions/cache 缓存 node_modules 与构建产物加速、actions/setup-node 指定 Node 版本、矩阵（matrix）并行跑多 Node/浏览器组合做 lint/test/build；按事件（push、PR、tag）触发，PR 中跑完整校验并部署预览，tag 触发生产部署。现代应用还结合缓存恢复、sha 作为镜像 tag、环境变量注入与 OIDC 免密钥部署。

核心是"可复现、可缓存、可并行、环境隔离"。GitHub Actions 把构建、测试、部署收敛到代码仓库，提升前端交付自动化。

• 多阶段构建的概念
• 分离构建与运行环境
• 镜像瘦身与安全

Docker 多阶段构建用多个 FROM 阶段：builder 阶段安装 Node 依赖并构建产物，runner 阶段（如 nginx:alpine）只拷贝最终产物运行，从而丢弃构建工具、依赖与源码，得到极小的运行镜像。工程价值：镜像体积小（传输/存储快、拉取快）、攻击面小（无 node_modules、无源码）、启动快、环境一致。常配合 .dockerignore 排除 node_modules 等，进一步瘦身。

多阶段构建的本质是"构建产物与构建环境分离"。把编译期与运行期依赖解耦，得到最小可运行镜像，是前端容器化的标准实践。

• Edge Middleware 的定位
• Edge Functions 的定位
• 执行时机与适用场景

Vercel Edge Middleware 运行在路由层，在请求进入页面/SSR 之前执行，用于请求改写、重定向、鉴权、A/B 分流、设置响应头等"轻量前置逻辑"，可提前返回或放行；Edge Functions 是更通用的边缘函数，可处理 API 请求、SSR、数据逻辑，能力更强。差异：Middleware 专为"路由前的请求拦截/改写"设计、执行早、可访问 NextRequest；Edge Functions 是独立函数、可做完整逻辑。工程上 Middleware 用于全局前置（鉴权、分流），Edge Functions 用于具体端点/页面逻辑。

本质是"执行时机与职责"：Middleware 是路由层拦截器，Edge Functions 是通用边缘执行单元。按"前置拦截"与"具体逻辑"选择。

• SPA 的 history 路由与服务器 fallback
• Nginx try_files 的语义
• 静态资源与 API 的区分

SPA 使用 history 路由时，刷新深层路径（如 /user/123）会请求服务器，若服务器无对应文件会 404。Nginx 用 try_files 实现 fallback：try_files $uri $uri/ /index.html; 表示先尝试匹配真实文件，找不到则回退到 index.html，由前端路由接管。工程上需把静态资源（带 hash 的 js/css）与 API 代理区分开：资源目录直接服务，API 反向代理到后端，避免把 API 也 fallback 到 index.html。

核心是"真实文件优先、找不到回退 index.html"。正确配置让 SPA 深链刷新可用，同时不破坏静态资源与 API 的访问。

• .dockerignore 的作用
• 构建期 vs 运行期配置注入
• envsubst 模板替换

.dockerignore 排除不需要进镜像 build context 的文件（node_modules、.git、dist 等），加快构建、减小上下文、避免 sensitive 文件打包。运行时配置：前端配置常需在构建后注入（同一镜像用于 dev/staging/prod），可用 envsubst 在容器启动时把环境变量替换进 JS 模板（如 config.js.template），从而无需为每个环境重新构建镜像。这样"构建一次、运行多环境"，保持镜像不可变。

.dockerignore 优化构建上下文，envsubst 实现"构建与配置解耦"。运行时注入让同一镜像适配多环境，是容器化配置的标准做法。

• Nginx 镜像的多阶段构建
• 去除构建工具与依赖
• 配置与扩展的优化

Nginx 前端镜像的多阶段构建：先用 node 镜像构建前端产物，再用 nginx:alpine 作为运行镜像只拷贝产物与最小 nginx 配置，去掉 node_modules、源码与构建工具，得到小体积镜像。瘦身手段还包括：用 alpine 基镜像、精简 nginx 配置、移除多余模块、--squash 或 --no-install-recommends 减少层。工程上配合 .dockerignore 与只拷贝必要文件，进一步减小体积、降低攻击面与启动时间。

核心是"构建与运行分离 + 最小基镜像 + 最小文件集"。Nginx 镜像只负责静态托管，体积小、安全、启动快。

• content-hash 文件名的作用
• immutable 指令的语义
• 长期缓存与更新

content-hash 让文件名随内容变化（如 app.a1b2c3.js），内容不变则 hash 不变，因此可安全地设置长缓存。Cache-Control: immutable 告诉浏览器"该资源在生命周期内不变，不要重新验证"，配合 max-age=31536000 实现长期缓存，避免每次刷新都发请求。当内容更新时 hash 变化，浏览器请求新 URL 才拿到新资源，旧资源可继续被旧页面引用。工程价值：静态资源命中率高、回源少、加载快；HTML 则用 no-cache 保证及时拿到新版本。

核心是"hash 作为内容指纹 + immutable 免验证"。长缓存 + 版本化 URL 让静态资源既快又安全，是前端性能优化的基石。

• HTML 用 no-cache 的原因
• hash 资源用 immutable 的原因
• 差异化缓存头设计

HTML 是最常变的入口，若 HTML 被长缓存，用户将长期看不到新版本。因此 HTML 用 Cache-Control: no-cache（每次请求都验证，但 304 时仍可用缓存体），保证尽快拿到最新 HTML 从而引用最新资源。带 hash 的静态资源内容不变则 URL 不变，可用 Cache-Control: public, max-age=31536000, immutable 长期缓存，永不重新验证。这样"HTML 常新、资源常驻"，两者配合实现安全快速的更新与缓存。

差异化设计的核心是"按变化频率分配缓存策略"：高频变化的 HTML 短缓存/验证，低频稳定的 hash 资源长缓存。这是前端缓存头设计的黄金法则。

• purge 的即时生效与成本
• 版本化 URL 的命中率优化
• 取舍与场景

CDN purge（缓存失效）能立即让指定 URL 失效并重新回源，适合需要"更新即生效"的动态内容，但 purge 有延迟（全局传播）、有成本（每次 purge 都增加回源）、且可能造成缓存命中率短暂下降。版本化 URL（hash 资源）让新内容用新 URL，旧 URL 继续缓存，天然高命中率、无需 purge，但"新版本"需要引导客户端访问新 URL（靠 HTML 更新）。取舍：静态资源用版本化 URL（高命中、可长缓存），HTML/动态内容用 short TTL 或按需 purge（即时生效）。两者结合兼顾即时与命中率。

本质是"更新即时性 vs 缓存命中率"的权衡。版本化 URL 对不可变资源最优，purge 对必须即时更新的内容必要。按内容类型选择。

• 版本化 URL 的回滚免疫
• purge 延迟的风险
• 回滚时缓存一致性策略

回滚时，若用版本化 URL（hash 资源），新旧版本资源并存，回滚只是切回旧 HTML（引用旧 hash 资源），旧资源仍可被缓存命中，天然免疫回滚，无需 purge。若用非版本化 URL（如覆盖同一路径），回滚后 CDN 边缘可能仍缓存旧内容，需 purge 失效，但 purge 有全局传播延迟，期间用户可能拿到混合/旧内容，造成不一致。工程风险：purge 延迟窗口内新旧内容混杂。对策：优先版本化 URL；对必须 purge 的场景，用带版本号的路径或短 TTL，并接受短暂的不一致窗口。

核心是"回滚及时性 vs 缓存一致性"。版本化 URL 让回滚即时且一致，purge 依赖传播延迟存在风险。设计上应尽量让回滚不依赖 purge。

• 多页/微前端的发布顺序依赖
• 资源与 HTML 的版本协调
• 原子部署保障

多页应用或微前端中，多个 HTML 页面/子应用可能引用共享或独立的 hash 资源。若发布顺序不当，可能出现"新 HTML 引用尚未发布的资源"或"发布后的资源被旧 HTML 引用（已删）"导致 404/白屏。保障手段：一是资源多版本共存，发布时保留旧资源，让新旧 HTML 都能找到对应资源；二是原子部署，把 HTML 与资源作为同一不可变版本整体发布，切换瞬间整组一致；三是微前端注意共享 chunk 的版本协调与发布顺序（先发布共享资源，再发布引用页面）。关键是不删除旧资源、降低耦合。

核心是"HTML 与资源的发布一致性"。原子部署 + 多版本共存 + 有序发布，避免多页/微前端下引用错配。

• 多级缓存的层级
• TTL 阶梯设计
• SWR 的应用

CDN 常用多级缓存：边缘缓存（靠近用户）、中间缓存（回源路径上的节点）、源站。TTL 阶梯设计让各级 TTL 由近到远递减或递增，边缘 TTL 短（更接近源更新）、中间/源站 TTL 长，以吸收回源压力并控制新鲜度。stale-while-revalidate（SWR）允许缓存过期时先返回旧值（stale），同时后台重新验证更新，用户无感、源站压力可控。工程应用：HTML 用 SWR + 短 TTL，静态资源用长 TTL + immutable，动态内容极小 TTL 或 no-store；多级缓存配合 SWR 实现"旧值兜底 + 后台刷新"。

核心是"分层缓存 + 过期策略"。TTL 阶梯平衡各级命中与新鲜度，SWR 缓解过期瞬间的源站压力，两者结合提升性能与稳定性。

• SW precache 与 HTTP 缓存的层次
• 版本化与更新时机
• 两者协调与冲突

Service Worker 位于浏览器与网络之间，优先于 HTTP 缓存：请求先经过 SW，SW 的预缓存（precache）在 install 时缓存带版本 hash 的资源，运行时优先从 SW 缓存响应，HTTP 缓存只在 SW 未拦截或未命中时生效。冲突点：SW 预缓存可能使 HTTP 的长缓存失效（因为 SW 优先），且 SW 更新需手动控制（activate 后清理旧缓存）。协调策略：SW 预缓存与 HTTP 缓存都基于版本化 hash（precache manifest 版本号），新版本发布后 SW 检测到 manifest 变化更新并清理旧缓存；对运行时请求策略（如 network-first 用于 HTML、cache-first 用于 hash 资源）区分。避免重复缓存与版本不匹配。

核心是"SW 优先于 HTTP 缓存，需用版本化 manifest 协调两者"。让 SW 与 HTTP 缓存指向同一版本，配合更新与清理，避免冲突与陈旧。

• CircleCI 的配置与 orbs
• 测试与部署流程
• 与自托管/云端的取舍

CircleCI 通过 .circleci/config.yml 定义流水线，用 jobs/workflows 组织构建、测试、部署。前端实践：用 circleci/node orb 缓存依赖、跑 lint/test/build，按分支与标签触发不同 workflow，部署到对应环境。取舍：CircleCI 云端托管简单、无需维护 runner，但需网络与成本；可自托管 runner 满足私有网络与合规，但需运维。相比 GitHub Actions，CircleCI 在 workflow 复杂编排与缓存配置上更成熟，但需单独维护账号与配置。

取舍核心是"托管 vs 自托管、生态 vs 成本"。CircleCI 适合需要复杂 workflow 编排与已有 CircleCI 生态的团队，但需评估与代码平台的一致性。

• Jenkins 的定位与插件生态
• 传统前端 CI/CD 的价值
• 与现代流水线的结合

Jenkins 是成熟的开放 CI/CD 服务，通过插件生态支持海量工具与集成，在传统企业/私有化环境中广泛使用。工程价值：可自托管、支持私有网络与合规、插件灵活、可编排复杂流水线。前端应用：用 Pipeline（Jenkinsfile）定义安装、构建、测试、部署，配合构建产物归档、镜像推送与部署远程主机。现代应用挑战：配置与维护成本高、需自行管理节点与安全，逐渐被 GitOps/云原生 CI 替代，但仍是私有化与合规场景的务实选择。

价值在"开放、可自托管、插件丰富"；取舍是"运维成本高"。适合内网/合规环境，现代可结合容器与 GitOps 降低维护负担。

• SPA 的静态资源与 HTML 缓存差异
• HTML 不缓存的原因
• 安全与更新

SPA 的静态资源（hash 的 JS/CSS/图片）用 CDN 长缓存（immutable），HTML 入口用 no-cache 或极短 TTL，确保用户每次访问都能拿到最新 HTML 从而引用最新资源。若 HTML 被长缓存，用户会长期停留在旧版本，且可能引用已删除资源。工程实践：CDN 上对 index.html 设置 Cache-Control: no-cache，对 hash 资源设置 public, max-age=31536000, immutable；配合 SPA fallback（try_files）与合理的缓存键。这样兼顾静态资源的高命中与 HTML 的及时更新。

核心是"HTML 常新、资源常驻"。这是 SPA 部署的黄金缓存策略，避免缓存导致版本滞后与资源缺失。

• 版本保留策略
• 清理（GC）策略
• 回滚能力与成本平衡

前端部署需保留若干历史版本以支持回滚，但无限保留会占用存储与成本。策略：保留最近 N 个版本（如最近 10 个）或最近 N 天，并支持"标记保留"特定版本（如稳定版、可回滚的安全版）；清理（GC）遵循生命周期：超过保留窗口的版本自动删除或被转档。S3 可用版本生命周期、容器镜像用 tag 保留策略、平台（Vercel/Netlify）自动管理部署历史。需平衡"回滚可达性"与"存储成本"，并为关键发布保留可回滚点。

核心是"保留窗口 + 自动清理 + 关键版本豁免"。让回滚始终可行，同时避免版本无限堆积，是版本管理的工程化。

• 中间件职责的执行顺序
• 实验黏性（Cookie）与签名
• CDN cache key 与 Vary

设计要点：执行顺序上，鉴权前置应最先执行，未授权请求直接返回 401/403 并带 Cache-Control: no-store，避免未授权响应被 CDN 缓存；地理路由其次，A/B 分流最后（读 Cookie 决定实验组）。实验黏性：用签名 Cookie（如 HMAC 签名，防篡改）记录实验组，同一用户跨请求保持一致，避免跨实验组抖动；若用随机分流，需保证同用户稳定。cache key：CDN 缓存键必须包含 Cookie 或按 Vary 区分（或把鉴权/实验标识放入 cache key），否则不同用户/实验组的响应会互相污染缓存。未授权与个性化响应一律 no-store 或进独立 cache key。

核心是"顺序（先鉴权防缓存泄露）+ 黏性（签名 Cookie 保证稳定）+ 缓存键（Vary 隔离）"。三者协同避免未授权缓存与实验抖动。

• KV 的最终一致性语义
• read-after-write 问题
• 跨 PoP 并发覆盖

Cloudflare KV 与 Deno KV 是最终一致性的键值存储。购物车/会话写入 KV 后，若用户立即读取自己的数据，可能因 KV 复制延迟读到旧值（read-after-write 不一致）；且 KV 的写是"最后写赢"（last-write-wins），同一用户在不同 PoP 的并发更新（如两个标签页/设备同时加购）会互相覆盖，导致购物车丢失部分条目。工程对策：对需要强一致或原子更新的会话/购物车，改用 Durable Objects（单对象串行、强一致）而非 KV；若必须用 KV，则接受短时最终一致、用版本号/合并策略防止覆盖，或把关键操作序列化到单一 PoP。

核心是"KV 最终一致 vs 会话强一致需求"。购物车/会话需强一致与原子操作，KV 的 read-after-write 与 last-write-wins 会带来数据丢失，故应选 DO 等强一致存储。

• 并发部署冲突与产物覆盖
• 部署锁与窗口
• 发布审批流

多团队协作时，并发部署可能互相覆盖产物或造成环境冲突。工程实践：部署锁（deployment lock）——同一环境同时只允许一个部署进行，用 CI 的锁/环境锁或分布式锁（如数据库/Redis 锁、GitHub 的 environment 规则）串行化部署；部署窗口（deployment window）——约定或限制发布时段，避免高峰期冲突；产物覆盖——用不可变版本/唯一目录避免互相覆盖，或用环境隔离（每团队独立预览环境）。发布审批流：生产发布需多级审批（如 PR 审批 + 环境审批 + 手动确认），通过 CI 的 required reviewers、environment protection 与审批门实现，保证发布受控。

核心是"串行化部署 + 隔离产物 + 受控审批"。锁与窗口防冲突，审批流保证质量与可追溯，避免多团队互相踩踏。

• Source Map 的用途与泄露风险
• 安全上传与访问控制
• 与运维/监控协作

Source Map 用于把混淆/压缩后的运行时报错映射回源码，便于定位。但 Source Map 包含源码，若被公开访问会泄露业务逻辑。安全实践：不要把 Source Map 公开部署到生产静态目录，而是通过认证方式上传到 Sentry/LogRocket 等监控平台（平台私密存储、仅授权访问），或仅内部 CDN 访问且带鉴权；生产构建关闭 sourcemap 或仅上传不公开。协作：构建流程生成 source map 并上传到监控平台（关联版本号/sha），监控平台用它还原堆栈，前端团队与运维/监控团队协作维护符号映射与版本对应，保证报错可定位且源码不泄露。

核心是"监控可用、源码保密"。Source Map 应私密存储于监控平台而非公开，通过版本关联实现错误定位，同时控制访问权限。

• 边缘函数与 Serverless 的差异
• 延迟与运行时约束
• 适用场景

Edge Functions 运行在边缘节点（靠近用户），延迟低、适合地理相关与轻量逻辑，但运行时受限（无完整 Node I/O、内存/CPU 限制、单次短执行）；Serverless（如 AWS Lambda、Node Functions）运行在区域数据中心，能力更全（可访问完整 Node 生态、更长时间与内存），但冷启动到区域距离可能增加延迟。取舍：需要低延迟、地理路由、轻量逻辑（鉴权、A/B、改写）选 Edge Functions；需要完整 Node 能力、复杂计算、长任务、依赖数据库 SDK 的重逻辑选 Serverless。也可混合：边缘做前置，Serverless 做重逻辑。

本质是"距离 vs 能力"。边缘更近但受限，Serverless 更全但较远。按逻辑复杂度与延迟需求选择，或用边缘+Serverless 分层。

• 环境变量的分层
• 构建期与运行期注入
• 安全与保密

前端多环境变量注入：构建期用 Vite/webpack 的 import.meta.env/process.env 注入，配合 .env.development/.env.staging/.env.production 文件按环境打包；运行期用运行时注入（如 envsubst 替换 JS 模板、占位符）让同一镜像适配多环境。要点：区分公开变量（API 地址、feature flag）与私有变量（密钥，仅服务端/CI 使用，绝不进客户端 bundle）；CI 中按环境注入 secret，避免把密钥写进前端代码。生产环境变量管理与审计，防止泄露。

核心是"按环境注入 + 公开/私有分离"。构建期注入适合打包，运行期注入适合同一镜像多环境，私有变量只留在服务端与 CI。

• content-hash 与 chunk 的关系
• 代码分割的粒度
• 减少不必要的缓存失效

代码分割（动态 import、按路由/依赖分包）把包拆成多个 chunk，每个 chunk 用 content-hash 命名。策略目标是让一次改动只影响真正变更的 chunk，其余 chunk 的 hash 不变，从而最大化缓存命中。实现要点：第三方依赖单独分包（vendor chunk，依赖升级才变 hash）；业务代码按路由分包（只改某路由的 chunk）；用稳定的模块 ID/基于内容而非顺序的 chunk 命名，避免"文件没变但 hash 变了"；对跨 chunk 的公共依赖合理抽取，避免拆分过度导致缓存失效扩散。构建器（webpack 的 optimization.splitChunks、Vite 的分包）可配置。

核心是"最小化缓存失效面"。细粒度分包让改动局部化，statistics 可验证"只改受影响 chunk"。这要求稳定命名与合理分包边界。