CI/CD：部署一次，debug 三天

CI/CD 是现代前端开发的标配，但现实往往是部署只要几分钟，debug 却要花上三天。自动化流程看似完美，实际落地时总会遇到各种意想不到的坑。

部署一时爽，回滚火葬场

典型的场景：某次代码合并后，CI 流水线绿灯全亮，部署成功。半小时后监控系统开始报警，用户反馈页面白屏。此时回滚按钮成了救命稻草，但可能遇到更糟的情况：

// 示例：一个看似无害的环境变量引用
const API_URL = process.env.REACT_APP_API_URL || 'https://fallback.example.com';

// 问题在于：
// 1. CI 中未正确注入环境变量
// 2. 本地测试时永远走fallback
// 3. 生产环境突然报错时才发现配置缺失

更可怕的是依赖版本问题。比如某次部署更新了间接依赖：

// package.json 片段
{
  "dependencies": {
    "ui-library": "^2.3.0" // 实际安装了2.3.12版本
  }
}

而 2.3.12 版本恰好有个未在 changelog 中提及的 breaking change，导致生产环境样式错乱。此时回滚到上一个版本可能因为 lockfile 不同步而失效。

测试覆盖率陷阱

高测试覆盖率报表可能给人虚假安全感：

// 测试用例：快乐路径
test('should render component', () => {
  render(<Component />);
  expect(screen.getByText('Submit')).toBeInTheDocument();
});

// 实际缺失的测试场景：
// - 接口返回500时
// - 移动端viewport异常时
// - 第三方SDK加载超时时

常见问题包括：

1. Mock 数据过于理想化，与真实 API 响应差异大
2. 浏览器环境模拟不完整（缺少 WebGL 支持等）
3. 时区敏感代码在 CI 服务器上表现不同

环境差异的幽灵

开发、测试、生产环境的不一致堪称经典问题：

# 本地运行正常
$ npm run build && serve -s build

# 生产环境报错
Uncaught TypeError: Cannot read property 'map' of null

根本原因可能是：

• 本地开发服务器自动注入 polyfill，而生产构建没有
• 测试环境使用 mock API，但生产环境 CORS 配置错误
• CI 机器内存限制导致 build 阶段异常终止

监控盲区

即使部署了完善的监控，关键问题仍可能被遗漏：

// 错误上报代码
window.addEventListener('error', (e) => {
  trackError(e); // 但无法捕获Promise rejection
});

// 未处理的异步错误
fetchData().then(data => {
  renderContent(data); // 如果data为undefined则崩溃
});

更隐蔽的问题包括：

• 性能下降但未达到错误阈值
• 特定设备上的 CSS 兼容性问题
• 第三方广告脚本阻塞主线程

依赖地狱

现代前端项目的 node_modules 就像定时炸弹：

# 某次安全更新后
npm audit fix --force

# 结果导致：
- 某个深层依赖降级到不兼容版本
- 隐式依赖关系被破坏
- 构建时出现神秘的peer dependency警告

真实案例：某个项目在 CI 中突然开始报错，最终发现是因为 Docker 镜像中的 Node 版本自动升级到最新 LTS，导致某些原生模块编译失败。

缓存带来的玄学问题

浏览器缓存、CDN 缓存、Service Worker 缓存多层叠加时：

// sw.js 片段
workbox.routing.registerRoute(
  new RegExp('/static/'),
  new workbox.strategies.CacheFirst()
);

可能出现：

• 用户永远卡在旧版本
• 部分资源走缓存而部分走网络导致不一致
• 缓存失效策略在跨地区 CDN 上表现不一致

配置即代码的代价

Infrastructure as Code 虽然强大，但一个参数错误就可能引发灾难：

# serverless.yml 配置示例
functions:
  prerender:
    handler: handler.prerender
    memorySize: 1024 # 生产环境应为2048
    environment:
      CACHE_TTL: 3600 # 开发环境值泄漏到生产

这类问题通常在流量激增时才会暴露，而此时扩容操作可能因为 IaC 的配置限制而受阻。

人机协作的鸿沟

CI 系统的报错信息往往对机器友好但对人类晦涩：

Build failed: ModuleNotFoundError: Module not found: Error: Can't resolve 'core-js/modules/es.array.iterator'

开发人员需要：

1. 理解这是 babel 运行时依赖问题
2. 知道要检查 @babel/preset-env 的 useBuiltIns 配置
3. 确认所有团队成员使用相同的 npm 版本

文档与现实的割裂

项目文档写着：

只需运行：
npm install && npm run deploy

但实际上需要：

1. 先配置 AWS 密钥
2. 安装特定版本的 Serverless Framework
3. 设置正确的环境变量前缀
4. 申请生产环境部署权限

微前端带来的新维度

当项目采用微前端架构后，问题复杂度指数级上升：

// 主应用加载微应用
loadMicroApp({
  name: 'checkout',
  entry: 'https://cdn.example.com/checkout/1.2.3/app.js',
  container: '#micro-container'
}).then(app => {
  // 这里永远resolve，即使子应用加载失败
});

典型问题包括：

• 版本不匹配导致的主子应用通信失败
• 样式隔离被意外破坏
• 全局事件监听器泄漏

长尾效应的恐怖

最棘手的问题往往是那些：

• 只在特定浏览器版本出现
• 需要特定操作顺序才能复现
• 错误率低于监控报警阈值
• 表现时好时坏的玄学问题

例如某个 Safari 14 的 bug：

/* 导致页面布局错乱的CSS */
.grid {
  display: grid;
  gap: 1rem; /* Safari 14会错误计算 */
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
}

这类问题通常要耗费大量时间才能定位，而修复往往只是加个 hack：

/* 修复方案 */
.grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fill, minmax(200px, 1fr));
  /* Safari 14 专修 */
  @media not all and (min-resolution: 0.001dpcm) {
    @supports (-webkit-appearance: none) {
      margin-left: -0.5rem;
    }
  }
}

基础设施的蝴蝶效应

某个周五下午的部署看似顺利，直到周一早高峰：

Error: ECONNREFUSED 127.0.0.1:5432

调查后发现：

1. 某新服务误用开发环境配置
2. 该配置指向本地数据库
3. 但因为在容器内运行，所以 CI 测试通过
4. 真正用户请求到达时才报错

版本锁定的两难境地

严格锁定所有依赖版本确保一致性：

"dependencies": {
  "react": "18.2.0", // 精确版本
  "react-dom": "18.2.0"
}

但会导致：

• 安全更新延迟
• 依赖关系冲突
• 升级时的大爆炸式更新

类型安全的幻象

TypeScript 项目也可能在运行时翻车：

interface User {
  id: string;
  name: string;
}

// 实际API返回
{
  "id": 123, // 不是字符串！
  "name": null // 文档没说可能为null
}

更隐蔽的类型问题：

• 枚举值在运行时被扩展
• 类型断言掩盖了实际数据问题
• 第三方类型声明过时

人为因素不可忽视

最后总有些人类专属问题：

• 紧急修复时直接 push 到 main 分支
• 误删生产环境数据库
• 把测试配置提交到生产代码
• 在 Slack 里说"先部署再说"之后消失