企业官网建设流程全解析

简介：DSmall多商户B2B2C开源商城系统v6.2.1源码包，面向需要搭建多商家入驻型电商平台的开发者、企业及高校毕业设计人群。系统完整覆盖商家入驻、商品管理、订单流转、支付对接、会员营销、物流追踪与销售数据分析等核心业务，既可快速部署用于实际项目，也可作为学习电商系统架构与二次开发的实例。包内共2000个文件，包括945个HTML页面模板、609个PHP业务逻辑文件、226个JavaScript交互脚本、81个CSS样式表，以及SQL数据库脚本、环境配置样例、说明文档等，压缩包约90.89MB，目录结构清晰，便于按模块查阅。目前已吸引337人学习下载，适合有PHP基础并希望深入研究B2B2C模式或完成毕业设计的读者使用。这版源码还包含银联证书与安装前必读文档，可帮助降低部署门槛，围绕平台进行定制化改造，完整体验从商户入驻到消费者购物的电商链路。

1. 拿 DSmall 源码之前：先搞懂 B2B2C 和单商户商城差在哪

别以为多商户商城就是单商户系统加一个“我要开店”按钮。DSmall 多商户 B2B2C 开源商城源码 v6.2.1 把平台、商户、会员拆成了三套独立的账号体系，平台既能自己卖货，也能让第三方商家入驻开店、各自管理商品和订单，最后由平台统一结算。它解决的是这样一类诉求：你想从自营卖货升级成行业平台，或者做区域电商、批发订货，让几十上百个商家进场卖货，而不是自己囤货压现金流。它适合有 PHP 基础、愿意自己拿源码部署和二次开发的团队，没有年费，数据全部在自己的服务器里。下面按我实际把这套源码跑上生产的顺序，从环境搭建、角色模型、结算配置一路讲到踩坑和二开验证。

2. 部署 DSmall v6.2.1：先读懂目录结构，再跑通最小环境

2.1 解压后先看这几个目录：平台端、商户端、会员端分别在哪

拿到 zip 包解压后，别急着传服务器，先花十分钟把根目录结构看一遍。DSmall 是典型的 ThinkPHP 5 工程，application目录放着全部业务代码，里面按admin、seller、member三个模块分开，分别对应平台后台、商户中心、前台会员中心；public是 Web 入口目录，index.php是商城前台入口，admin.php是平台后台入口；runtime目录是运行时缓存与日志；install里放着数据库初始化 SQL 和安装向导。

这个分层结构直接决定了你后面改代码时去哪儿找人：要改平台后台的审核逻辑，进application/admin/controller；要改商户发货流程，去application/seller/controller；前台会员的订单查询则找application/member/controller。很多人在 DSmall 里找一个功能找不到，就是因为没分清三端模块，在错误的模块里翻。v6.2.1 的“多商户”也不是评论里说的那种单店版，而是商户端独立成站，商户有自己的登录入口、店铺装修、商品和订单管理界面，这一点看目录结构比看功能清单更直观。

2.2 环境选型：为什么我建议 PHP 7.4 + MySQL 5.7

老项目配新环境最容易翻车。DSmall v6.2.1 基于 ThinkPHP 5.0 开发，PHP 版本建议选 7.1 到 7.4，不要直接上 PHP 8。TP5 对 PHP 8 的兼容性不好，启动后满屏 deprecation 警告，严重时直接白屏，这种问题在本地开发环境可能看不出来，上线后访问量一上来才暴露。数据库用 MySQL 5.7 最稳，8.0 也能跑，但连接字符集务必设成utf8mb4，否则中文和 emoji 会以各种奇怪姿势乱码。Web 服务器用 Nginx 必须配伪静态，Apache 则要确保mod_rewrite已开启，DSmall 包里自带的通常是 Apache 规则，Nginx 规则需要手写。

下面贴一套我部署 DSmall 时用的 Nginx 配置，直接按你的域名替换server_name即可：

