React 项目实践

如何优化 React 项目的构建、发布和回滚？

发布系统要保证产物可复现、配置可控、缓存可兼容，并能在异常时快速止损。

适合阶段：资深前端 / 工程负责人核心能力：构建优化 · 发布治理 · 回滚

面试官想考什么

• 如何定位构建慢和 bundle 变大的原因？ 考察工程分析能力。
• 环境变量和密钥如何管理？ 考察安全意识。
• 静态资源缓存如何兼容灰度和回滚？ 考察发布链路。
• 前端回滚是否只是重新部署旧包？ 考察系统性思考。

一句话回答

React 发布要让代码、静态资源、配置和数据迁移可独立演进，产物可复现且带版本，灰度和回滚必须考虑缓存、旧页面和 API 兼容。

面试回答详解

1. 构建优化

用 bundle analyzer、构建 profile 和依赖图定位大包、重复依赖、全量导入和过大的入口；通过路由/交互切分、tree shaking、缓存和并行构建降低成本。

2. 配置与安全

构建时公开变量和运行时私密配置分开，不能把服务端密钥打进客户端。配置应有 schema、环境校验和变更审计，避免本地和生产行为漂移。

3. 发布与缓存

静态资源使用带 hash 的不可变 URL；HTML、manifest 和入口版本要考虑旧页面引用旧 chunk 的情况。灰度时新旧前端可能同时访问后端，因此 API 要向后兼容。

4. 回滚

回滚应用版本、feature flag 和配置，同时确认数据库 schema、缓存 key、CDN、Service Worker 和第三方 SDK。错误率、加载失败、Web Vitals 和业务成功率是发布观察指标。

可直接背诵的 30 秒回答

我会先用 bundle analyzer 和构建 profile 定位大依赖、重复依赖和入口问题，再做代码分割、缓存和依赖治理。发布时区分公开配置和私密配置，静态资源采用 hash 和不可变缓存，HTML 与 API 要兼容新旧版本。回滚不仅是换旧包，还要检查 CDN、Service Worker、缓存 key、数据库和 feature flag。

扩展知识

发布依赖图

source -> build artifact -> CDN/static assets -> HTML/runtime config
-> API compatibility -> feature flag -> monitoring -> rollback

面试官追问链

追问一：为什么资源都 hash 了，回滚还会失败？

• 考察点：是否理解入口和缓存。
• 回答方向：旧 HTML 可能引用已清理 chunk，Service Worker 可能缓存了不兼容 manifest，或者新旧前端调用了不兼容 API；需要保留资源和兼容窗口。

追问二：如何判断 bundle 优化有效？

• 考察点：是否使用用户指标验证。
• 回答方向：同时看产物大小、下载/解析时间、LCP、INP、缓存命中和业务转化，不能只看 gzip 后体积。

追问三：前端如何做紧急止损？

• 考察点：发布应急能力。
• 回答方向：feature flag、kill switch、降级入口和回滚产物；保留用户可恢复路径和故障上下文。

推荐阅读

• React lazy
• React Performance Tracks
• web.dev Performance
• React 项目实践