开发、测试、预发与生产环境边界

开发、测试、预发与生产环境边界高清原图

把同一个应用部署到四个地方，只改数据库账号、短信凭据、回调地址或网络出口，业务结果就可能完全不同。开发、测试、预发和生产因此不是四台服务器的名字，而是四份不同的风险权限：预发可以验证生产式部署，却不该有权发送真实短信。两个名称不同的 Namespace 如果共享生产凭据和写权限，仍然处在同一个风险域。

候选进入下一阶段时，制品字节、部署方式和迁移工具需要保持可比，数据库账号、凭据、数据与外部副作用则要严格分开。前一组让验证结果能够随候选晋级，后一组阻止低环境取得生产权力。把生产数据和凭据向下复制会越过风险边界；把部署和协议改得面目全非，预发又失去了验证价值。

配套实验让订单服务调用短信服务，并提供可直接运行的 Java / Docker Compose 完整工程。解压后的 README.md 包含运行入口和文件说明。所有请求都停留在本机容器与回环端口，凭据使用公开假令牌，不连接真实云账号、短信平台或生产数据。

环境边界由哪些运行事实组成

先区分代码、制品、发布、部署和实例

“把代码发布到预发”把多个不同对象压缩成了一句话。要判断一次晋级是否可信，必须把对象重新展开：

源代码修订
└─ 构建过程：工具链、依赖解析、测试、打包
   └─ 构建制品：JAR、镜像、静态资源、迁移工具……
      └─ release：制品 + 当前 deploy 的配置引用
         └─ deployment：平台期望运行的版本、副本、身份和策略
            └─ instance：某一时刻真实运行的进程、容器或 Pod
               └─ runtime facts：实际摘要、配置修订、principal、目标和收据

代码修订是版本控制系统中的输入。构建制品是构建过程产生的可交付字节，例如可执行 JAR 或容器镜像。相同 Git commit 在不同时间解析到不同依赖、基础镜像或插件时，可能生成不同字节，因此 commit 不能代替制品身份。

release 表示一次可以被识别和追溯的发布组合。按照 The Twelve-Factor App 的 build、release、run，build 将代码转成可执行制品，release 将 build 与当前部署配置组合，run 再启动进程。release 应拥有唯一标识并保持不可变；修改配置后得到的是新 release，而不是悄悄改写旧 release。

deployment 是平台保存的期望运行状态，例如 Kubernetes Deployment 的 Pod 模板、副本数和更新策略。instance 是该期望状态在某一时刻产生的实际副本。一个 deployment 可以不断替换 instance；滚动更新期间也可能同时存在两个版本。因此，“Deployment YAML 写的是哪个镜像”和“每个 Pod 实际运行哪个镜像”是两个检查点。

环境是承载一类验证任务与权限边界的运行上下文，由账号、集群、Namespace、网络、数据库和第三方账号共同形成。下面用 deploy 表示一套可独立配置的运行位置，用 environment 表示它承担的风险角色；不同平台可能采用其他定义，发布记录应明确本系统的词义。

authority 决定一次运行真正能做什么

环境边界最终约束请求到达后能够造成什么结果。接受写入、扣款、发送通知、发布消息或读取受保护数据的权力，可以统一称为 authority。它通常由多层条件共同决定：

一次外部副作用被接受
├─ 网络路径允许到达目标
├─ TLS 对端身份符合预期
├─ 调用方凭据能够通过认证
├─ principal 被授权访问目标资源
├─ 目标账号、租户、库或主题属于预期环境
└─ 业务规则允许本次操作

低环境访问生产地址时，生产服务端应拒绝它的 principal，数据库不授予相应账号写权限，消息主题和对象存储桶也由独立资源策略拦截。网络出口限制进一步减少误达和攻击面。域名中的 prod 只能帮助识别目标，真正的保护来自服务端授权与资源权限。

人和工作负载需要分别建模。开发者、发布系统、平台控制器和应用进程拥有不同 principal：开发者提交变更时，个人凭据不进入容器；发布系统可以更新 Deployment，运行中的 ServiceAccount 仍无须获得创建 Deployment 的权限；应用读取自己的数据库，也不要求值班人员直接读取生产明文数据。

配置沿多级来源解析

数据库地址、外部服务凭据、主机名和资源句柄会随 deploy 改变，Twelve-Factor Config将它们视为部署配置。工程中还要进一步区分配置的结构、值、来源和实际解析结果：

配置契约
├─ key、类型、必填条件、取值约束与安全默认值
├─ source：JAR 内文件、外部文件、环境变量、系统属性、配置中心、Secret store
├─ source revision：Git 修订、配置版本、Secret 不可变版本
├─ precedence：多个来源冲突时谁覆盖谁
└─ resolved runtime value：实例最终得到的非敏感值或安全摘要

