PHP H5商城源码部署指南:从环境配置到支付短信与避坑实践 简介一套完整的PHP手机端H5商城系统源码内含前端页面与后端管理逻辑可应用于抖音小店、微信H5商城等轻量电商场景适合需要学习商城系统设计或进行二次开发的初中级开发者。其中亮点是附带了系统的后台设置教程覆盖网站配置、短信与支付接口对接、商品分类与商品管理、工单处理、订单管理、分站管理、提现审核等核心模块从基础信息维护到订单流程处理均有清晰指引能帮助使用者快速掌握商城运营的后台操作要点。压缩包共346个文件以PHP业务代码、JavaScript交互脚本、CSS样式以及GIF/PNG图片素材为主同时包含SQL数据库、备份文件与htaccess等配置文件整体仅13.64MB下载部署非常轻便。目录中还保留了常用前端库的备份文件以及批处理脚本和运行日志方便开发时调试、回滚与跟踪状态。目前已有158人学习适合作为电商项目从零搭建或功能完善的参考样板源码仅供学习交流使用请勿直接商用。1. 先看清这份H5商城源码它是成品快照不是开发框架做抖音小店、私域运营或者独立H5商城的朋友问得最多的问题就是有没有一套能直接用的手机商城源码。这份PHP H5商城源码就是奔着这个诉求去的——它是一套已经完整跑通的后台管理系统打包覆盖网站配置、短信、支付、商品、订单、工单、分站和提现九大模块前台是移动端H5页面拿到手之后解压、配库、改配置就能进后台管理商品和订单。它适合两类人一是需要快速搭一个H5商城做业务验证的运营者二是接单改造成品商城的技术人员。需要注意它不是一个让你从零写业务的开发框架而是一个现成的、已经在跑的系统。2. 拆解后台九大模块从网站配置到提现管理的业务闭环2.1 从文件列表看这套系统的真实骨架先看压缩包里到底有什么。从项目的文件列表来看里面有jquery.js.bak、layui.css.bak、layer.css.bak、element.js.bak这四个带.bak后缀的备份文件以及bui.css、iconfont.css、style.css、base.css、Mao.min.css这几个前端样式文件。文件结构其实已经透露出两个关键信息。第一这是一套基于 layui 后台框架 原生H5前端的系统后台的表格、弹窗、表单验证大概率都依赖 layui 和 layer 的组件能力。第二.bak文件是旧版本文件的备份说明这套源码是从一个已经部署运行的站点上直接打包下来的而不是Git仓库里克隆出来的干净工程。这个判断对后续部署很重要——你解压之后第一件事不是直接访问而是要把.bak文件处理掉否则某些配置不当的服务器会把.bak文件也当可执行脚本解析引发样式错乱或者报错。前端文件里Mao.min.css这种压缩过的样式文件值得注意它把大部分页面样式都压缩到一行里了。如果你之后要改页面风格不要直接去改Mao.min.css那会让你找半天找不到修改点正确做法是新建一个custom.css在页面尾部引入覆盖。这是H5商城二次开发时最省力的姿势。2.2 九大后台模块各自管什么这套系统的后台管理逻辑是围绕运营一个商城这个目标来设计的九个模块基本覆盖了一个交易闭环。模块配置入口核心字段网站配置系统设置-网站配置商城名称、LOGO、ICP备案号、SEO关键词短信配置系统设置-短信配置短信服务商、AccessKey、签名、模板CODE支付接口系统设置-支付配置微信支付商户号、API密钥、回调地址商品分类商品-分类管理分类名称、上级分类、排序值、图标商品管理商品-商品列表商品名、价格、库存、SKU规格、主图工单管理售后-工单列表工单号、用户、类型、状态、回复记录订单管理订单-订单列表订单号、金额、支付状态、发货状态分站管理系统-分站管理分站名称、管理员账号、权限范围提现管理财务-提现审核用户、金额、收款账号、状态这九个模块里真正决定系统能不能跑起来的是前三个——网站配置、短信配置、支付配置。商品和订单是日常运营天天要用的工单和提现是售后和资金相关的补充。分站管理的存在说明这套源码支持多区域独立运营的玩法但如果你只有单一业务可以跳过分站配置不影响主流程。2.3 分站管理和提现管理的实际用法分站管理这块容易被忽略但它其实是这套源码的一个特色功能。它的设计思路是总站创建分站给每个分站分配管理员账号分站管理员只能管理自己区域内的商品和订单。实际配置时你需要在分站管理里先建分站再给分站绑定管理员最后给该管理员分配商品分类的权限范围。如果你用不到多区域代理模式这个模块可以不碰。提现管理涉及资金比分站要谨慎得多。用户在前台申请提现之后后台提现管理里会生成待审核记录你需要核对用户填写的收款账号、提现金额是否在可提现余额范围内确认无误后打款然后在后台把状态改为已打款。这套流程里最容易出问题的是用户提现后改收款账号所以养成审核时截图存档的习惯很有必要后面有纠纷时这就是凭证。3. 部署记录从解压到伪静态一步步把系统跑起来3.1 环境准备Nginx PHP 7.0 MySQL 5.6 是约定摘要里写得很清楚测试环境是 Nginx PHP 7.0 MySQL 5.6。这套组合是很多老一批PHP商城系统的标准配置但放到今天有坑——新版宝塔面板默认装的是 PHP 7.4 甚至 8.0直接用 PHP 7.4 跑这套源码极大概率白屏。我先说结论不要试图在 PHP 8.0 上碰运气老老实实装 PHP 7.0。原因有两点一是这不系统的加密解密逻辑可能依赖mcrypt扩展而mcrypt在 PHP 7.2 就被移除了二是老代码里的each()、create_function()这类函数在 PHP 8.0 里已经直接报 Fatal error改起来工作量不小且容易引入新问题。PHP 7.0 在宝塔面板的安装方式如下装完记得确认扩展里勾选了openssl、pdo_mysql、fileinfo# 宝塔面板安装PHP 7.0的命令入口 curl -sSO http://download.bt.cn/install/install_panel.sh bash install_panel.sh # 安装完成后在面板左侧软件商店-PHP扩展中安装 # 需要启用的扩展openssl、pdo_mysql、fileinfo、curl、gdPHP 7.0 装好之后把网站的PHP版本切换到 7.0再继续往下走。3.2 解压、上传、建站三连下载下来的压缩包是 zip 格式在 Linux 服务器上解压时最容易翻车的是中文文件名乱码。Windows 下打出来的 zip 默认用 GBK 编码文件名Linux 解压默认 UTF-8乱码几乎必然。解决办法是加-O GBK参数# 先上传压缩包到 /www/wwwroot/ 目录再执行解压 unzip -O GBK H5商城源码.zip -d /www/wwwroot/h5_mall # 解压结束后确认关键目录是否存在 ls -la /www/wwwroot/h5_mall解压完成后在宝塔面板网站里添加站点域名绑定你自己的域名本地测试可以用 IP根目录指向/www/wwwroot/h5_mallPHP 版本选 7.0。这里有个细节如果源码是放在子目录里运行的比如http://domain.com/mall/那伪静态规则里的 rewrite 路径也要跟着改否则页面能打开但路由全部404。3.3 导入数据库并修改配置文件数据库是这套系统的命门。先建库再导入。压缩包里一般不会带.sql文件但后台代码里会连数据库你需要先找到配置文件看清楚它连的库名然后创建同名的空库再导入你有的 SQL 文件。先全局搜一下数据库配置# 搜出所有包含数据库连接配置的文件 grep -r DB_HOST\|DB_NAME\|dbname /www/wwwroot/h5_mall --include*.php | head -20通常这套系统的配置文件在/Application/Common/Conf/config.php或者/data/config.php。找到之后修改数据库连接信息// config.php 数据库配置段按你实际环境填写 return array( DB_TYPE mysql, DB_HOST 127.0.0.1, DB_NAME h5_mall_db, // 数据库名 DB_USER h5_mall_user, // 数据库用户 DB_PWD your_password, // 数据库密码 DB_PORT 3306, DB_PREFIX p_, // 表前缀一定要和SQL文件里的前缀一致 );改完之后测试数据库连接是否正常。如果你有 SQL 文件导入命令是mysql -uh5_mall_user -p h5_mall_db h5_mall.sql导入之后登录后台前先把站点目录权限处理掉否则后台上传图片、生成缓存全会失败。chown -R www:www /www/wwwroot/h5_mall chmod -R 755 /www/wwwroot/h5_mall chmod -R 777 /www/wwwroot/h5_mall/data # 缓存和上传目录需要写权限 chmod -R 777 /www/wwwroot/h5_mall/Uploads # 图片上传目录没有就创建一个注意如果你不确定data和Uploads目录的实际路径去看一眼根目录下的目录列表再改别把整个站点 777 了安全上划不来。3.4 伪静态配置不配好就会样式全丢这套系统默认是 ThinkPHP 系的 MVC 路由结构入口文件是根目录的index.php。如果你不做伪静态访问http://域名/index.php?s/Home/Index/index这种带参数的长链接也能跑但手机端H5页面的 CSS、JS 引用路径是通过路由生成的相对路径一旦 URL 格式不对bui.css、iconfont.css这些样式文件全部加载失败页面会裸奔得像 2004 年的网站。Nginx 环境下的标准伪静态规则如下location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s$1 last; break; } }这段规则的含义是当用户请求的文件在服务器上不存在时把请求重写到index.php并附带原始路径参数s由框架路由解析。$request_filename是 Nginx 内置变量表示文件实际路径-e判断是否存在不存在才重写。配好后在宝塔面板的伪静态里粘贴保存再访问首页测试。如果首页能开但内页404优先检查 rewrite 规则是否生效而不是去改代码。PHP 解析配置也顺手确认一下很多环境问题出在这location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; }配置完成后访问http://域名/index.php/Admin/Login/index应该能跳到后台登录页。后台入口一般不是/admin而是/index.php/Admin/Login/index或/admin.php具体看源码里的入口文件名。4. 配置三套核心支付、短信、商品参数一次到位4.1 支付接口配置微信支付从申请到回调支付是本系统最需要耐心的模块。老系统的支付配置界面通常长得比较朴素——填写参数、保存、完事但漏一个字段后面就收不到回调。以微信支付为例你需要的参数有微信商户号、商户API密钥32位字符串、AppID、AppSecret、证书路径如果走退款接口必须传证书、回调地址。回调地址是关键它必须是公网可访问的 URL而且不能带index.php后面的参数形如http://你的域名/index.php/Api/Notify/wechat。支付配置界面的写法大致如下// 后台支付配置提交后系统生成这样的配置数组 array( appid wx1234567890abcdef, // 公众号/小程序AppID mch_id 1234567890, // 微信支付商户号 key 你的32位API密钥, // 商户平台APIv2密钥 notify_url http://你的域名/index.php/Api/Notify/wechat, return_url http://你的域名/index.php/Home/Pay/return, )保存之后先不要急着真支付用微信支付测试号或者小额真实订单比如1分钱商品验一遍。如果支付成功后订单状态没变九成是回调地址不通或者签名验证失败。判断方法是打开回调地址看返回# 直接访问支付回调地址看返回是否包含 SUCCESS curl -X POST http://你的域名/index.php/Api/Notify/wechat正常返回是 XML 格式的SUCCESS如果返回FAIL说明签名校验不过去查商户密钥是否多复制了空格。回调地址在本地开发时基本没法调试需要用到内网穿透工具把本机服务暴露到公网或者直接把系统部署到云服务器上测。4.2 短信配置模板和签名是两大坑短信配置用于给用户发通知比如验证码、订单状态变更。以阿里云短信为例后台需要填写四个东西AccessKey ID、AccessKey Secret、签名名称、模板CODE。// 短信配置的核心参数 array( access_key LTAI5tXXXXXXXXXXXX, // 阿里云AccessKey ID access_secret 你的AccessKey Secret, // 阿里云AccessKey Secret sign_name 你的签名名称, // 必须在短信控制台审核通过 template_code SMS_12345678, // 模板CODE模板里要有${code}变量 )签名名称是最容易出错的如果你的签名还在审核中短信接口会报isv.SMS_SIGNATURE_ILLEGAL如果模板变量名不匹配报isv.TEMPLATE_MISSING_PARAMETERS。收到这两个错误码别去改源码先去短信控制台确认签名和模板状态。测试时建议在后台发短信入口输入真实手机号不要用那种虚拟号段有些服务商会拦虚拟号。4.3 商品与订单配置SKU和状态流转决定了运营效率商品管理里最需要注意的就是 SKU 设计。这套系统支持多规格商品添加商品时先选分类再填基础信息然后在规格区设置颜色、尺码这种维度组合每个组合对应一个价格和一份库存。常见错误是把规格直接写在商品详情描述里这样用户下单时无法选择具体规格订单到后台之后你根本不知道用户买的是哪个颜色。// 商品SKU的数据结构示例 array( spec array(颜色 黑色, 尺码 XL), price 199.00, stock 50, sku_no P20240601-BL-XL )订单状态流转建议用一张状态表把自己理顺状态码含义操作0待支付用户下单未支付可取消1待发货支付成功后台需发货2待收货已发货用户确认收货3已完成交易结束4已取消用户或后台取消很多售后的根源在于已支付订单在后台没有按时间排序所以进后台先配好默认排序字段按下单时间降序否则订单积累多了容易漏发。批量发货功能在这个系统里有但前提是导入的Excel列名跟系统模板一致列顺序错了会整批导入失败所以第一次用的时候先导三行测试数据跑一遍别一上来就导几千条。5. 避坑六个翻车现场与对应解法5.1 PHP 7.2 以上直接白屏现象部署完后台打开是一片空白什么都不显示。原因这套源码基于 PHP 5.6~7.0 编写里面用了mysql_*系列函数或者已废弃的each()在 PHP 7.2 以上直接 Fatal error。Apache 环境会显示让你摸不着头脑的 500Nginx 环境则表现为空白页。解决切换环境到 PHP 7.0同时开启错误日志确认是不是扩展缺失。用以下命令先看日志tail -f /www/wwwroot/h5_mall/runtime/Logs/$(date %y_%m)/$(date %d).log如果日志显示缺mcrypt去面板装mcrypt扩展如果显示某个函数不存在则要在代码里做兼容替换。5.2 .bak 文件被 PHP 解析导致报错现象访问后台时偶尔出现文件不存在或路径错误代码里也找不到问题。原因.bak文件如果和.php文件放在同目录PHP 在某些服务器配置下可能把xxx.php.bak当作备份脚本直接解析输出二进制内容干扰响应。解决解压后立刻清理掉所有.bak文件。做这一步还有个好处——如果这套源码是从已部署站点打包的.bak文件可能包含旧版本信息留着会在改代码时产生误导。清掉后重新扫描一遍目录确认没有*.bak残留在 web 根目录内。5.3 中文文件名和中文内容乱码现象解压后进入后台发现商品分类名、订单备注、用户昵称全部变成乱码。原因源码打包时 Windows 环境用 GBK 编码导入数据库时如果连接层没设置 UTF-8中文会变成???或者乱码。这种乱码属于入库即乱不是显示层的问题。解决在导入 SQL 之前先设置客户端编码或者修改数据库连接配置加上字符集字段# 导入 SQL 前设置客户端编码 mysql --default-character-setutf8 -uh5_mall_user -p h5_mall_db h5_mall.sql同时在配置文件里把数据库字符集参数补上DB_CHARSET utf8,改完这些之后老数据已经乱码的只能从原始包里找回备份重新导入所以刚开始部署不要急着在后台录入测试数据先确认中文正常再动手。5.4 支付成功但订单状态不更新现象用户微信里钱扣了但后台订单还是待支付。原因支付回调地址配置错误或者回调地址是内网地址微信服务器无法访问。另一个隐蔽原因是你保存配置时回调地址带了http://localhost这种本地地址。解决确保回调地址是公网 HTTPS 地址在微信商户平台-产品中心-开发配置里核对支付回调域名。然后用curl模拟 POST 请求到回调地址看日志里有没有收到微信的异步通知。如果日志显示收到了但验签失败检查 API 密钥是否和商户平台一致注意密钥里的横杠和空格容易被复制进去。5.5 短信验证码收不到现象用户注册时点了发送验证码页面提示发送成功但手机没收到。原因签名或模板未审核通过或者模板变量名不匹配。阿里云短信接口返回的成功只是受理成功实际发送结果要看SendSms接口的Code字段OK才是真成功。解决后台日志里通常有短信服务商的原始返回把Code复制到短信控制台文档查一下含义。最常见的是isv.SMS_SIGNATURE_ILLEGAL签名未审核和isv.SMS_TEMPLATE_ILLEGAL模板未审核。另外注意同一条短信在短时间内发送次数限制测试时反复点发送会被服务商限流一般一个号码一天收几十条短信的限额这个不属于代码问题。5.6 H5 页面在 iOS 上下载的文件全变成预览现象商城里有虚拟商品链接安卓上点击能正常下载iPhone 上点击直接打开预览没有下载。原因iOS 的 Safari 对 Content-Type 的处理逻辑和安卓不同application/octet-stream响应头在 iOS 上会被某些 WebView 直接丢给预览器尤其是 PDF、图片这类浏览器能解析的格式。解决这不是源码 bug不用改框架。给下载链接加一个跳转页点击后先用curl探测文件真实的Content-Disposition然后在跳转页加提示让用户长按链接选择下载。如果是自己的服务器在下发接口里强制设置响应头header(Content-Disposition: attachment; filenamefile.pdf); header(Content-Type: application/octet-stream);再配合后端权限校验基本能解决 iOS 上下载变成预览的问题。6. 上线前把核心链路走一遍一份能直接用的验证清单很多部署翻车不是因为某个环节不会配而是以为配好了但没验证。我从自己的经验里整理了一条验证链路每次部署这套系统都会强制走完走完再交差。验证链路从用户视角开始打开H5首页 → 搜索一个商品 → 点进详情 → 选规格加购物车 → 提交订单 → 模拟支付 → 后台看到订单 → 发货 → 用户确认收货 → 申请售后 → 后台处理工单 → 用户申请提现 → 后台审核通过。每一步都是上一环节的输入任何一环断了后面全白搭。序号验证项预期结果检查点1首页访问商城首页正常显示样式完整控制台无 CSS/JS 4042商品搜索能搜到已上架商品搜索关键词和分类一致3下单流程选规格、加购、提交订单成功库存扣减正确4支付回调支付成功订单变待发货回调日志有 SUCCESS 记录5短信通知下单后收到短信通知短信服务商日志 CodeOK6订单管理后台可发货、可导出导出Excel列完整7工单处理售后工单能回复、能关单状态流转正常8提现审核提现申请可审核、可打款用户余额扣减正确9数据备份后台能备份数据库备份文件可下载、可恢复完成这条链路之后再补两类测试一是多终端适配——iPhone、安卓、iPad各打开一次首页和结算页重点看 Safari 下的样式错乱和输入框聚焦问题二是并发下单——用两个账号同时买同一个库存只剩1件的商品看库存会不会超卖。库存扣减逻辑如果是支付减库存那么两个账号都下单但只有一个人能支付成功如果是下单减库存第二个下单的人应该提示库存不足。从那以后我每接到一次 H5 商城部署或者源码改造的需求都会强制自己先把这条链路完完整整走一遍再交付而不是配好后台就收工。走完这几步基本就是最后一遍后面出问题的概率会小很多。希望帮到你。本文还有配套的精品资源点击获取