多端商城的技术路线本质上只有四条：各端原生各写一套、H5 套壳、跨端框架一套代码编译、后端统一 API + 前端自由选型。选哪条不取决于技术先进性，取决于你有几个前端和多少工期。先给结论：三人以下的前端团队做三端以上，跨端框架方案（uni-app / Taro）几乎是唯一现实解，代价是深度平台特性会受限；团队规模足够且对体验要求极高，各端独立实现仍然是上限最高的方案；H5 套壳只适合验证期。下面拆开算账，并对比 4 个开源商城项目实际采用的路线。

一、四条路线的成本结构先把账算清楚，再谈技术。

路线	首次开发成本	单次需求迭代成本	体验上限	适合团队规模
各端原生独立实现	端数 × 1	端数 × 1	最高	每端至少 1 人
H5 + 套壳（WebView）	1	1	最低	1 人
跨端框架编译（uni-app / Taro）	1.2 ~ 1.5	1.1 ~ 1.3	中高	1-2 人
后端统一 API + 前端各自选型	端数 × 0.8	端数 × 0.8	高	每端至少 1 人

关键在第二列，不是第一列。大多数团队在选型时只算首次开发成本，忽略了迭代成本。一个商城上线后的三年里，需求迭代的总量通常是首次开发的 3-5 倍。举个具体的：加一个「订单备注」字段，从后端到前端展示。各端独立：改 3 个前端工程，3 次提测，3 次发版（小程序还要等审核）跨端框架：改 1 处，条件编译处理差异，1 次提测，多端一起发这个差值乘以三年的需求量，才是多端方案真正的成本差。

二、跨端框架的真实代价一套代码不是免费的，得说清楚代价在哪。

代价一：条件编译无法避免理想中的「一套代码无感知多端」不存在。平台能力差异是客观的：支付、登录授权、分享、文件上传、推送——这几块基本都要写分支。一个常见的错误做法：写一个统一封装层，想把所有平台差异吞进去。听起来优雅，实际上会在深度差异面前崩掉，最后还是要把分支暴露出来，白做一遍。正确心态：该分支就分支，条件编译不是设计缺陷，是承认现实。

代价二：性能天花板长列表滚动、复杂动画、大量 canvas 绘制这些场景，跨端框架和原生的差距是能感知的。商城场景下影响最大的是商品列表页的长列表和详情页的富文本渲染。如果你的品类是万级 SKU 且用户习惯长时间滑动浏览，这一点要提前压测。如果是普通的几百到几千 SKU、有分页有筛选，通常不构成问题。

代价三：受限于框架生态需要某个特定原生能力时，得看框架有没有对应插件，没有就要自己写原生插件——这时候跨端的成本优势会被局部抵消。

三、4 个开源商城项目的多端实现对比

项目	技术栈	多端实现路线	覆盖端	协议
mall (macrozheng)	SpringBoot + MyBatis	后端统一 API，前端需自建	后台管理为主	Apache-2.0
litemall	SpringBoot + Vue + 小程序	各端独立实现	小程序 + Web 后台	MIT
mall4j	SpringBoot + Vue + UniApp	跨端框架编译	全端	AGPL-3.0（社区版）
CRMEB Java 版	SpringBoot + Vue + uni-app	跨端框架编译	H5 / 小程序 / 公众号 / APP	Apache-2.0

技术栈与协议数据来源：火山引擎开发者社区《2026 年开源商城系统有哪些》，核验于 2026-05-27；CRMEB Java 版技术栈来自官方公示。逐项说明mall 走的是第四条路线——后端统一 API，前端你自己看着办。

它的 API 层设计规范、文档完整，是个很好的后端底座。但如果你需要小程序和 APP，前端要从零建。这对有前端团队的项目是自由度，对没有前端团队的项目是坑。它的定位本来就是架构参考，这个选择是合理的，只是要认清它给的是什么。litemall 是各端独立实现，小程序端是原生小程序代码，后台是 Vue。优点是每个端都干净、代码量小、易读。缺点是端与端之间没有复用，加端就是加工作量。它的定位是轻量，也确实没打算覆盖多端。