Spring Boot 支持 properties、YAML、环境变量、系统属性和命令行参数等多种来源，并有明确的覆盖顺序；后出现的高优先级来源可以覆盖较早来源。Spring Boot Externalized Configuration还提供 env 与 configprops Actuator 端点辅助定位来源，但这些端点可能暴露敏感结构，生产开放前必须经过访问控制和脱敏评估。

仓库里的 application-staging.yaml 只是配置链的一层，启动参数、Helm values、环境变量、挂载文件和配置中心都可能覆盖它。运行记录应保存 release ID、配置修订、Secret 引用和实际解析到的资源标识，同时避开 Secret 值、令牌和完整连接串。

动态配置和 feature flag 也属于 release 之外的运行输入，可以在进程不重启时改变行为。变更记录至少包含操作者身份、作用域、版本、生效时间和回退值。能够开启真实扣款或批量通知的 flag 直接控制生产 authority，需要按高风险配置管理。

数据、依赖、平台和观测共同形成环境

完整环境至少要识别以下运行事实：

边界对象	需要识别的事实	不能接受的替代判断
制品	目标平台摘要、构建来源、签名或 provenance、测试绑定	Git 分支名、commit 或可变 tag 相同
配置	Schema、来源优先级、修订、Secret 引用、解析后的安全标识	仓库里某份 YAML 看起来正确
身份	人类身份、发布身份、工作负载 principal、token audience	Pod 位于名为 staging 的 Namespace
数据	数据库/Schema/租户、账号权限、来源、分类、保留和清理规则	表结构相同或使用了生产快照
外部依赖	endpoint、账号、sandbox 能力、回调地址、拒绝语义	DNS 能解析、健康检查返回 200
网络	入口、出口、TLS 身份、策略实施者、默认允许/拒绝状态	已经创建 NetworkPolicy 对象
平台	OS/CPU、运行时、资源限制、时钟、证书、区域和故障域	都运行在容器里
观测	service、environment、release、instance、request/operation ID	日志里出现了环境名称

数据环境不只是一条 JDBC URL。还要知道连接落在哪个账号、区域、集群、数据库与 schema，账号具有什么读写权限，数据从哪里生成，是否包含个人或受监管信息，谁负责重置和删除。生产数据直接下沉到测试环境会把真实隐私暴露给更宽松的人员和工具；即使做过脱敏，也要验证关联字段、自由文本、文件附件和备份是否仍可重新识别。

依赖环境可以使用 stub、协议模拟器、真实软件容器、供应商 sandbox 和生产账号。stub 稳定覆盖错误分支，容器验证协议与版本，供应商 sandbox 检查认证和厂商行为；生产配额、证书、网络与数据分布仍要在受控生产验证中确认。自动化测试按风险选择其中一层，无须直接访问生产。

四类常驻环境承担不同任务

开发、测试、预发与生产是常见角色，实际流水线可以按系统风险调整。开发环境通常服务快速反馈，开发者可能直接从本地修订构建临时制品；候选制品更常从测试进入预发，再晋级生产。

环境角色	主要回答的问题	常用数据与依赖	允许的副作用
开发	局部代码是否按预期工作，能否快速调试	合成数据、本地容器、个人沙箱	只影响个人或可随时重建的资源
测试	功能、契约、回归和故障分支能否稳定复现	固定 fixture、测试账号、可控替身	可重放、可清理，不触达真实用户资产
预发	候选能否按生产式部署机制和协议运行	脱敏/合成数据、真实协议、供应商 sandbox	可以阻止晋级，不允许真实扣款、通知或生产写入
生产	系统能否持续服务真实用户并控制风险	真实数据、真实依赖、不可预测流量	只允许经授权的业务副作用，并具备审计和恢复路径

专项环境按风险任务创建。PR preview 用于界面或集成评审，性能环境承担可重复容量实验，安全环境承受攻击性测试，灾备环境用于恢复与切换演练。它们可以短期创建，也可以复用常驻基础设施；是否独立建设取决于要隔离的权力、待验证假设和维护成本。

测试类型描述验证范围，环境提供运行位置。单元、组件、契约、集成、端到端、性能和安全测试中的任何一种，都可能运行在本地、CI 临时容器或稳定测试环境。The Practical Test Pyramid讨论不同粒度自动化测试的反馈速度和维护成本，Consumer-Driven Contracts提供跨服务验证消费者期望的方法。仅记录“测试环境通过”，仍看不出验证内容、故障归属和数据复现条件。

哪些条件应保持一致，哪些权力必须隔离

同一目标平台晋级已经验证的制品

候选晋级最重要的不变量是：进入下一环境的目标平台制品，必须是前一阶段实际验证过的制品。不要在生产阶段重新执行 mvn package 或 docker build，也不要只记录 orders:1.4.0 这样的 tag。tag 是可以被重新指向的名字，digest 才是对具体内容的标识。

OCI Content Descriptors使用 media type、digest 和 size 描述目标内容，并要求消费不可信来源时按摘要验证内容。Kubernetes 也建议用 image@sha256:... 固定实际运行版本，避免 tag 改变后同一工作负载混入不同代码，见 Kubernetes Images。

