不可变交付指软件发布中部署单元一旦创建便不再修改，所有变更通过新建部署单元实现。其核心是杜绝运行时修改，确保环境一致性，避免因手动更改导致的故障。每次发布均基于统一镜像生成新实例，保障开发、测试、生产环境一致，解决“在我机器上没问题”现象。回滚时只需切换至上一稳定镜像，操作快速可靠。运行中实例不受人为干预，提升系统稳定性与安全性。该模式天然适配CI/CD自动化流程，结合Docker与Kubernetes等容器技术，实现高效、可重复的部署。新版本通过构建带新标签的镜像完成，旧容器被全新容器替换，过程简洁可控。这一实践显著增强发布可靠性与效率，是现代云原生应用推荐的交付方式。
不可变交付指的是在软件发布过程中，一旦创建了部署单元（比如容器镜像），就不再对其进行修改。任何更新或变更都通过构建一个新的、完整的部署单元来实现，而不是在已有的实例上打补丁或更改配置。
核心理念：不修改，只替换
传统的应用部署常常需要登录到服务器，更新文件、修改配置甚至重启服务。这种方式容易导致环境不一致，“这次上线怎么又出问题了？”——可能就是因为某台机器被手动改过。不可变交付杜绝了这种情况。每次发布都是从统一的镜像重新生成实例，保证了环境的一致性和可预测性。
为什么这么做？好处在哪里
- 一致性高：所有环境（开发、测试、生产）运行的都是同一个镜像，避免“在我机器上是好的”这类问题。
- 回滚简单：如果新版本出问题，不需要撤销复杂的变更操作，只需快速切回到上一个已知正常的镜像版本。
- 更稳定安全：运行中的实例不会被随意改动，降低了人为错误和安全风险。
- 适合自动化：配合CI/CD流程，整个发布过程可以完全自动化，无需人工干预具体部署细节。
常见实现方式
这项实践通常和容器技术结合使用。例如，开发完成后，CI系统会打包出一个包含应用和依赖的Docker镜像，并推送到镜像仓库。部署时，Kubernetes等编排平台会拉取这个镜像并启动容器。后续的每一次变更，都会生成新的镜像标签，用新镜像创建新容器来替换旧的。
基本上就是这样，不复杂但能显著提升发布的可靠性和效率。
