Azure Container Apps Express 现已正式发布（GA），同时 GA 的还有承载它的 Container Apps Sandboxes。这个组合针对的是一类很具体的工作负载：希望直接运行容器、避免预先配置 Container Apps 环境，并在没有请求时把实例缩减到零。
Express 通过预热实例池提供亚秒级启动体验。它降低了部署入口和冷启动延迟，但并没有覆盖完整 Container Apps 平台的全部能力。是否采用，取决于应用更看重启动速度和操作简单性，还是更看重网络、可观测性与平台集成能力。
Express 改变了什么
传统 Container Apps 部署通常需要先准备环境，再配置应用、扩缩容规则和相关依赖。Express 的核心变化是跳过环境配置，让开发者更快从容器镜像进入可运行状态。
它还具备按零扩缩容的特性。没有流量时，应用可以不保留运行实例；新请求到来后，平台从预热池中启动所需的沙盒实例。对于低频 API、Webhook、内部工具和演示环境，这种模型可以减少空闲资源消耗，同时把首次请求的等待时间控制在较低水平。
这里的 Sandbox 是承载容器的微型虚拟机计算层。它为容器提供更明确的隔离边界，也让平台可以围绕启动、回收和预热建立统一的运行时机制。对应用代码而言，仍然应该把实例视为短生命周期、可随时替换的容器，而不是持久主机。
速度提升不是功能等价
Express 的简化入口伴随着明确的能力边界。摘要列出的限制包括：
- 不支持自定义域名。
- 不支持区域冗余（zone redundancy）。
- 不支持 Key Vault 引用。
- 不支持 OpenTelemetry。
- 不支持 Dapr。
这意味着 Express 更适合无状态、依赖外部服务、通过标准 HTTP 接口提供能力的容器。需要服务发现、分布式应用抽象、内建密钥引用或完整遥测链路的系统，仍应评估标准 Container Apps 方案，或者选择其他 Azure 运行平台。
尤其要注意“缩到零”带来的行为变化。应用不能依赖本地文件保存状态，后台任务不能假设进程持续运行，连接池和缓存也必须允许在实例重建后重新初始化。对于 HTTP 服务，还应设置合理的启动探针、请求超时和幂等逻辑。
一个适合 Express 的最小容器服务
下面是一个可以直接构建和运行的 Python HTTP 服务。示例只使用标准库，方便先验证容器的启动和关闭行为，再把镜像接入目标部署流程。
将以下内容保存为 server.py：
import json
import os
from http.server import BaseHTTPRequestHandler, ThreadingHTTPServer
class Handler(BaseHTTPRequestHandler):
def do_GET(self):
if self.path != "/healthz":
self.send_response(404)
self.end_headers()
return
payload = {
"status": "ok",
"service": os.getenv("SERVICE_NAME", "express-demo"),
}
body = json.dumps(payload).encode("utf-8")
self.send_response(200)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(body)))
self.end_headers()
self.wfile.write(body)
if __name__ == "__main__":
port = int(os.getenv("PORT", "8080"))
ThreadingHTTPServer(("0.0.0.0", port), Handler).serve_forever()
再创建 Dockerfile：
FROM python:3.12-slim
WORKDIR /app
COPY server.py .
ENV PORT=8080
EXPOSE 8080
CMD ["python", "server.py"]
本地构建并运行：
docker build -t express-demo:local .
docker run --rm -p 8080:8080 -e SERVICE_NAME=express-demo express-demo:local
另开终端检查健康接口：
curl --fail http://127.0.0.1:8080/healthz
预期会返回类似结果：
{"status": "ok", "service": "express-demo"}
部署到 Express 时，应把镜像地址、监听端口、健康检查和最小实例数作为重点配置项。由于具体命令和可用区域可能随 Azure CLI 版本变化，实际部署前应以当前租户中 Container Apps Express 的 CLI 或门户选项为准，不要直接套用标准 Container Apps 的环境参数。
如何判断是否采用
Express 适合以下场景：
- 请求量有明显波峰波谷，希望空闲时缩减到零。
- 服务是无状态 HTTP API、Webhook 或轻量后台接口。
- 团队希望减少环境预配置和平台运维工作。
- 应用可以接受实例重启，并把状态放在数据库、对象存储或缓存服务中。
下面这些情况需要谨慎：
- 必须绑定自定义域名才能对外提供服务。
- 需要跨可用区冗余。
- 依赖 Azure Key Vault 引用注入配置。
- 需要 OpenTelemetry 或 Dapr 作为平台能力。
- 有长时间运行的后台任务，不能承受缩容或实例回收。
上线前可以逐项确认：镜像是否能在任意实例上重复启动，启动过程是否足够短，首次请求是否允许出现冷启动延迟，外部依赖是否具备重试和超时，日志与指标是否可以通过应用自身或其他平台链路收集。
结语
Container Apps Express 的价值不在于替代所有 Container Apps 工作负载，而在于提供一条更短的容器运行路径。Sandboxes 负责微 VM 隔离和快速启动，Express 则把环境配置、按零扩缩容和预热实例结合起来。
对低频、无状态、HTTP 优先的服务，可以先用一个最小镜像验证启动时间、请求恢复和成本表现。若项目依赖自定义域名、可用区冗余、Key Vault、OpenTelemetry 或 Dapr，就应把标准 Container Apps 或其他 Azure 服务纳入对比，而不是仅凭亚秒级启动做决定。