错误关联：commit abc123 → tag orders:1.4.0 → 各环境重新构建

可验证关联：
source revision abc123
└─ build run build-8472
   ├─ linux/amd64 manifest digest sha256:...
   ├─ linux/arm64 manifest digest sha256:...
   ├─ image index digest sha256:...
   └─ tests / SBOM / signature / provenance
      └─ release stg-r57 → release prod-r91

多架构镜像需要区分 image index digest 与各平台 manifest digest。不同 OS/CPU 平台的字节本来就不同，不能要求它们共享一个平台摘要；应保存 index 到 os/arch → manifest digest 的映射，并确认测试覆盖了将要运行的平台。构建来源、工具链和参数则由 provenance 关联。SLSA Provenance将 provenance 定义为可验证的制品来源信息，用于说明软件在何时、何地、以何种方式产生。

制品一致不意味着 release 相同。预发和生产应复用候选制品，但使用各自配置修订、Secret 引用、工作负载身份、资源策略与依赖账号：

release identity =
  artifact digest
  + deployment specification revision
  + configuration revision
  + immutable Secret references
  + policy / feature-flag revision

runtime evidence =
  actual instance image identity
  + resolved non-secret targets
  + workload principal
  + downstream receipts and accepted business facts

机制与契约尽量同构，值与 authority 分开

预发接近生产，应接近的是启动方式、探针语义、配置 Schema、认证机制、协议版本、数据库迁移过程、观测字段和失败处理。预发不应复制生产私钥、生产数据库写账号、真实短信账号或无限制出口。

对象	应保持可比	必须隔离
应用制品	同一目标平台摘要	不在低环境注入生产工具或调试后门
配置	key、类型、约束、来源规则和安全默认值	值、修订、资源地址与变更权限
身份	相同认证协议和授权模型	principal、issuer/audience、凭据和角色绑定
数据	Schema、业务不变量、迁移与兼容窗口	记录、租户、写账号、备份、保留和清理权限
外部依赖	协议、认证流程、错误语义和兼容版本	sandbox/production 账号、目标、配额与副作用
平台	部署、探针、资源限制和观测语义	账号、区域、故障域及按风险决定的物理资源

安全的低环境会在多层独立失败。短信地址误写成生产端点时，低环境令牌无法通过生产认证；令牌意外泄露后，资源策略继续限制账号与收件人；应用尝试直连时，出口策略还能阻断。这样，一处配置错误不会直接变成真实业务副作用。

Namespace、Secret 和 NetworkPolicy 各自只解决一部分问题

Kubernetes Namespace 为 namespaced object 提供名称作用域和管理范围，安全隔离还要依靠身份、授权、网络和集群配置。ServiceAccount 是工作负载使用的非人类身份，并且属于某个 Namespace；不同环境和工作负载应分配独立 ServiceAccount，再以最小权限绑定资源，见 Kubernetes Service Accounts与 RBAC Good Practices。

同一 Namespace 内的边界尤其弱。能创建 Pod 或修改 Deployment 的主体，通常可以让新 Pod 挂载该 Namespace 中的 Secret，间接取得其他工作负载权限。除了检查运行 ServiceAccount 的 get secrets 权限，还要限制谁能创建工作负载、引用哪些 Secret、使用哪些 ServiceAccount，并评估是否需要独立账号或集群。

Kubernetes Secret 是承载敏感数据的 API 对象，安全存储、轮换和审计还需要额外配置。官方 Secrets文档要求结合静态加密、最小权限、容器访问限制和外部 Secret store 等措施；OWASP Secrets Management Cheat Sheet进一步覆盖创建、轮换、撤销、过期和审计等生命周期控制。排查时不要执行 kubectl get secret -o yaml 来“确认密码”，应核对 Secret 名称、不可变版本、挂载关系、权限和密库审计。

NetworkPolicy 只有在集群网络实现支持并执行它时才生效；没有策略选择 Pod 时，默认仍可能允许流量，见 Kubernetes Network Policies。它按 Pod、Namespace、端口和 IP 等条件控制三四层流量，不负责验证应用层账号、HTTP Host 或 TLS 对端身份。环境边界必须把网络策略、工作负载身份和目标服务端授权组合起来。

数据代表性与数据权限不能混为一谈

测试数据要覆盖生产风险，同时避开整库复制。可以先从业务不变量设计合成数据，再针对分布、长度、字符集、时区、空值、重复、乱序和历史版本构造数据集。必须使用生产样本时，应经过授权、最小化、脱敏、隔离、保留期和删除证明，并确认附件、日志与备份没有绕开处理链。

数据库 Schema 一致也不证明应用可以安全晋级。滚动发布或回退期间，新旧应用可能同时访问同一生产数据库；迁移需要声明兼容窗口。常见做法是先扩展 Schema，让新旧版本都能读写，再迁移数据和流量，确认旧版本退出后才收缩旧字段。应用镜像回退无法自动撤销已经提交的数据迁移。

