科技资讯
Azure Container Apps Express 转为正式可用，容易被读成一条普通的产品更新。但放进中国团队的排期表里，它更像一次「准入判定」的窗口：平台把环境预置这一步整个删掉，用一套带倾向性的默认值替代大部分配置项，你交出一个容器镜像、一个区域和必要参数，计算、入口与扩缩容由平台自己完成，CPU 按秒计费，空闲时缩容到零，环境预置本身不额外收费【1】。
换句话说，部署这件事变便宜了，但「能不能放进去」的判断变贵了。过去判断一套托管容器服务，看的是配置项够不够；现在要看的是默认值替你做主的那些地方，恰好是不是你的硬需求。
本文不复述发布说明，而是把它拆成可以排进下周日历的运营动作：四个兼职角色、三条并行验证线、一份准入清单，以及四条最容易返工的判断【3】。阅读顺序不必按天来，先看第一节的三问判定，再决定后面几天要不要做。
图：来源页面配图（已本地备份）。引用：【1】Azure Container Apps Express在新的通用沙箱层上正式发布 — https://www.infoq.cn/article/ChONW7EYk5Vuj0VF7AkZ?utm_source=rss&utm_medium=article
图：示意图（AI 生成，非原文截图；模型 nano-banana-2）。仅作阅读辅助，事实以正文与参考文献为准。
一、先做判定，再谈部署：六个问题决定去留
Express 暴露的是标准环境的一个精简子集，能力边界官方写得很直白：缩容至零、多副本、托管域名上的 HTTP 入口、环境变量、手动密钥、IP 限制、日志流式传输，以及基于 HTTP、CPU 或内存规则的自动扩缩容；自定义域名、可用区冗余、Key Vault 密钥引用、Easy Auth、OpenTelemetry、Dapr、jobs、工作负载配置文件、GPU 工作负载、多修订版本与流量切分、系统分配的管理身份均不在其中【1】。它也没有服务发现，应用之间只能通过各自的公网 URL 通信，且入口仅支持 HTTP【1】。
把上面这段话翻译成业务语言，就是下面这张判定表。任何一行命中「是」，该业务就留在标准环境，不进入本轮的 Express 试点。
| 判定项 | 命中后的处理 | 原因 |
|---|---|---|
| 对外站点必须使用自有域名 | 留标准环境 | 托管域名无法承载品牌与备案要求 |
| 需要可用区冗余 | 留标准环境 | 不在 Express 支持列表内 |
| 密钥必须托管在 Key Vault 或使用托管身份 | 留标准环境 | 仅支持环境变量与手动密钥 |
| 应用之间需要内网互调 | 谨慎评估 | 无服务发现，只能走公网 URL |
| 需要 GPU、Dapr、OTel、流量切分 | 留标准环境 | 官方明确建议改用标准环境 |
| 内部工具、轻量 API、Webhook 接收 | 可进试点 | 试运行两周后复核 |
另有两个准入条件常被忽略：Express 要求使用受 Microsoft Entra ID 支持的账户，个人 Microsoft 账户不可用；日常管理走专用界面而非 Azure 门户，Container Apps 与 Sandboxes 各有独立入口，但这些界面只是独立视图，并不取代门户【1】【2】。如果团队习惯用个人账号做技术验证，第一天的任务就不是部署，而是账号治理。
二、角色：四个兼职岗，各有一票
不建议为此成立专项组，但必须指定到人，并且每个人都有一个明确的判断权，而不是「配合一下」。
| 角色 | 判断权 | 本周唯一交付物 |
|---|---|---|
| 平台负责人 | 哪些业务进 Express、哪些回退 | 准入清单（含回退条件与责任人） |
| 交付工程师 | 技术可行性结论 | 可复现部署脚本 + 冷启动实测记录 |
| 成本与容量负责人 | 计费口径与基线 | 单应用成本基线表 |
| 安全与合规负责人 | 一票否决 | 风险项清单与替代方案 |
安全岗必须在周一就进场。原因很具体：没有服务发现意味着服务间调用要经过公网 URL，这会直接改变评审结论；而缺少 Key Vault 引用与系统分配管理身份，意味着密钥要么写在环境变量里、要么由应用层自行拉取，两种做法对应完全不同的合规叙事【1】。等到上线前一周才提出，返工成本最高。
三、一周日程：三条线并行，周五只做一个决定
周一｜45 分钟立项会，只产出清单
平台负责人主持，逐条过判定表，给每个在售或在研业务打上「进 / 不进 / 待定」三档，待定项必须写明需要谁在什么时候补齐信息。同日完成两件小事：确认账号体系可用 Entra ID 工作账户登录；确认管理界面的实际地址与访问方式，并告知团队这些界面不替代门户【1】【2】。会议不讨论技术细节，细节留给三条并行线。
周二｜A 线：用真实镜像跑通，重点测三个数
交付工程师选一个内部工具或轻量对外 API，必须用真实镜像而非示例镜像。要记录的不是「能跑起来」，而是三个数：空闲多久触发缩容到零、冷启动到首个成功响应的耗时、多副本扩容的实际触发行为。同时把部署过程中被默认值「替你做主」的配置项单独列出来，这些项才是后续要写进团队规范的内容。对跨境卖家场景，典型候选是订单同步接口、Webhook 接收端、内部运营看板的后端——它们对域名和冗余的要求低，但请求量波动大，正好用得上按秒计费与缩容至零【1】【3】。
周三｜B 线：先把三种载体分清，再谈智能体
这一天最容易混淆。jobs 面向运行至完成的任务与批处理；Sandboxes 提供的是可编程、带生命周期控制的隔离计算环境；Express 是位于两者之上的应用层【1】【2】。如果团队要做的是智能体工具调用、不可信代码执行，验证对象应是 Sandboxes 而不是 Express：它从预热资源池中预置以实现亚秒级启动，把每个工作负载放在硬件隔离的 microVM 边界内，支持突发扩展到大量并发沙箱，并能对内存与磁盘在内的完整状态做快照、支持挂起与恢复【1】。其顶层 ARM 资源是 Microsoft.App/SandboxGroups，可作为共享配置沙箱之间的管理边界，形态上类似 Container Apps 环境【1】。
同一天可以顺手验证一件事：既然沙箱支持挂起与状态快照，你们的业务是否真的需要在自己的代码里实现一套状态持久化？这个问题的答案会直接影响架构复杂度。
周四｜C 线：迁移演练与组织侧响应
已经在标准环境运行应用的团队，可走「归档与恢复」路径：归档现有环境，再恢复为 Express 环境，官方称该过程保留应用与环境配置、耗时约十五分钟量级，且不改变免费用量额度【1】。安排在周四的用意是拿一个非核心环境做整链演练，不在生产上试。
三件事同时要盯：迁移通知中包含一份退出表单，供需要额外审批或协调的组织使用，跨国团队要走内部审批链的，务必在通知窗口内响应；长期不活跃的环境（无运行中的应用或 jobs、近期无活动）可能被归档并转入休眠，对共享测试环境是资产，对没人认领的遗留环境则是隐患【1】。
周五｜复盘会：只做一个决定
成本负责人出基线表，把「按秒计费 + 空闲归零」与现有常驻实例做对比，但必须把冷启动带来的体验损失放在同一张表里看，否则结论会偏向乐观。安全负责人补齐风险项。会议输出只有一个决定：哪些业务下周扩大范围、哪些回退标准环境、哪些挂起等待能力补齐。三个桶之外不要有第四种结论。
四、四条最容易返工的判断
第一，把原型当长期形态。 官方文档把快速原型列为适用场景，并提到团队可以不做重新平台化直接在生产继续运行；但对需要自定义域名、可用区冗余或 Key Vault 支撑密钥的工作负载，这两种表述方向上是矛盾的【1】。原型可以留在 Express，生产要重新判定。
第二，出站子网一次性定死。 出站子网一旦设定便无法更改，网络规划必须在部署第一支应用之前完成【1】。对中国团队而言，这条尤其容易被忽略——很多团队的网络方案是在第一次安全评审之后才补的。
第三，可观测性缺口。 不支持 OpenTelemetry 意味着现有的大盘与告警链路要重新设计接法，日志流式传输只解决「看得到」，解决不了「留得久、查得快」【1】。对需要留存审计日志的行业，这一点应在周三前就有结论。
第四，选型对比别只看一家。 这一形态与 Google 在 Kubernetes Engine 上的组合思路相近：一边是快照能力，一边是面向不可信智能体代码的沙箱【1】。公开讨论中还有人提问：同类能力在托管 Kubernetes 服务中是否同样可得，因为部分团队留在 Kubernetes 正是因为 Container Apps 满足不了某些需求；这个问题目前没有正面答案，值得在选型会上留一条待办【2】。
五、验收清单：五条全部打勾才算这一周结束
- 准入清单已签核，每个「不进」的业务都写了回退原因与责任人；
- 至少一支真实应用跑通，且冷启动耗时与缩容触发时间有实测数字；
- 成本基线表完成，含冷启动损失的口径说明；
- 密钥与身份方案有结论，明确哪些业务必须回标准环境；
- 迁移与退出预案就位，包括退出表单的响应责任人与不活跃环境的清理名单。
六、编辑判断
Express 真正改变的是「起一个能对外服务的容器」的成本结构，它适合内部工具、面向客户的轻量接口，以及智能体平台的执行沙箱这一类负载【1】【2】。它不适合承载对域名、合规密钥、可用区冗余有硬要求的核心系统——这不是缺陷，而是产品划界的方式。
所以这一周的目标不该定成「上云成功」，而应定成「用五天换一份被验证过的准入清单」。清单在手，此后每一次新业务上线都只是一次查表动作。据公开报道，Express 在正式发布时已覆盖超过 40 个 Azure 区域，公测期间创建了数千个 Express 应用【1】——覆盖面已经不是问题，剩下的判断权在你们自己手里。
参考文献
【1】Azure Container Apps Express 在新的通用沙箱层上正式发布 — https://www.infoq.cn/article/ChONW7EYk5Vuj0VF7AkZ?utm_source=rss&utm_medium=article
【2】同上来源中关于 Sandboxes 原语定位、管理界面与社区讨论部分的二次归纳 — https://www.infoq.cn/article/ChONW7EYk5Vuj0VF7AkZ?utm_source=rss&utm_medium=article
【3】编辑注：本文的角色划分、三条并行验证线、判定表与验收清单，由古令乐编辑团队基于上述来源推演设计，非微软官方建议 — https://www.infoq.cn/article/ChONW7EYk5Vuj0VF7AkZ?utm_source=rss&utm_medium=article
