结账扩展的限制清单：哪些事在结账页永远做不了

发生了什么#

Checkout UI Extensions 让开发者能在结账页插入自定义内容，但它运行在受控沙箱里：不能直接操作 DOM、外部请求受域名白名单限制、不能修改支付与订单创建的核心流程。很多需求在提案阶段看起来可行，做到一半才发现撞墙。

关键细节#

• 运行在沙箱环境，禁止直接操作页面 DOM
• 网络请求需预先声明允许的域名
• 只能使用官方提供的组件，不能引入任意 UI 库
• 不能改变支付流程与订单创建的核心逻辑
• 有执行时间与体积限制
• 组件库固定，不能引入任意前端框架
• 网络请求需声明域名白名单

对商家与开发者的影响#

这意味着「在结账页做一个复杂的地址联想」这类需求，只能通过官方组件与允许的接口实现，不能自己写一套。方案评审时先对照能力清单，能省掉大量返工。

真正需要改支付流程的需求（比如自定义分期逻辑），应该走 Functions 或支付应用，而不是结账 UI 扩展。

方案评审阶段就该对照限制清单：很多「在结账页做个 XX」的需求，实际上只能在订单完成后或账户页实现。

建议动作#

1. 提案前先对照官方组件清单，确认能实现
2. 外部接口提前配好域名白名单
3. 把「改支付流程」类需求转到 Functions 方案