测试数据还要有来源和生命周期。fixture 由哪个版本生成，测试前是否清理，失败后是否保留证据，并行执行是否共享业务键，都是复现条件。把一套长期污染的测试库当作“更接近生产”，通常只会制造顺序依赖和不可解释的偶发失败。

外部依赖既要验证成功，也要验证拒绝

支付、短信、邮件、对象存储、OAuth 和 webhook 都可能产生环境串线。低环境需要独立账号、回调域名、签名密钥、资源前缀与配额。客户端配置校验可以在启动时拒绝明显冲突，例如 environment=staging 却声明 expectedAccount=production；真正安全边界仍应由目标服务根据调用 principal 和资源策略拒绝。

成功测试只能证明一条路径可用。环境隔离还必须有反向断言：预发 principal 调用生产目标会失败，错误凭据无法产生记录，生产计数和账本保持不变。失败响应、目标服务审计和副作用查询应由同一个 request ID 或 operation ID 关联。

回调是容易遗漏的反向路径。请求虽然使用 sandbox 账号，供应商后台却可能仍把回调发往生产 URL。验证时要同时核对出站 endpoint、下游账号、回调 URL、签名密钥、DNS/TLS 身份和实际接收日志。浏览器参与 OAuth 或支付时，还要使用开发者工具 Network 面板确认重定向链、Cookie Domain/SameSite 和最终回调主机；页面上的环境标识只供显示。

观测必须能区分环境，也不能互相污染

日志、指标和 Trace 至少应携带稳定的服务名、环境名、release、实例和请求关联标识。OpenTelemetry Deployment semantic conventions定义了 deployment.environment.name，并列出 development、test、staging 和 production 等常用值。该属性用于描述部署环境，不参与服务唯一性；查询和告警仍要同时限定服务与环境。

低环境 telemetry 不应写入生产审计流或触发生产值班告警，生产数据也不应为了排障流入开放的测试日志平台。环境标签、采样策略、保留期、访问权限和告警路由都要隔离。与此同时，字段语义和仪表盘逻辑应尽量一致，使预发演练能够验证生产观测方法。

怎样验证一次候选晋级没有串线

Java / Docker Compose 实验说明

配套工程把同一个 Spring Boot 镜像运行成三个容器：预发订单服务、短信沙箱和短信生产模拟服务。三个容器共享制品字节，却接收不同 mode、环境、release、principal、端点与假令牌。短信服务端只接受属于自身账号的令牌，因此错误路由不会获得生产发送权。

environment-boundaries-lab/
├─ Dockerfile
├─ compose.yaml
├─ compose.misroute.yaml
├─ secrets/
│  ├─ staging-sms-token.txt       # 公开假数据
│  └─ production-sms-token.txt    # 公开假数据
└─ src/main/java/dev/example/environment/
   ├─ EnvironmentContractProperties.java
   ├─ EnvironmentContractValidator.java
   ├─ orders/
   │  ├─ OrderController.java
   │  └─ SmsClient.java
   └─ authority/
      └─ SmsAuthorityController.java

EnvironmentContractValidator 在启动时验证环境、release ID、配置修订、摘要格式、工作负载身份、目标账号、端点和令牌文件。主机名对应规则只用于尽早发现示例中的配置冲突，不能替代服务端认证。SmsAuthorityController 独立校验令牌并记录接受计数，代表真正控制副作用的下游 authority。订单服务的 HTTP 客户端还设置了 2 秒连接超时和 3 秒请求超时，避免依赖无响应时让实验无限等待。

实验使用 Java 25、Maven 3.9.12、Spring Boot 4.1.1 与 Docker Compose v2。Linux 或 WSL 2 可直接执行以下命令；Docker Desktop 的终端也可执行等价命令。操作者只需要读取工程、构建本地镜像和管理该 Compose 项目的权限，不需要 root、云账号或 Kubernetes 权限。

先下载并解压完整工程，进入 environment-boundaries-lab 目录，确认运行环境：

LAB_DIR="$PWD"
test -f "$LAB_DIR/compose.yaml"
java -version
docker version
docker compose version

./mvnw 需要主机提供 Java 25，Maven 版本由 Wrapper 固定；没有主机 JDK 时可以跳过主机 Maven 命令，因为 Dockerfile 会在 Maven/Temurin 构建阶段执行同一条 mvn clean verify。docker version 应同时显示 Client 与 Server，docker compose version 应显示 v2。若 daemon 不可用，先启动 Docker Engine；若只有旧的 docker-compose 命令，应先安装 Compose v2，避免命令和合并语义差异。生产构建还应把基础镜像从可变 tag 固定到经过审核的 digest，本实验保留可读 tag 以便教学复现。

构建一次候选并固定本地镜像身份

从工程根目录执行：

