张云雷宝宝我一直觉得，微前端这玩意儿，很多团队是“为了微前端而微前端”，最后搞出来的东西比巨石应用还难维护。但如果你真遇到了组织协作和发布节奏上的硬瓶颈，那垂直微前端（Vertical Micro Frontend）确实是个值得认真考虑的架构方向。尤其是当这个架构碰上了 Cloudflare 这套全球边缘网络，很多以前在微前端体系里让人头疼的资源调度、隔离和分发问题，反而有了新的解法。
今天我就结合自己实际趟过的一条路，聊聊怎么在 Cloudflare 平台上把垂直微前端跑起来。这篇不是纯概念科普，更多是我在选型、搭建、部署和排坑过程中的一手记录。如果你是负责公司中台前端、核心业务前端，或者是想折腾一套真正能落地的多团队协作方案，这篇应该能给你不少参考。
1. 垂直微前端的底层逻辑与适用场景
1.1 垂直微前端和水平微前端的本质区别
先理清一个概念，很多人一聊微前端就是“把一个页面拆成 header、菜单、内容区”，按 UI 区域横向切分，这叫水平微前端。垂直微前端不一样，它是按“业务能力”和“用户旅程”来切的。比如一个电商后台，订单管理的整套流程，从列表查询、详情展示、售后处理到数据导出，全流程都归一个团队负责。这个团队交付的不只是一个页面组件，而是一条完整的垂直业务链路。
在 Cloudflare 的体系里，这种垂直切分天然契合 Workers 的部署模型。每个垂直业务域可以独立部署成单独的 Worker 或者 Pages 项目，互不干扰。这种模式下，团队自治不再是口号，而是真正落到了基础设施层面。以前我们做水平切分，组件版本升级要考虑关联影响，牵一发动全身；垂直切分后，订单团队只需要关注订单域自己的版本迭代，只要对外暴露的接口契约没变，内部随便重构。
1.2 什么情况下才应该选择垂直微前端
这里我不建议为了炫技或者追求架构时髦去上垂直微前端，尤其是中小团队或者业务边界模糊的项目。但这几类情况就很适合：
- 多团队开发同一体系，且团队间代码仓库完全隔离，只有接口层面的协作。比如平台型公司里，交易、营销、风控各自为战，协同仅限于联调。
- 业务模块的生命周期差异巨大，有的模块每天发版几次，有的模块半年才动一次。部署频率差异过大时，水平微前端会迫使用户每次加载全部模块代码，浪费性能。
- 需要精细化权限隔离和故障隔离的场景。比如某个垂直应用崩溃了，不能拖垮整个壳子。
从 Cloudflare 的角度看，垂直微前端可以充分利用它的边缘部署特性。不同业务模块可以按区域、按用户群体、按版本策略分别灰度，这个灵活性比传统的单机部署强太多。
1.3 Cloudflare 生态能带来哪些关键价值
Cloudflare 并不是一个简单的 CDN，它提供的 Workers、Pages、KV、Durable Objects 以及各种集成能力，组合起来相当于一个边缘应用平台。在垂直微前端架构里，Cloudflare 的价值体现在三个层面：
第一，静态资源分发天然快。每个子应用打包产物可以独立部署，Cloudflare 的全球网络自动做缓存和加速，用户不管在哪个区域，拿到最近节点的资源。
第二，运行时逻辑放在边缘。公共的容器壳子（Host Application）可以运行在 Worker 上，根据用户请求动态决定加载哪个垂直应用、走哪个版本，这个能力传统服务器需要自己搭建路由层，而 Cloudflare 原生支持。
第三，基础设施成本低且弹性好。不需要为每个子应用单独准备一套服务器集群，Workers 的按请求计费模式让中小团队也能用得起企业级的分发网络。
不过，也有个现实问题——Cloudflare 在国内的访问稳定性一般，如果你的主要用户在国内，可能需要考虑备选方案或者做一层自建回源。这个属于边界条件，后面会单独说。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 在 Cloudflare 上构建垂直微前端的整体架构方案
2.1 架构模式：边缘路由 + 静态托管 + 动态加载
我最终落地的架构方案可以概括成三层：边缘路由层、应用注册层、业务子应用层。
边缘路由层，运行在 Cloudflare Worker 上的一个入口脚本，负责接收所有前端请求。它会根据请求的路径前缀（比如 /order/* 走订单域，/marketing/* 走营销域），决定返回哪个子应用的 HTML 文档和资源路径。
应用注册层，是一份集中式的应用清单，存在 Cloudflare KV 里。这份清单记录着每个子应用的名称、版本号、资源入口地址、依赖共享策略。子应用发布新版本后，只需要更新 KV 里的记录，不用动路由代码。
业务子应用层，每个独立业务域构建后的静态资源，部署到 Cloudflare Pages 或者 Worker Static Assets。子应用之间完全隔离，构建部署互不依赖。
整体数据流大概是这样的：用户浏览器发起请求 → Cloudflare CDN 边缘节点拦截 → 执行边缘路由 Worker → 查询 KV 中当前版本清单 → 返回对应子应用的 HTML 和静态资源。
2.2 子应用之间怎么做运行时隔离
微前端绕不开的一个话题就是隔离。垂直微前端由于每个业务域本身就是整套页面，如果走 iframe 方案，隔离最彻底，但体验和通信成本都比较高；如果走 Web Components 或者 JavaScript 沙箱方案，体验好，但要自己处理样式冲突和全局变量污染。
我个人的选择是：容器壳子负责渲染框架级别的公共依赖（React、ReactDOM），子应用打包时把 React 标记为 external，运行时从全局变量 window.React 获取。这个方案也常被称为运行时共享依赖，能有效控制子应用的包体大小。
子应用内部的状态、路由、样式全部封装在自己的 Shadow DOM 或者 CSS 命名空间内。这块需要团队统一约定，从工程上强制。比如用 @scope/order 作为 class 前缀，或者在构建配置里通过 PostCSS 插件给所有类名自动加前缀。
还有一点，垂直微前端里子应用免不了跟容器通信，比如用户登录状态、菜单的展开收起。我建议不要直接用全局事件满天飞，而是通过容器注入的 hostApi 对象来调用，这样可管控可追踪。
2.3 依赖共享策略：什么该共享，什么该隔离
依赖共享是微前端里最容易翻车的点。共享太多，子应用之间耦合太深；共享太少，每个子应用都打一份 React，体积爆炸。
我的经验性结论是：
- 运行时框架（React/Vue）值得共享，且建议固定大版本。共享框架能显著降低资源体积。前提是团队有升级纪律，不要你升 18 我还在 16。
- UI 组件库不一定共享。如果你的团队用的都是公司内部封装的组件库，统一版本后可以共享；如果各自引第三方库，老实打成自己的包。
- 工具函数库（lodash、dayjs）不建议共享，收益不明显，混乱风险大。
- 业务状态管理绝对隔离。子应用之间的状态不能放一个全局 store 里，否则边界瞬间模糊。
在 Cloudflare 的实现里，共享依赖的处理方式通常是在容器壳子的入口 HTML 里用 import map 或者手动 script 标签加载公共库，子应用构建时将这些库排除打包。
3. 核心实现细节：从静态托管到边缘路由搭建
3.1 创建基础设施：Pages 项目和 Worker 路由准备
我先假设你已经有一个 Cloudflare 账号，并且域名也托管在 Cloudflare。如果没有，先去把域名接入，这一步对后