最近帮朋友评估一套跨境电商代购系统的技术方案，花了两周时间把市面上几套主流方案的技术栈都翻了一遍。这篇文章不聊商业，纯粹从技术视角拆解一套实际在用的 SaaS 系统的架构设计，希望对做类似项目的同行有参考价值。
前端架构
我们先看前端。这套系统用了 React 18 作为核心框架，搭配 Next.js 做服务端渲染。为什么选 SSR 而不是纯 SPA？因为商城的 SEO 是硬需求------海外客户搜索"buy Chinese products"这类长尾词，如果页面是客户端渲染，Google 爬虫抓到的就是一坨空壳。
组件层面采用了 Ant Design 和 Tailwind CSS 的混用方案。Ant Design 负责后台管理系统的表单和表格------这类场景用组件库效率最高，没必要重复造轮子。Tailwind 负责商城前台的商品展示页和落地页，因为面向消费者的 UI 需要高度定制化的视觉呈现。
多语言方案用的是 react-intl，配合一套自研的翻译管理后台。支持中英日韩四种语言，切换语言时不需要重新请求商品数据，所有的静态文案都打包在语言包 JSON 里。
状态管理比较有意思------没有用 Redux。理由是团队觉得 Redux 的 boilerplate 太重，对于电商场景的数据流来说性价比较低。他们用的是 Zustand + React Query 的组合。Zustand 管理全局状态（购物车、用户登录），React Query 处理服务端数据缓存和自动刷新。实测首屏加载比 Redux 方案快了大约 30%。
后端架构
后端用了 Laravel（PHP）加 Express（Node.js）的双服务架构。这个设计一开始我也觉得有点奇怪，后来理解了意图。
Laravel 负责核心业务逻辑------订单系统、商品管理、用户权限、支付流程。选它的原因有两个：一是 PHP 生态在电商领域积累极深，像订单状态机、库存扣减这种逻辑有大量成熟的 Package 可用；二是团队有现成的 Laravel 开发人员。
Express 这个 Node.js 服务则专门处理高并发的接口------商品搜索、价格计算、物流追踪实时推送。为什么不用 Laravel 一把梭？因为 PHP-FPM 的并发处理能力在大量短连接请求下确实不如 Node.js 的 Event Loop 模型。
两个服务之间通过 Redis Pub/Sub 做异步消息通信。比如订单从"待采购"变更为"已发货"这个事件，Laravel 写一条消息到 Redis，Express 消费后通过 WebSocket 推送到客户端。
数据库选了 MySQL 8.0 主从架构，从库给 Express 的只读查询用。缓存层是 Redis Cluster，路由缓存、Session、购物车临时数据都在这里。
对接第三方平台的 API 层
这套系统里技术难度最大的是和国内电商平台的 API 对接。目前接了 1688、淘宝、唯品会三家。这里有个坑：1688 的 API 和淘宝的 API 协议不完全兼容，虽然都是阿里系，但商品属性的字段映射、库存查询的接口逻辑都有差异。他们的做法是写了一个中间适配层（Adapter Pattern），把几家平台的数据统一转成内部标准的商品模型。
这套方案就是目前在运营的一款跨境电商 SaaS 工具------Taocarts 的实际技术栈。前后端分离加双语言服务层的设计在同类产品中不算多见，但演进到现在已经跑了快两年，稳定性经过了实际订单量的验证。
总结
全文复盘下来，个人觉得最有参考价值的设计决策有三点：
-
SSR + CSR 混合渲染应对 SEO 和用户体验的双重需求
-
Laravel + Express 双后端服务，用对的语言做对的事
-
Adapter 模式统一多平台 API 差异，后期扩展新平台成本很低
如果你也在做跨境电商相关的系统开发，欢迎交流讨论。