# 主机已安装 Java 25 时执行；否则从 docker build 开始
./mvnw -B -ntp clean verify
docker build --tag local/environment-boundaries-lab:1.0.0 .

export ARTIFACT_DIGEST="$(docker image inspect \
  --format '{{.Id}}' local/environment-boundaries-lab:1.0.0)"
printf '%s\n' "$ARTIFACT_DIGEST"

主机 Maven 或 Docker 构建阶段至少有一处应报告：

Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
BUILD SUCCESS

ARTIFACT_DIGEST 应以 sha256: 开头，后接当前机器构建出的镜像内容 ID，例如：

sha256:<64 个十六进制字符>

每次构建都以本机 docker image inspect 返回的值为准，不应拿示例值与自己的输出比较。本地 BuildKit 输出可能把该 ID 指向带证明的 image index；它是当前机器上这次构建的内容身份，不应直接冒充远端 registry 中某个平台 manifest digest。真实发布系统需要保存 registry index、平台 manifest 与节点平台的对应关系。

若测试失败，应从第一条失败断言检查配置契约；若 Docker 构建失败，应区分基础镜像拉取、依赖下载、编译测试和运行层组装。变量为空时不得继续启动 Compose，否则会失去“全部容器使用同一制品”的约束。

运行正常路径并核对副作用

同一个 shell 中继续执行：

docker compose up --detach --wait --wait-timeout 90

curl -q --noproxy '*' --fail-with-body --silent --show-error \
  http://127.0.0.1:18082/release

curl -q --noproxy '*' --fail-with-body --silent --show-error --request POST \
  --header 'X-Request-ID: req-sandbox-001' \
  http://127.0.0.1:18082/orders/order-1001/notify

curl -q --noproxy '*' --fail-with-body --silent --show-error \
  http://127.0.0.1:18083/accepted-count
curl -q --noproxy '*' --fail-with-body --silent --show-error \
  http://127.0.0.1:18084/accepted-count

--wait 要求三个服务在 90 秒内通过健康检查。/release 只返回环境、release、配置修订、镜像身份、工作负载标识、目标端点和预期账号，不返回令牌内容。正常请求的 JSON 字段顺序可能不同，关键语义应为：

-q 必须作为 curl 的第一个选项，才能阻止用户级 .curlrc 改写请求；--noproxy '*' 阻止代理环境接管回环地址；成功路径上的 --fail-with-body 会在 HTTP 4xx/5xx 时保留响应体并返回非零状态。负向路径预期得到 424，因此不使用 fail 选项，而是分别检查 curl 传输退出码和精确 HTTP 状态。

environment = staging
artifactDigest = $ARTIFACT_DIGEST
workloadId = orders-staging
smsExpectedAccount = sandbox

notify status = accepted
notify account = sandbox
receiptId = sandbox-1
sandbox accepted = 1
production accepted = 0

连接失败时先执行 docker compose ps，确认端口和健康状态，再用 docker compose logs --no-color orders-staging 查看应用启动原因。通知返回非 202 时，应按同一个 request ID 查看订单和短信模拟服务日志。生产计数不为 0 表示实验边界已经失败，应立即停止并检查是否错误叠加了 compose.misroute.yaml 或改动了假令牌。

故意误路由，验证生产 authority 独立拒绝

反向实验只重建订单容器，把短信端点改为 sms-production，但仍保留 staging 的 sandbox 假令牌。覆盖文件还打开 APP_ALLOW_MISROUTE=true，用于绕过示例的主机名快速失败。校验器明确禁止该开关出现在 production mode；真实系统不应保留这种教学开关。

docker compose -f compose.yaml -f compose.misroute.yaml \
  up --detach --no-deps --force-recreate \
  --wait --wait-timeout 90 orders-staging

NEGATIVE_BODY="$LAB_DIR/negative-response.json"
NEGATIVE_RC=0
NEGATIVE_STATUS="$(curl -q --noproxy '*' --silent --show-error \
  --output "$NEGATIVE_BODY" \
  --write-out '%{http_code}' \
  --request POST \
  --header 'X-Request-ID: req-production-denied-001' \
  http://127.0.0.1:18082/orders/order-1002/notify)" || NEGATIVE_RC=$?

cat "$NEGATIVE_BODY"
printf '\nHTTP %s\n' "$NEGATIVE_STATUS"
test "$NEGATIVE_RC" -eq 0
test "$NEGATIVE_STATUS" = '424'

curl -q --noproxy '*' --fail-with-body --silent --show-error \
  http://127.0.0.1:18084/accepted-count

生产模拟服务实际返回 403 Forbidden；订单服务把下游拒绝映射成对调用方的 424 Failed Dependency，因此预期输出是：

{"requestId":"req-production-denied-001","status":"forbidden","account":"production"}
HTTP 424
{"account":"production","accepted":0}

这组结果表达三个不同事实：网络路径确实到达了生产模拟服务；sandbox 凭据没有获得 production authority；生产副作用计数保持为零。只得到 424 而不检查下游账号和计数，不能排除请求其实失败在别处。