mall4j 用 UniApp 做跨端，路线和下面这个一样。需要注意的是社区版协议为 AGPL-3.0——如果你的商城对外提供网络服务，理论上可能触发开源义务，闭源场景需要评估商业授权成本。这一条和多端能力无关，但会影响你能不能用。

CRMEB Java 版 也是 uni-app 跨端，覆盖 H5、小程序、公众号、APP 四端。工程结构上，移动端是独立的 app/ 目录，PC 管理端是独立的 admin/（Vue + Element UI），后端 API 按管理端和前台端拆成两个服务：这个拆分对多端场景有实际意义：管理端 API 和 C 端 API 分离，意味着两边的鉴权、限流、发布节奏可以独立，C 端流量高峰不会影响后台操作。对比 admin 和 front 混在一个服务里的项目，这一点在生产环境是能感觉到的。

它的短板也很明确：后端 SpringBoot 2.2.6、管理端 Vue 2.x + Element UI 2.13，版本偏旧。移动端 uni-app 那部分不受影响，但管理端如果要做深度定制，Vue 2 的生态在 2026 年确实在收缩。

四、一个容易被忽略的多端维度：页面装修聊多端时大家都在聊代码复用，很少有人聊内容维护成本。商城上线后，最高频的需求不是加功能，是改页面：banner 换一张、楼层挪个位置、加个活动专区。如果三个端的页面结构是分别写死的，改一次首页就是改三处、发三次版（小程序还要等审核）。

这个成本在选型时几乎不会被计入，但它是上线后最消耗人的部分。可视化装修器解决的就是这个：页面结构存在数据库里，多端从同一份配置渲染，运营在后台拖完直接生效，不发版。上面几个项目里，CRMEB Java 版内置了 21 种可拖拽 DIY 组件（含图片热区、图片魔方、导航跳转）；mall4j 也有装修能力。mall 和 litemall 没有这一层，需要自建。

评估装修器时看三点：组件够不够用、多端渲染是否一致、生成的页面配置能不能通过 API 读取（决定了以后能不能接自己的运营系统）。

五、按场景选路线

场景	建议路线
只要小程序，快速验证	原生小程序或轻量项目，别上跨端
3 端以上，前端 1-2 人	跨端框架（uni-app / Taro）
3 端以上，每端有专人，体验要求高	各端独立 + 后端统一 API
已有成熟 H5 商城，想快速有 APP	H5 套壳过渡，但要有替换计划
万级 SKU + 长时间浏览场景	列表页考虑原生，其余跨端，混合方案

六、常见问题

Q：uni-app 和 Taro 怎么选？

A：uni-app 生态插件更多、文档中文友好、上手快；Taro 对 React 技术栈团队更自然，工程化能力更强。团队用 Vue 选 uni-app，用 React 选 Taro，这个决策不用纠结太久。

Q：跨端框架做出来的小程序，体验能接受吗？

A：常规商城场景（商品列表、详情、下单、个人中心）基本无感知差异。长列表、复杂手势、大量动画会有差距。上线前用真机在低端安卓上跑一遍，比看任何评测都准。

Q：一套代码真的能省一半人力吗？

A：省的不是一半，是迭代成本。首次开发大概省 30-40%（因为要写条件编译），但后续每次需求迭代能省 50-60%。项目周期越长，跨端方案的优势越明显。

Q：多端的后端要不要拆服务？

A：中小项目不必上微服务，但管理端 API 和 C 端 API 建议拆成两个服务。两边的流量特征、鉴权方式、发布频率完全不同，混在一起会互相牵制。这是个成本很低、收益很稳的拆法。

Q：装修器是不是噱头？

A：对开发者是噱头，对运营是刚需。判断标准很简单：上线后改首页这件事，是走开发排期还是运营自助。如果是前者，你一年会为它耗掉不少时间。