PHP H5商城源码实战：支付接入与虚拟商品自动发货解析

做PHP商城有些年头了，手头存了不少源码，也帮人排查过各种乱七八糟的二开问题。今天翻出来一套比较完整的、支持实物加虚拟商品同时销售的H5商城源码，全新UI风格，支付端支持易支付和码支付这两种当前中小型项目里用得最多的渠道。这套东西不是那种烂大街的thinkphp改个皮就拿出来卖的教学版，而是可以直接部署、拿着做二次开发底子的项目。

先说它适合谁：想快速搭建一个移动端商城、又不想被SaaS平台抽成的个人创业者，或者手里有虚拟货源（卡密、网课、授权码之类）想做自动发货的，再或者接单做商城二开的开发者，都可以拿它当起点。H5的形态决定了它在微信内打开、扫码打开都顺畅，不需要走应用商店审核，这对很多急着上线试水的业务来说非常关键。我花了大概两个晚上把整套东西从头到尾理顺了，包括支付回调、虚拟商品自动发货的处理逻辑、以及一些容易踩的坑，这篇文章就把我梳理和实测的过程写出来，尽量把关键的点都说透。

1. 整体设计与功能拆解：这套源码是怎么定位的

1.1 为什么是“H5 + PHP”的组合

现在做电商，首先要想清楚入口在哪里。原生App开发周期长、上架审核烦、还要维护两个端，对中小项目并不友好；小程序虽然流量好，但类目审核、资质要求卡得严，很多人第一步就被挡在门外。相比之下，H5商城是个非常务实的选择：一套代码，链接扔哪都能开，微信里、浏览器里、二维码扫出来，通通一个样。用户不需要下载安装，转化路径短，特别适合做活动页、朋友圈推广、短视频挂载链接这类“即点即买”的场景。

这套源码采用PHP作为服务端语言，本质上还是看重它的生态成熟和部署成本低。市面上主流的虚拟主机、vps都能跑，不需要像Java那样折腾一堆环境变量和容器配置。而且PHP在处理电商这种“请求-响应”模型上有天然优势，配合MySQL做数据存储，一个标准的LNMP环境就能把整套商城撑起来。我见过不少开发者一上来就要上Swoole、上Redis集群，其实对于日单量几百上千的小型商城，传统PHP-FPM架构完全够用，别为了技术炫技而过度设计。

1.2 从“全新UI”判断这套源码的界面思路

标题里特意强调了“全新UI”，这也是我把这套源码挑出来细看的原因之一。很多老牌PHP商城系统（比如ecshop二次开发的各类版本）后台功能的确强大，但前端界面还停留在五六年前的水平，圆角生硬、布局拥挤、字体错位，用户一进来就感觉不靠谱。这套源码的UI倒是挣脱了老PHP商城的通病，整体走的简洁卡片风：首页轮播、宫格导航、商品瀑布流、底部Tab栏，都是现在用户熟悉的移动端交互模式。

前端这块采用原生HTML5+CSS3+JavaScript实现，没有强行上Vue或React。对于商城这种需要SEO和快速加载的页面，原生H5反而有优势——首屏渲染快，兼容性好，出现问题也容易排查。而且源码里保留了H5页面和部分PC端模板共存的结构，意味着同一套后台数据，既能支撑手机端浏览下单，又能在电脑上做订单管理，这对实际操作来说很重要——不是所有用户都习惯在手机上处理退款和发货。

1.3 实物与虚拟商品混合模式带来的设计差异

这可能是这套源码区别于一般单品类商城的重要点。实物商品走的是“下单→支付→商家发货→用户确认收货”的流程，而虚拟商品则是“下单→支付→系统自动发卡/自动开通”，两者在订单状态机、库存扣减方式、发货逻辑上都完全不同。

源码把商品类型设计成独立的字段，核心在于订单处理层的分支判断：实物订单创建后进入待发货状态，后台管理员可以手动填写物流单号；虚拟订单则是在支付回调成功的瞬间触发发货逻辑，从卡密库中取出一条未使用的卡密，绑定到订单上，同时把卡密信息明文展示给用户，并发送短信或邮件通知。这里有一个关键细节——不是所有商品都做了自动发货，源码支持为虚拟商品配置手动发货，这是为了方便卖定制服务的商家（比如远程安装、定制开发这类需要人工介入的服务），这种灵活度在实际运营中很实用。

2. 核心业务模块与代码结构盘点

2.1 商品、订单、用户三大核心表的关系

拿到源码第一件事不是看页面长什么样，而是先把数据库表结构过一遍。这套源码的表不算多，但核心表之间的关系很清晰：

• 商品表（goods）存储基本信息，包括标题、缩略图、价格、库存、商品类型（实物/虚拟）、销量、排序权重等。虚拟商品会关联一个独立的卡密池表。
• 订单表（order）存储每一笔交易，字段涵盖订单号、用户ID、商品ID、实付金额、支付方式、订单状态、物流信息等。订单状态我特别关注了一下，它把“待支付、已支付、已发货、已完成、已关闭”全部用状态码表示，这个在后期对账时很有用，可以通过一条SQL就统计出各个状态的订单数量。
• 用户表（user）保存了用户的OpenID、昵称、头像、余额、积分等，其中余额字段是给后续做站内充值、分销提现留的口子。
• 额外还有一张配置表（config），系统名称、客服电话、运费模板、支付参数等全局设置都集中在里面。好处是改配置不用动代码，直接在后台保存即可。

表前缀在安装时可以自定义，这个设计虽然简单但很实用。我见过太多源码把表前缀写死，一旦跟其他系统对接，改起来牵扯一大堆SQL文件，简直是灾难。

2.2 虚拟商品卡密管理与自动发货逻辑

虚拟商品能否稳定运营，核心看卡