再核对三个运行实例：

docker inspect \
  environment-boundaries-lab-orders-staging-1 \
  environment-boundaries-lab-sms-sandbox-1 \
  environment-boundaries-lab-sms-production-1 \
  --format '{{.Name}}|{{.Image}}|{{.Config.User}}|{{.State.Health.Status}}'

实测三行的镜像 ID 完全相同，用户均为 10001:10001，健康状态均为 healthy。这证明差异来自运行输入和服务端权限，而不是换了一份专门写死结果的代码。

输出图中的镜像 ID 是同一次实测的缩写，三行相同值对应三个容器引用同一镜像。其他机器会生成自己的 ID。图中命令也经过节选，复现时使用上面的完整 curl 命令控制 curlrc、代理、传输退出码与 HTTP 状态。

环境边界 Java 与 Docker Compose 正反验证输出

实验结束后使用同一变量和覆盖文件清理：

docker compose -f compose.yaml -f compose.misroute.yaml \
  down --remove-orphans
rm -f -- "$NEGATIVE_BODY"
unset ARTIFACT_DIGEST NEGATIVE_BODY NEGATIVE_RC NEGATIVE_STATUS

down 应删除本项目三个容器和专用网络。镜像保留用于复验；需要释放空间时，可以在确认没有其他实验依赖后单独删除 local/environment-boundaries-lab:1.0.0，不要使用覆盖整个 Docker 环境的清理命令。

在 Kubernetes 中核对声明与运行事实

本地实验覆盖的是同一 Docker 主机上的身份与网络限制。进入 Kubernetes 现场后，还要使用只读身份核对 context、Deployment、Pod、ServiceAccount、配置引用和运行镜像。以下命令适用于 Linux shell，操作者需要目标 Namespace 中 Deployment、Pod、NetworkPolicy 的 get/list 权限；Nodes 是集群级资源，若没有权限，应向平台清单查询节点 os/arch，不要临时申请管理员账号。

export STAGING_CONTEXT='staging-cluster'
export APP_NAMESPACE='orders-staging'
export APP_NAME='order-api'

kubectl --context "$STAGING_CONTEXT" cluster-info
kubectl --context "$STAGING_CONTEXT" auth can-i get deployments \
  --namespace "$APP_NAMESPACE"
kubectl --context "$STAGING_CONTEXT" auth can-i list pods \
  --namespace "$APP_NAMESPACE"

cluster-info 的 API 地址必须属于预期集群，两次 can-i 应返回 yes。返回 no 时停止，不要删改资源或切换到高权限 kubeconfig；由平台管理员提供只读证据或最小权限。context 指向生产时也应停止，重新确认终端、身份和变量。

读取期望状态与 Pod 实际状态：

kubectl --context "$STAGING_CONTEXT" --namespace "$APP_NAMESPACE" \
  get deployment "$APP_NAME" \
  -o jsonpath='{.metadata.generation}{"\t"}{.status.observedGeneration}{"\t"}{.spec.replicas}{"\t"}{.status.updatedReplicas}{"\t"}{.status.readyReplicas}{"\t"}{.status.availableReplicas}{"\t"}{.spec.template.spec.serviceAccountName}{"\t"}{.spec.template.spec.containers[?(@.name=="app")].image}{"\n"}'

kubectl --context "$STAGING_CONTEXT" --namespace "$APP_NAMESPACE" \
  get pods -l app=order-api \
  -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.nodeName}{"\t"}{.spec.serviceAccountName}{"\t"}{.status.phase}{"\t"}{.status.containerStatuses[?(@.name=="app")].ready}{"\t"}{.spec.containers[?(@.name=="app")].image}{"\t"}{.status.containerStatuses[?(@.name=="app")].imageID}{"\n"}{end}'

generation 与 observedGeneration 不一致，updated/ready/available 未达到期望副本，Pod 不是 Running 且 Ready，ServiceAccount 不是预期 staging 身份，imageID 为空或同批 Pod 出现无法解释的多个摘要时，都不能放行。容器运行时的 imageID 格式可能带前缀，也可能报告平台 manifest；应按已知 runtime 规则归一化，并与 registry 解析结果、节点平台和发布记录核对，不能直接截取字符串比较。

继续读取配置引用和网络策略，但不读取 Secret 内容：

kubectl --context "$STAGING_CONTEXT" --namespace "$APP_NAMESPACE" \
  get deployment "$APP_NAME" \
  -o jsonpath='{range .spec.template.spec.containers[?(@.name=="app")].envFrom[*]}configMap={.configMapRef.name}{" secret="}{.secretRef.name}{"\n"}{end}{range .spec.template.spec.volumes[*]}volume={.name}{" configMap="}{.configMap.name}{" secret="}{.secret.secretName}{"\n"}{end}'

kubectl --context "$STAGING_CONTEXT" --namespace "$APP_NAMESPACE" \
  get networkpolicy

