部署槽位：一个服务内部的并行环境

同一入口后的第二份副本

部署槽位用同一套应用定义运行在独立基础设施上，拥有自己的主机名和配置。你把新版本部署到空闲槽位、预热并测试，然后把生产流量切过去。旧版本仍在另一个槽位运行，因此回滚只是重定向，而不是重新构建。

切换前先预热

冷启动是坏发布最常见的诱因。槽位让你在任何真实用户之前直接访问新版本：预热缓存、建立连接池、完成 JIT 编译并核对配置。例如，把流量切到缓存为空的实例，会产生一次看起来像代码回归的延迟尖刺。

deploy:
  slot: staging
  warmup:
    - url: /healthz
      expect: 200
    - url: /api/warmup
      expect: 200
swap:
  target: production
  rollback: true

槽位不能解决的问题

槽位不隔离状态：会话、进程内缓存、后台任务和数据库连接都会跨越边界。它也不能解决 schema 兼容性：两个槽位可能短暂同时服务同一个数据库，因此迁移至少要向后兼容一个发布周期。粘性会话需要明确的方案，否则切换时用户会被登出。

与滚动发布和蓝绿的对比

滚动发布逐步替换实例，不需要双倍容量，但会让用户在一段时间内接触混合版本。蓝绿用独立基础设施实现同样的原子切换，成本通常更高。槽位介于两者之间：比完整第二套环境便宜，比滚动更原子，但仅限于单个服务的范围。

何时使用

当发布频率不高、可以接受双倍容量，且预热会明显影响行为时，使用槽位。对于高频发布，采用流量切换的渐进式交付通常更合适。