SHOPLINE 跨境电商

背景

跨境电商前台的特点是页面形态多、变化快、参与团队多：营销页、商品页、结算流程由不同团队维护，但共享同一套商品、价格、多语言与币种能力。单体应用在这里会退化成「谁都不敢改」的状态，因此平台采用 Layout Engine 架构，把页面拆成可独立发布的模块联邦子应用。

我的角色

• 在客户域多个微前端子应用中承担主要开发，负责商品与营销模块。
• 设计并优化子应用之间的通信机制，支撑多团队并行协作。
• 开发 C 端 SSR 渲染插件，让 CSR 与 SSR 在同一架构下共存。
• 落地多语言方案，兼顾运行时切换与首屏性能。

关键设计

1. 子应用之间不直接调用，只通过契约通信

微前端最常见的失败模式是「共享了一个全局 store」。我们改为事件契约：

type ShellEvent =
  | { type: 'cart:add'; skuId: string; quantity: number }
  | { type: 'currency:change'; currency: 'USD' | 'EUR' | 'GBP' }
  | { type: 'locale:change'; locale: string };

export function emit(event: ShellEvent) {
  window.dispatchEvent(new CustomEvent('shell:event', { detail: event }));
}

壳层负责转发与版本兼容，子应用只依赖事件结构而不是彼此的运行时。任一子应用升级，只需保证发出的事件结构不变，联调成本从「拉齐所有团队」降到「对齐一个类型」。

2. CSR 与 SSR 共存，而不是二选一

营销页需要 SEO 与首屏速度，走 SSR；后台配置页需要交互与状态，走 CSR。Layout Engine 允许按路由声明渲染模式：

• SSR 页面由 Node 渲染引擎输出 HTML，使用 Handlebars 模板保证渲染性能与可维护性。
• 客户端 hydration 后接管交互，避免整页重渲染。
• 共享的数据请求层按环境切换 baseURL 与缓存策略，模板与组件不感知差异。

3. 多语言：编译期与运行时分工

• 静态文案在构建时按语言拆包，首屏只加载当前语言。
• 动态文案（商品标题、营销规则）由接口返回，运行时插值。
• 语言与币种切换通过事件广播，避免每个子应用各自监听路由做重复请求。

结果

• 多个子应用可独立构建与发布，联调与回归范围收敛到单个模块。
• SSR 营销页首屏与 SEO 指标明显改善，CSR 页面保持原有交互能力。
• 多语言方案在运行时切换时无需整页刷新。

复盘

微前端解决的从来不是技术问题，而是组织问题：让团队的发布节奏互不阻塞。真正让架构稳定的是那份事件契约与版本策略——没有契约的微前端，只是把单体拆成了若干个互相耦合的小单体。