输出应只含引用名称，不含 Secret 值。配置还可能来自单个 env.valueFrom、CSI Secret Store、init container、sidecar 和配置中心，因此 envFrom 为空时仍要继续检查。NetworkPolicy 对象创建后，还要确认选择器覆盖目标 Pod、包含预期 egress、集群 CNI 支持策略，并通过受控拒绝测试或流量审计验证实施结果。

镜像、身份和配置引用仍只是平台侧证据。最终还要从应用脱敏启动记录确认解析后的数据库/依赖资源标识，从数据库审计确认实际账号，从短信或支付收据确认下游 account，从出口日志确认目标，从 Trace 确认 release 与 request ID。声明和下游事实冲突时，以实际运行和资源服务端接受的事实为准。

环境串线与漂移怎样控制、定位和恢复

先按对象层定位，不按环境名称猜测

环境问题通常表现为“预发通过、生产失败”或“低环境产生了真实副作用”，根因却可能位于不同层。可以按以下结构收缩范围：

运行结果异常
├─ 制品身份
│  ├─ tag 被覆盖、生产重建、平台 manifest 不同
│  └─ 滚动更新未收敛、旧实例仍接流量
├─ release 输入
│  ├─ 配置来源覆盖、修订未知、动态 flag 漂移
│  └─ Secret 引用/版本、证书或回调地址错误
├─ authority
│  ├─ ServiceAccount、云角色、数据库账号错误
│  └─ 资源服务端授权过宽或低环境凭据泄露
├─ 数据与依赖
│  ├─ Schema/数据分布/配额/区域差异
│  └─ sandbox 与生产协议或错误语义不同
├─ 平台与网络
│  ├─ DNS、TLS、出口、NetworkPolicy、代理
│  └─ CPU 架构、资源限制、时钟、证书链
└─ 观测
   ├─ 环境标签错误、日志/Trace 串流
   └─ request ID、release 或下游收据无法关联

先确认“什么制品、什么 release、什么 principal、访问了什么资源、资源端接受了什么”，再讨论代码缺陷。只看配置仓库或 CI 绿色状态，会忽略运行时覆盖、漂移和未收敛实例。

低环境触达真实副作用时先控制 authority

假设预发订单触发了真实短信。第一步是停止产生新副作用：暂停对应任务或入口，并优先在生产短信服务端撤销该低环境 principal、账号或资源授权，也可以阻断明确的预发出口。不要先反复修改 URL 并重试，因为每次试错都可能继续发送。

随后保存不会泄密的证据：短信 provider request ID、下游账号、收件目标的安全标识、时间窗、应用 request/operation ID、release、实例、工作负载身份、配置修订、Secret 引用版本和出口记录。Secret 值不应复制到事故文档。凭据已泄露时，按影响范围轮换；共享凭据轮换会影响所有消费者，必须协调而不能只在预发删除文件。

反查顺序从已经发生的资源端事实开始：

下游收据或业务事实
└─ 接受动作的 production / sandbox account
   └─ 认证到的 caller principal 与 credential reference
      └─ 工作负载 ServiceAccount / 云身份 / 数据库账号
         └─ 实际出口、DNS/TLS 对端与网络策略
            └─ 实例解析到的配置修订和动态 flag
               └─ release、deployment 与制品摘要

这样可以区分“地址配错但被拒绝”和“生产权限真的下沉”。地址误配且被拒绝属于未造成副作用的 near miss，仍需修复配置和防护；一旦生产请求已被接受，还要评估真实影响、通知责任和业务补偿。

修复后必须同时复验正向与反向路径。预发短信使用 sandbox 账号生成新收据；同一预发 principal 访问生产目标被客户端策略、网络或服务端拒绝；被撤销的凭据无法再次使用；生产计数没有增加；新旧请求通过不同 request ID 关联到确定 release。“预发又能发短信”只覆盖正向功能，生产权限是否收回要由拒绝记录和服务端授权状态确认。

配置漂移要比较来源、修订和解析结果

配置漂移包括声明漂移与运行漂移。声明漂移是环境配置库或部署清单偏离基线；运行漂移是实例实际解析结果与声明不一致，例如命令行参数覆盖文件、手工修改 ConfigMap、Secret 轮换未重启、配置中心推送部分失败或旧 Pod 仍在运行。

安全的漂移检测不比较明文 Secret，而比较配置 Schema、key 集合、来源、修订、Secret 不可变版本、资源标识和安全摘要。差异需要分成三类：预期的环境值差异、允许但需审批的平台差异、无法解释的漂移。将所有环境文件做文本相等比较，会把合法隔离误报成问题，也会漏掉不同来源最终解析为同一危险目标。

应用启动时应校验关键契约并在失败时拒绝就绪，例如 production 不允许调试模式、staging 不允许 production tenant、数据库只读任务不允许写账号。校验信息只能打印资源标识和失败原因，不能打印密码。对于动态配置，变更应产生新的审计事件和运行版本，并能够回答哪些实例已经收敛。