server { listen 80; server_name yourdomain.com; root /var/www/dsmall/public; # 入口指到 public，别指到项目根目录 index index.php index.html; # ThinkPHP 5 pathinfo 兼容 location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?s=/$1 last; } } location ~ \.php$ { include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_pass 127.0.0.1:9000; } location ~ /\.(?!well-known).* { deny all; } }

这里三个参数值得说清楚：root指向public而不是项目根目录，是为了防止别人直接访问到application下的源码和配置；rewrite把不存在的路径全部交给index.php的s参数解析，商城前台、商户中心、会员中心都走这一个入口；fastcgi_param SCRIPT_FILENAME必须用$document_root拼接，否则 PHP 解析会报 “Primary script unknown”，这是新手最常见的 500 来源之一。

2.3 最小部署命令：从 zip 到登录后台

环境就绪后，按下面这套顺序操作，能少踩一半的坑。注意 zip 文件名里有空格和特殊字符，命令行必须用引号包住：

unzip "DSmall多商户B2B2C开源商城源码 v6.2.1.zip" -d /var/www/dsmall cd /var/www/dsmall chmod -R 777 runtime upload mysql -uroot -p -e "CREATE DATABASE dsmall DEFAULT CHARACTER SET utf8mb4;" mysql -uroot -p dsmall < install/dsmall.sql

第一行解压，文件名带空格所以加了引号；chmod给runtime和upload写权限，这两处没有写权限的表现很隐蔽：网页能开但图片传不上去、日志写不进去、缓存报错；建库时指定utf8mb4，避免后面存表情符号或特殊字符时插入失败；导入 SQL 用命令行而不是 phpMyAdmin，因为初始化 SQL 通常几百条表结构和数据，phpMyAdmin 容易执行超时中断，导到一半你还得清掉重来。

导入完成后，改application/database.php里的数据库配置：

// application/database.php 关键配置 return [ 'type' => 'mysql', 'hostname' => '127.0.0.1', 'database' => 'dsmall', 'username' => 'root', 'password' => 'you_password', 'prefix' => 'ds_', // 表前缀，与 SQL 文件保持一致 'charset' => 'utf8mb4', ];

prefix是表前缀，默认通常是ds_，如果你导入的 SQL 实际前缀不是这个，必须改一致，否则后台一打开全是“数据表不存在”的报错。改完配置访问http://你的域名/index.php，环境正常会跳到商城前台；后台入口是admin.php，登录后第一件事改掉默认密码，然后删掉或改名install目录，防止别人重新运行安装向导覆盖你的配置。

3. 平台、商户、会员三端如何协作：B2B2C 的账号模型与订单流转

3.1 三套账号体系：为什么不能只用一张 user 表

B2B2C 的“多商户”核心不是店铺数量，而是角色边界。DSmall 里账号分三套：平台管理员账号负责审核商户、配置佣金比例、处理投诉；商户账号绑定一个店铺，管理自己的商品、订单、运费模板和结算账户；会员账号是 C 端买家，只在前台买东西。三者各有独立的登录入口和会话隔离，相互之间的关联靠店铺表串起来，而不是混在一张 user 表里加个角色字段。

为什么不做成一张表？因为三端的功能菜单、登录方式、数据权限完全不一样：商户登录后看到的所有订单、商品、报表都是按shop_id过滤的；会员登录后看到的是自己的浏览、收藏、购买记录；平台管理员看到的则是全平台的汇总数据。硬塞进一张表，光菜单权限和登录态的逻辑就能把项目拖垮。这也是很多“单商户加插件”的方案做不了真 B2B2C 的原因——商户需要的是独立后台、独立库存、独立结算，不是用户表里多一个is_seller字段就完事。

这里有个二开时容易忽略的点：会员可以同时是某个店铺的商户，但两边账号是完全独立的，平台财务对账时也按店铺维度核算。你在写查询时，任何跨店操作都要先确定shop_id，不能直接拿会员 ID 去查订单表，否则数据会把两个身份混在一起。

3.2 商品发布与审核：平台审核开关和批发阶梯价

商户在商户中心发布商品，默认状态是待审核；平台后台在“商品审核”里通过之后，商品才在前台展示。这个流程可以在后台配置成免审核，适合以平台自营为主的场景，但对真正的多商户平台，保留审核是底线。否则商户商品违规、图片不合格、价格乱标，风险全部由你平台承担，出了事再下架就晚了。

DSmall 的商品支持实物、虚拟、批发三类。批发类可以配置阶梯价，比如 10 件以下按零售价，10 到 50 件按九折，50 件以上按八五折。这一点对做 B2B 订货场景特别有用，但很多人拿它当纯 B2C 用，批发能力完全浪费。日常排查待审核商品，我习惯直接用下面的 SQL：

SELECT s.shop_name, g.goods_name, g.goods_price, g.goods_state FROM ds_goods g LEFT JOIN ds_shop s ON g.shop_id = s.shop_id WHERE g.goods_state = 0 -- 0 待审核，1 已上架 ORDER BY g.create_time DESC;

注意goods_state在 DSmall 里是有状态集合的字段，除了 0 待审核、1 已上架，还有下架、违规强制下架等状态。具体状态值以你当前版本的数据库字典为准，二开时建议把状态定义成常量，而不是在代码里到处硬编码数字，后面改状态流会轻松很多。

3.3 订单状态机与结算：平台抽佣的钱怎么算出来

订单状态是整个商城最容易出 bug 的地方，多商户场景尤其如此。DSmall 的订单状态大致是“待付款到待发货，再到待收货，最后已完成”，中间还穿插退款申请、退款成功、平台介入。核心状态变化如下：

每次状态变更都应该记录操作日志，二开之后你会发现日志比代码更值钱。排订单问题第一步永远是翻状态变更记录，而不是盯着当前状态猜。

结算逻辑才是 B2B2C 和单商户系统的真正区别。会员付款后，钱先进平台账户，因为支付接口配置的是平台的商户号；订单完成后再按平台设置的佣金比例生成结算单，把货款扣除平台佣金后的余额结算给商户。v6.2.1 的常见做法是：订单进入已完成状态后出现在“待结算”列表，平台财务后台手动或定时批量结算。遇到“钱去哪了”的疑问，先查结算表而不是订单表，这是多商户对账的常识。

4. 把多商户真正跑起来：入驻、结算、运费与售后的关键参数

4.1 商户入驻申请与审核：开关、协议、短信缺一不可

平台后台开启“商户入驻”功能后，前台才会显示入驻申请入口。入驻流程一般包含：填写企业或个人资料、上传营业执照或身份证、勾选平台协议、提交等待审核。审核通过后，系统自动创建店铺记录和商户账号，并通过站内信或短信通知商家。这个环节有几个关键开关：入驻是否需要缴纳保证金、是否需要平台人工审核、短信通知是否真的能发出去。

实际运营中常见的错误是直接给商户开后门账号，跳过入驻流程。这样会导致店铺资料缺失、结算账户未绑定、后续佣金计算没有主体，财务对账的时候一团乱麻。我的建议是第一版就强制走完入驻流程，平台这边只负责审核，别为了省事手动建店铺。

入驻申请相关参数，在平台后台的“店铺-入驻设置”里通常能找到：

4.2 结算账户与分佣比例：把这几项在后台设对

平台佣金比例是多商户商城的命根子。DSmall 的部分版本支持按店铺分类设置差异化佣金，比如数码类抽 3%、服饰类抽 5%、虚拟商品抽 8%；部分版本是全局一个比例。强烈建议用分类差异化，全平台一个比例会把低毛利品类的商家全赶走。

提现手续费也可以设置由平台承担还是商户承担，这会直接影响结算明细的计算公式。商户端需要绑定自己的提现账户，绑定的银行卡或支付宝必须是平台审核过的，否则结算打款时找不到主体，财务只能先挂着。

结算相关的参数，按运营优先级配置如下：

结算周期别一上来就 T+1，平台刚起步时交易量不稳定、退款纠纷也多，周结能给你留出处理售后的缓冲时间。等订单结构稳定了再切 T+1，体验和风控两头都顾得上。

4.3 运费模板与售后服务：多商户最容易忽略的两块

多商户商城运费模板必须由每个商户单独配置，平台要提供“按地区 + 按重量/按件数”的模板能力，否则低客单价的商品会被高运费直接吓跑。会员下单时，系统会根据不同店铺的商品分别计算运费，这也就是多商户订单会拆单的原因之一。二开时不要图省事改成全场包邮，否则运费成本全压在商户身上，商户流失比谁都快。

售后流程也必须按店铺隔离。会员申请退款，走的是对应店铺的售后单流程，平台可以介入仲裁。这里有个后台参数容易被忽略：售后超时自动通过的时间。比如设置超时 7 天未处理自动退款，那么商户连续几天不登录后台，退款就会自动打回给买家，这对商户来说很肉疼，但也是平台保护买家体验的兜底机制。建议把超时自动通过的时长设得比平台承诺的售后时效长一点，避免商户被系统偷偷退款还不知道。

5. DSmall 部署与运营中常见的 5 个坑：现象、原因、解法

5.1 首页能打开、商品详情 404：伪静态规则没落到 Nginx

现象：商城首页、登录页都正常，点开任意商品或店铺链接变成 404。
原因：Nginx 没有把带 pathinfo 的 URL 重写到index.php，PHP 拿不到真实的控制器和方法名，路由匹配失败。Apache 环境则通常是.htaccess没生效，AllowOverride设置成了None。
解决：Nginx 用上面第 2.2 节那套rewrite ^/(.*)$ /index.php?s=/$1 last;规则；Apache 先确认httpd.conf里对应目录的AllowOverride All，再确认mod_rewrite已加载。改完配置记得nginx -t && nginx -s reload，很多人规则写对了没重启，照样 404。

5.2 商户入驻收不到短信：签名和模板 ID 没对上号

现象：买家下单、商户入驻审核的短信通知都发不出去，后台却显示发送成功。
原因：DSmall 的短信接口要走阿里云或腾讯云短信服务，但平台后台配置的签名、模板 ID 只是“占位符”，实际模板变量名和官方模板对不上，比如系统传的是{name}，你申请模板时填的是{product}，服务商直接拒绝。
解决：先在短信服务商后台完成签名审核和模板申请，再把模板内容里每个变量原样填进 DSmall 后台对应字段，注意变量名要一字不差，包括大括号。填完后用真实手机号发一条测试短信，不要只看后台提示。

5.3 订单已完成但结算金额少了：退款和平台券没剔除

现象：某商户月结算单金额和店铺营业额差了 20% 以上，商户找上门。
原因：结算金额不是简单的“订单实付金额减去佣金”。退款成功的订单、平台发放的优惠券、积分抵扣，这几部分需要特殊处理：退款单要从结算里剔除；平台券对应的金额是平台自己承担的营销成本，也不能算进商户货款；积分抵扣部分按比例分摊到平台和商户。v6.2.1 的结算明细表在部分版本里只记录最终净额，不显示计算过程。
解决：对账时不要直接对订单表，去查结算明细表，并把“订单实付、退款、优惠券、积分抵扣、佣金、应结金额”六列拉出来做 Excel 流水核对。发现不一致，先查退款单有没有进结算排除列表。

5.4 图片传不上、头像不显示：目录权限和防盗链双重夹击

现象：商户后台上传商品图片一直转圈，会员头像显示裂图，但服务器负载正常。
原因：第一，runtime和upload目录没有写权限，PHP 脚本没有权限创建图片文件；第二，部分模板或防盗链配置拦截了图片请求的Referer，导致浏览器能打开页面但加载不了图片。
解决：先执行chmod -R 777 runtime upload并确认目录归属是 PHP 运行用户（通常是www-data）；再看 Nginx 里有没有valid_referers限制，有的话把商城域名加进白名单，或者干脆去掉防盗链，图片防盗链对商城来说弊大于利。

5.5 后台菜单点开是空白页：PHP 版本与扩展缺失

现象：后台能登录，但点“商品列表”或“订单管理”页面白屏，服务器日志里没有明显报错。
原因：多数是 PHP 版本过高触发 TP5 兼容问题，或者是缺少php-gd、php-curl扩展，图像处理或网络请求的功能直接致命错误。PHP 8 环境下 TP5 的写法会产生大量 deprecation，有些主机把错误显示关掉了，页面就成了白屏。
解决：第一步打开 DSmall 的调试模式，在application/config.php里把'app_debug' => true，让错误信息直接显示出来；第二步检查php -m | grep gd和curl，缺什么装什么；第三步如果用的是 PHP 8，直接降回 PHP 7.4，这是目前 v6.2.1 兼容性最稳的版本，不用在这个问题上硬刚。

6. 二开优先改这三处：支付回调、结算任务、自测闭环

6.1 支付回调校验与结算任务改造

多商户商城二开，最高性价比的是改支付回调和结算任务。支付回调是所有资金流的入口，这一块不扎实，后面对账全是窟窿。常见的做法是在支付异步通知里做“验签、验订单、验金额、防重入”四件事，顺序不能乱：

// 支付异步通知简化逻辑 $sign = md5($orderNo . $amount . $appKey); if ($sign !== $notify['sign']) { log('验签失败：' . json_encode($notify), 'pay_error'); exit('fail'); } $order = db('order')->where('order_sn', $notify['out_trade_no'])->find(); if (!$order || $order['amount'] != $notify['amount']) { exit('fail'); } if ($order['pay_state'] == 1) { exit('success'); // 幂等处理：重复通知直接返回成功 } // 更新订单状态、写入结算待处理表、增加商户待结算余额

这段逻辑里有三个关键点：验签必须跟网关注册时拿到的密钥一致，否则所有通知都会被当成伪造；金额比对要用等于而不是大于等于，防止金额被篡改；pay_state的判断是幂等保护，因为支付网关在极端情况下会重复推送通知。

结算任务可以从后台手动点“生成结算单”改成定时任务，每天凌晨跑一次：找出所有已完成超过结算周期、且未生成结算单的订单，按商户维度汇总，再扣佣金生成待打款列表。这样财务每天早上只需要复核，不用天天手工点。

6.2 验证二开结果的三个自测手段

二开完最怕的是自我感觉良好，上线就被打脸。我现在习惯用三个手段交叉验证：第一，开调试日志，把runtime/log里的支付、结算日志全部打开，模拟一笔 0.01 元的订单走完整链路；第二，准备一个专用测试商户，从入驻、发品、下单、支付、发货、收货、结算、提现整条链路反复跑，每一步截图存档；第三，上线前把代码分支部署到一台临时服务器，用真实域名跑一遍确认回调地址、短信模板、支付密钥都是对准生产环境的。

这三个手段分别针对代码逻辑、业务闭环、环境配置三类问题。很多二开代码本地跑得好好的，一上生产就出乱子，十有八九是回调地址、密钥、域名这类配置没对准。我现在的习惯是每次上线前先跑一遍“新商户入驻-发商品-买家下单-支付-发货-确认收货-结算-提现”八步闭环，全绿才敢放量。这套巡检救过我很多次，希望帮到你。

本文还有配套的精品资源，点击获取