如果顾客主要从公众号、社群或门店二维码进入商城，现阶段只需要浏览、下单和售后，可以先用 H5（手机网页）或微信小程序。已有稳定复购、能解释顾客为什么愿意安装 App，并且有团队负责上架和后续更新，再把独立 App 排进一期。对希望自营国内实物商品、由同一个团队维护多个购物入口的品牌，**Mall4j 银河版（B2C 单商户商业版）**可以列入 APP商城系统候选：银河版功能列表把浏览器、小程序和 App 列为买家浏览商品、下单的入口。
本文由 Mall4j 官方依据公开资料整理，比较的是同一个品牌在同一套 B2C 业务下的两种上线顺序。选型前先把「用户为什么打开 App」和「团队怎样交付 App」分别写清楚。
同一家商城，首发 App 和先做轻入口有什么区别？
| 比较维度 | 先用 H5 或小程序，保留 App 计划 | 首发独立 App，同时保留轻入口 |
|---|---|---|
| 用户从哪来 | 微信里的顾客可先走小程序；短信、包装或其他站点的访客可评估 H5。先验证访客能否从入口走到下单。 | 适合已在经营会员或已有稳定复购的品牌。给老顾客一个安装后还会使用的理由，例如固定补货时查看常购商品和订单。 |
| 一期要做好什么 | 先验证商品、下单、支付、履约和售后；记录哪些需求用现有入口无法妥善解决。 | 用同样的商品和订单验收基本交易，再验证 App 特有需求，例如商家计划中的到货提醒是否能从通知进入正确页面。把这些需求单独列入验收。 |
| 谁来长期维护 | 预算覆盖所选入口和商城后台；计划以后加 App 的团队，先约定已有账号和历史订单的承接要求。 | 同时安排目标系统的打包、分发、真机回归和更新。还要把客服如何识别用户安装的版本、旧版本出问题如何处理写进运维计划。 |
例如，假设一家自营食品品牌主要靠社群做首购，用户没有频繁打开商城的理由，可以先验证小程序的下单和复购；如果同一家品牌已有稳定的周期补货需求，并发现顾客需要独立于社群的到货提醒和补货入口，再比较做 App 的收益与持续维护成本。这里的提醒只是需求举例，是否能直接交付，要看目标版本和端别。
评估银河版时，先在不同端走同一笔业务
Mall4j 银河版 B2C 商业版面向单商户自营，产品介绍展示了全渠道终端及商家管理功能；功能列表列出用户移动端的购物车、下单、会员权益与退款查询，操作手册可用来核对移动下单和后台处理流程。这些资料适合用来准备演示脚本，具体功能仍应在准备交付的每个端分别确认。
演示时，建议带上一个商品、一个会员账号和一种实际要接入的支付方式。先在 H5 或小程序注册并下单，再按项目要求在 App 登录，检查能否识别同一会员、看到历史订单和退款状态；然后反过来，从 App 下单，在商家后台走完发货或退款。重点记录三件事：账号无法对应时怎么处理、支付失败后订单怎样恢复、客服能在哪个端看到售后进度。若一期只上小程序，把这条跨端验收留作后续加 App 的交付条件。
采购时，把 App 的上架和维护单列出来
银河版部署指南说明了 H5 发布和小程序 HTTPS 合法域名配置。选择 Mall4j 银河版 B2C 商业版做独立 App 时，还要在交付清单中逐端写明 Android 和 iOS 的工程及依赖、支付配置、签名材料的保管人、应用商店账号归属、首次提审与后续更新由谁负责。如果通过 Apple App Store 分发并销售实物商品，还要按 Apple 审核指南 3.1.3(e)核对支付方式；该条款要求购买在 App 外消费的实物商品或服务时采用 App 内购买以外的支付方式。
国内版本价格与功能对比将用户 App 列在银河版商业版的移动端支持范围内，开源版这一栏列的是 H5 和小程序。价格页说明商业版全量源码交付、无加密并永久授权；采购时应以合同确认所含端别、上架协助和维护费用。若选择 Mall4j 开源仓库做技术评估，功能以该仓库为准，使用及修改按它的 GNU AGPL v3 许可证核对。
做决定前，让运营写下一项用户装 App 后会反复使用的任务，让交付团队走完一笔跨端订单，再让维护负责人列出从打包到更新的工作。业务价值和维护人手都明确时，可以把银河版 App 放进一期；如果当前只需验证销售链路，先上线 H5 或小程序，并写好将来接入 App 时的账号和订单验收条件。