预发通过而生产失败并不自动说明预发无用

预发能够验证生产式部署、配置结构、协议、迁移和观测假设，却无法完整复制生产流量、数据分布、证书链、配额、区域故障、缓存状态和真实第三方行为。剩余风险需要生产预检、小流量发布和持续观测接手。

生产独有差异要分开处理。容量通过可控压测和模型估算，真实数据长尾通过脱敏统计与合成边界数据覆盖。证书、DNS 和网络策略适合发布前只读验证；第三方生产账号只做最小连通性检查或受控 canary。真实流量与缓存状态留给带有限额、停止条件和快速回退的灰度发布。破坏性 Schema 变更、一次性批任务和不可逆外部副作用不应默认交给灰度兜底。

某类故障多次只在生产出现时，先把差异转成明确事实，再决定验证位置。处理结果可能是改进合成数据、给预发增加相同 CPU 架构、引入供应商 sandbox、增加生产只读预检，或在生产建立小流量验证。环境设计随实际风险调整，而非简单增加一套“更像生产”的环境。

回退应用与恢复业务事实是两条路径

把 Deployment 切回旧镜像只改变后续运行的应用字节。它不会撤销已经发送的短信、提交的支付、写入的数据、发布的消息或执行完的数据库迁移：

应用运行轨
当前 release ──切流/回退──> 旧的兼容 release

业务事实轨
已提交数据 / 已发布消息 / 已发送通知
└─ 对账 ──> 补偿、撤销、人工处置或向前修复

能否回退取决于新旧应用与当前 Schema、消息和配置是否兼容。若新版本已经写入旧版本无法读取的数据，盲目回退会制造第二次故障。发布前要声明兼容窗口、停止条件、回退版本、数据迁移状态和不可逆操作；事故中则以实际业务事实决定补偿或向前修复。

Secret 泄露也不能靠镜像回退解决。应先撤销或轮换凭据，查明可访问资源和时间窗，审计实际使用，再更新消费者并验证旧凭据失效。若 Secret 曾进入 Git 历史、镜像层或构建日志，删除当前文件不足以消除泄露面。

环境数量由验证收益和维护成本共同决定

每套常驻环境都会增加补丁、证书、配置、凭据、数据重置、监控、费用和漂移成本。无人维护的预发可能比按需创建的临时环境更不可信。环境生命周期至少要有 owner、用途、创建来源、到期时间、数据分类、成本归属和销毁证明。

PR preview 适合按需创建并在合并后销毁；固定回归适合可重置测试环境；长期合作方联调或生产式部署演练可能需要稳定预发；性能和灾备环境可以按计划启用。合并环境角色时，必须确认权限与数据仍能隔离，例如同一集群中的 test 与 staging 不能因为节省成本而共享高权限 ServiceAccount。

环境名称只有在这些条件成立后才对应真实工程边界：每种风险有明确验证位置，每次 release 能关联制品与运行输入，低环境在资源服务端无法取得生产权力，运行结果还能通过下游事实反查。四套环境同时在线本身说明不了这些关系。

权威资料与规范地址

以下资料可用于查阅构建发布、配置来源、容器制品、Kubernetes 边界、测试策略与观测语义；实施时还需结合所用产品版本和组织安全要求。

构建、发布、配置与供应链

资料	地址
The Twelve-Factor App — Build, release, run	https://12factor.net/build-release-run
The Twelve-Factor App — Config	https://12factor.net/config
Spring Boot — Externalized Configuration	https://docs.spring.io/spring-boot/reference/features/external-config.html
OCI Image Specification — Content Descriptors	https://github.com/opencontainers/image-spec/blob/main/descriptor.md
SLSA v1.2 — Provenance	https://slsa.dev/spec/v1.2/provenance

Kubernetes 作用域、身份、密钥与网络

资料	地址
Kubernetes — Namespaces	https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/
Kubernetes — Service Accounts	https://kubernetes.io/docs/concepts/security/service-accounts/
Kubernetes — Secrets	https://kubernetes.io/docs/concepts/configuration/secret/
Kubernetes — RBAC Good Practices	https://kubernetes.io/docs/concepts/security/rbac-good-practices/
Kubernetes — Network Policies	https://kubernetes.io/docs/concepts/services-networking/network-policies/
Kubernetes — Images	https://kubernetes.io/docs/concepts/containers/images/

测试、Secret 管理与观测

资料	地址
Martin Fowler — The Practical Test Pyramid	https://martinfowler.com/articles/practical-test-pyramid.html
Martin Fowler — Consumer-Driven Contracts	https://martinfowler.com/articles/consumerDrivenContracts.html
OWASP — Secrets Management Cheat Sheet	https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html
OpenTelemetry — Deployment semantic conventions	https://opentelemetry.io/docs/specs/semconv/resource/deployment-environment/