企业官网建设流程全解析

简介：一款基于ThinkPHP框架开发的多商户B2B2C开源商城系统v6.1.5，面向需要搭建多店铺电商平台的企业开发者、PHP工程师和独立站运营者，可用于学习商城核心业务、商家入驻、订单交易、营销活动及前后端分离架构设计。源码采用B/S架构，后端以PHP+MySQL为支撑，H5端使用Vue.js构建，整体包含商户端、平台端与用户端模块，文件目录结构清晰，适合作为二次开发底座。压缩包共含13466个文件，大小约65.95MB，其中以11208个PHP业务逻辑文件为核心，辅以898个HTML页面、226个JavaScript交互脚本、81个样式表，以及大量JPG/PNG/GIF图片素材，另附SQL数据库初始化脚本、支付证书配置和Markdown说明文档，便于快速部署并理解多商户权限控制流程。已有1030人学习关注，适合希望掌握B2B2C系统数据表设计、多店铺结算机制或前后端分离实践的中高级开发者，可从中获得完整的可运行源码、部署参考与二次开发思路。

1. DSmall多商户B2B2C开源商城：先把它从源码层面拆开看

两年前有个做区域零售的团队找到我，他们想搭一个平台，让本地十几家供应商各自开店、各自发货，平台只抽佣金。预算不多，从零写根本不现实。我当时给的建议就是去看DSmall多商户B2B2C开源商城这类现成方案，这也是国内做多商户平台时最常被提到的开源项目之一，v6.1.5算是一个功能相对完整的版本。

这篇笔记会把DSmall多商户当成一个研究对象来讲，不贴官方文档，也不假装见过谁的安装包，只讲这类源码在真实部署和运营里最常遇到的架构问题、配置参数和翻车点。适合手里有源码、准备本地部署或已经在测试环境里折腾但始终跑不顺的人；也适合技术负责人想快速判断这套东西能不能接住自己的业务需求。我尽量做到新手能按步骤落地，熟手能直接看边界和坑。

2. DSmall多商户的核心设计：订单、店铺、结算这三条线必须先理清

2.1 单商户到多商户的转变：商品表和订单表里的归属字段是分水岭

单商户商城的数据模型很简单，商品表里不需要记录“这是谁的货”，订单表里也不需要记录“钱要分给谁”。但DSmall多商户这类B2B2C系统，最核心的改动就是把“归属”两个字写进了几乎每张业务表。

商品表里会多出店铺ID或商家ID，订单表里同样有这个字段，甚至购物车、售后单、结算单都要带上。这个字段不只是用来区分数据，它决定了后续所有逻辑的分支：列表页按什么过滤、订单通知推给哪个商家的后台、结算时佣金算给谁。如果只看代码不动手，很容易忽略这个字段的重要性，等到做二次开发时写了一条不带商家ID的查询，整个后台的数据就全串了。

常见的数据表设计大致是这样：商家表存登录账号和资质信息，店铺表存店铺名称、Logo、运费模板、经营类目，商品表通过店铺ID关联店铺，订单表通过商家ID关联商家，结算表记录每一笔订单里平台佣金、商家货款和实收金额的拆分结果。这套设计并不复杂，但它是多商户业务的地基。

2.2 订单归属与资金拆分：支付完成后钱去了哪、什么时候到商家账上

多商户平台最敏感的就是资金流。用户付款时，多数情况下钱是先进平台方账户的，然后系统根据订单金额、平台佣金比例、退款情况生成一笔结算记录，再在约定的结算周期里把货款打给商家。DSmall多商户把这块拆成了订单流水和结算单两个维度。

订单流水记录的是每个订单的应收、实收、退款、佣金这些原始数据；结算单则是按周期对订单流水做聚合，生成“这段时间内某商家应该收到多少钱”的结果。如果项目里佣金规则是分类目设置的，比如食品类抽5%、数码类抽8%，那每一笔订单在支付回调时就要把佣金算好并写到流水里，而不是等到结算时再算，这个细节很关键，否则月底结算会乱到没法对账。

从技术角度看，结算模块最需要关注的是状态机。一张结算单通常有待确认、已确认、已打款几个状态，每个状态之间的流转是否有幂等处理，决定了运营手动操作时会不会重复打款。我第一次翻代码时特意先找这个状态流转，确认没问题才继续往下看。

2.3 这套模型的实际承载边界：适合什么规模的业务

DSmall多商户的架构在中小规模业务下非常顺手，单库单应用，部署成本低，开发也好上手。但要说承载几百万用户、日均几十万单，它作为单体应用会明显吃力，因为订单表、商品表都在一个库里，数据量上去之后索引命中率和数据库连接数都会成为瓶颈。

选型时要认清楚这一点：这类开源商城定位是帮业务快速起步，而不是帮你一步到位做成大流量平台。如果你的预期是“先跑起来，后面不行再改造”，那它的下限非常友好；如果你从第一天就要支撑复杂的分仓、分账、多级代理，那还不如直接评估商业版或更重的方案。这也是为什么我一直强调，部署之前先谈边界，别等项目上了线再来补课。

3. 本地把DSmall多商户跑起来：从下载到首页可访问的完整步骤

3.1 环境准备：PHP版本、数据库和扩展的推荐组合

我一般会用 Linux 服务器或本地虚拟机来跑，操作系统选 Debian 或 CentOS 都行，关键是 PHP 版本要符合源码要求。v6.1.5 这一代的商城源码，常见做法是跑在 PHP 7.x 到 8.0 这一段，MySQL 用 5.7 或 8.0，再加一个 Redis 用于缓存和 Session，如果环境里没有 Redis，后台登录和商品缓存会间歇性出问题。

建议先用以下命令检查 PHP 扩展是否齐全，这个检查绝对不能省，至少看到 mbstring、curl、openssl、pdo_mysql、redis 扩展都是 enabled 状态再继续，否则安装过程中有九成概率卡在看不懂的报错上。

php -m | grep -E "mbstring|curl|openssl|pdo_mysql|redis"

这段命令的作用是列出当前 PHP 已加载的扩展并过滤出关键项。如果缺了扩展，按 PHP 版本的对应方式安装即可，比如 Debian 系可以用 apt 装 php-mbstring、php-curl，装完记得重启 PHP-FPM。参数上不需要做额外调整，关键是确认它们在列表里正常出现。

3.2 源码目录与文件权限：三分钟看清哪些目录不能动

源码解压后，目录结构一般会分为应用代码目录、静态资源目录和上传目录。上传目录是运行时写入图片和文件的，必须给写权限；应用代码目录只读即可，不需要也没必要开放写权限，否则被写入了恶意文件你都不容易察觉。

目录权限建议这样设置，我用命令直接说明：

chown -R www:www /path/to/dsmall chmod -R 755 /path/to/dsmall chmod -R 777 /path/to/dsmall/upload chmod -R 777 /path/to/dsmall/runtime

这里把整个目录属主设为 Web 服务用户，默认目录给 755 权限，只有 upload 和 runtime 这两个需要写文件的目录放开到 777。这两个目录一个是用户上传的商品图、营业执照等附件，另一个是框架运行时的缓存与日志。权限开太大会有安全风险，不开够又会出现“上传失败”或“无法写入缓存文件”的报错，实战里这是踩得最多的一道门槛。

3.3 安装向导与伪静态配置：跑通首页的最后两步

多数开源商城都带 Web 安装向导，浏览器访问域名后会自动跳转到安装页，按页面提示填数据库连接信息和管理员账号即可。这一步通常不会卡人，真正让人翻车的是装完后伪静态没配，导致首页能打开、商品详情页全是 404。

Nginx 下的伪静态配置，我一般按下面的写法处理：

location / { if (!-e $request_filename) { rewrite ^(.*)$ /index.php?s=$1 last; } }

这段配置是 Nginx 的常规 rewrite 规则：请求的路径如果不是真实存在的文件，就重写到 index.php 并通过 s 参数传递路由。对 ThinkPHP 风格的商城源码来说，路由入口就是 index.php，URL 重写是否生效直接决定商城内页能不能打开。配置完成后记得nginx -s reload重载，然后在浏览器里分别访问首页、商品详情页、商家入驻页，确认没有 404 再继续。

4. 平台端到店铺端：把入驻、商品和营销配置成可运营状态

4.1 商家入驻到店铺开张：平台审核的关键开关

跑通首页只是第一步，多商户平台真正要运营起来，必须完成“平台上注册商家 → 提交资质 → 平台审核 → 开通店铺”这条链路。在 DSmall 多商户里，平台后台通常有一个入驻审核开关，决定是商家提交后自动开通，还是需要平台人工确认。

我建议把自动通过先关掉，人工审核更稳。原因是资质材料的真实性问题在自动模式下没法处理，营业执照是拍的还是扫描的、是否过期、店铺名称是否涉及侵权，这些系统判断不了。人工审核虽然多一道操作，但能避免上线第一天就出现一批山寨店铺，后面投诉理都理不清。

店铺开通后要检查两个参数：店铺类型（普通店或自营店）和佣金比例。自营店通常不走佣金，普通店按类目扣点。这里要提醒一句，佣金比例要和商品类目绑定，而不是只挂在店铺上，否则商家把高佣金类目的商品往低佣金类目下面挂，结算时你会吃大亏。

4.2 商品SKU、运费模板与库存扣减：三处最常改的参数

商品模块里，SKU 是商家发布商品的必填项，颜色、规格、价格、库存都要在这里定义。很多人在测试环境随便填，结果订单里出现负数库存或者价格不一致的问题才开始追查。正确做法是给每个 SKU 一个唯一的商品编码，这个编码要遵循商家自己定的规则，不能为空也不能重复，否则后续对接 ERP 或财务系统时对不上账。

运费模板是另一个高频修改点。平台可以设置统一的默认模板，也可以允许商家各自创建。需要注意计费方式的参数是“按件数”还是“按重量”，如果业务是卖家具和卖数码的，一定要让商家按类目创建多套模板，否则一件沙发和一盒数据线收一样的运费，售后纠纷会非常多。

库存扣减建议选择“下单减库存”而不是“支付减库存”，高并发场景下“支付减”容易超卖。但“下单减”要配好订单超时关闭机制，比如30分钟内未支付自动关单并回滚库存。这里放一个实际的定时任务配置示例，我习惯用系统 crontab 来实现：

*/5 * * * * php /path/to/dsmall/think order:auto-close --minutes=30 */1 * * * * php /path/to/dsmall/think order:auto-receive --days=7

第一条命令每5分钟扫描一次超过30分钟未支付的订单并自动关闭，第二条每分钟检查一次发货后满7天的订单并自动确认收货。这里的关键参数是--minutes=30和--days=7，具体数值按业务来改。这类定时任务是商城不“烂单”的命根子，如果没有配置，订单会堆积成山，库存也永远回滚不了。

4.3 营销工具的落法：优惠券、满减与拼团在数据层的记录方式

营销功能在多商户系统里和单商户差异不大，但有一个点容易忽略：优惠券的成本由谁承担。平台发券和商家发券在结算时要走不同账户扣减，平台券的成本要从平台佣金里冲抵，商家券的成本则直接在商家货款里扣。我在配置时会先在测试环境分别下一单平台券和商家券，然后核对结算流水里的佣金和货款数字，对不上就直接定位到营销成本字段。

满减和拼团这类活动在数据层的实现通常是活动表和参与记录表。活动表存规则（满多少减多少、几人成团），参与记录表存每个用户的活动状态。这里要注意活动的“重叠规则”，平台活动一般要限制不与商家活动叠加，否则会出现“满减叠加 + 优惠券 + 拼团价”导致的金额倒挂，也就是实付金额小于零，这是我真实见过的事故。

下面是用 SQL 查看商家活动与平台活动是否冲突的检查思路，实际排查时可以拿着这个查询去核对配置数据：

SELECT activity_id, activity_name, start_time, end_time FROM dsmall_marketing_activity WHERE is_global = 1 AND start_time < NOW() AND end_time > NOW() AND status = 1;

这条查询的作用是找出当前正在进行中的平台级营销活动，is_global=1表示平台级活动。如果在同一时间段内存在多条全局活动，叠加风险就会骤然升高。执行后如果结果超过一条，就该去后台检查这些活动的参与限制条件，而不是等到订单金额对不上再来翻数据表。

5. DSmall多商户部署与日常运营必踩的坑：现象、原因、解法

5.1 伪静态没配好：首页能开、内页全404

这个坑出现频率极高。很多人在 Windows 本地用集成环境调试没问题，一上 Linux + Nginx 就出现商品详情打不开、文章页打不开，原因基本是 Nginx 配置里缺少 rewrite 规则，或者把 rewrite 写到了错误的 server 块里。

排查时先访问一个不带伪静态的 URL，比如index.php?s=/goods/1.html，如果能打开而去掉 index.php 就 404，那问题确定在 rewrite。解决方法是把上一章写的 Nginx rewrite 配置放到目标 server 块的 location / 里并重载配置。这个坑的迷惑之处在于首页本身常常是正常的，容易让人误判成源码问题，实际上后端代码根本没跑起来。

5.2 后台登录 Session 频繁失效：Redis 没配好

表现是后台登录成功后点两下就跳回登录页，或者一直提示验证码错误。第一次遇到时我以为是浏览器问题，换了好几个浏览器都是同样结果，最后才发现是 Session 驱动配置成了 files，而代码又在多处调用了 Redis，导致 Session ID 写入和读取的目标不一致。

解决方式是在配置里把 Session 驱动统一设置为 Redis，同时确认 PHP 的 Redis 扩展已安装并且配置项里的 Redis 地址、密码和实际运行的服务一致。常见做法是在 .env 环境变量里设置SESSION_DRIVER=redis和REDIS_HOST=127.0.0.1，如果设了密码还要补REDIS_PASSWORD这一项。

5.3 结算金额对不上：平台佣金、退款单和优惠券的先后顺序没理清

第一次对账时我对结算明细里的数字来回算了三遍都对不上，最后定位到原因：一笔订单在支付后发生了部分退款，但退款时只退了货款，佣金没按比例冲销。换句话说，系统在结算时按订单原金额计算了佣金，而不是按实际到账金额计算，平台多拿了商家的钱。

解决思路是去后台检查佣金计算规则，看是否支持“按实付金额计算”。如果支持，把它打开；如果不支持，只能写一个补偿脚本定时扫描退款订单，按退款比例把多余佣金退回商家的待结算余额。这类问题在代码层面通常不是 bug，而是业务规则的不完善，上线前一定要用“下单→退款→结算”三连操作做一次完整验证。

5.4 商品图片上传后无法显示：upload 目录权限和域名配置双检查

商品图上传成功但前端访问 404 或 403，多半是 upload 目录的写权限没问题，但 Web 服务器没权限读取，或者是上传时保存的 URL 带了本地绝对路径，比如localhost/uploads/xxx.jpg，在正式域名下自然打不开。

排查时先用浏览器直接访问图片完整 URL，确认是 404、403 还是 500。404 多半是伪静态规则把真实文件路径也重写了；403 是目录权限不够；500 是 PHP 处理上传时出问题。对应解决分别是改 rewrite 排除 uploads 目录、调目录权限、查 PHP 错误日志。图片地址问题的预防做法是在后台配置里把上传域名或 CDN 域名设为正式域名，而不是服务器 IP 或 localhost。

5.5 定时任务不执行：入口路径写错和任务列表未开启

定时任务不跑，订单永远不会自动关闭，物流也不会自动确认收货，平台会像死了一样安静。常见原因是 crontab 里写的 PHP 路径不对，或者命令里的任务名写错。我自己踩过最隐蔽的坑是：定时任务脚本是用绝对路径写的，但脚本内引用了相对路径的配置文件，导致命令行模式下加载不到配置，任务空跑了。

建议先在命令行手动执行一次同样的命令，看是否有输出或报错，确认无误后再配置 crontab。同时到后台的任务列表里确认这个任务是不是启用状态，开源系统经常自带一个任务开关，总开关关着的话定时任务到了时间也不会执行。

6. 二次开发与日常维护：建议优先做的三个增强

6.1 给售后流程补一个线下退款审核节点

商城源码自带的售后流程一般是“用户申请 → 系统自动退款或商家直接退款”，这在运营早期够用，但金额大了之后财务会要求有审核介入。我给模拟项目X加过一个简单节点：售后单状态在商家同意后退款前，增加一个“财务确认”状态，由财务在后台核对原订单实付金额和售后申请金额后手动放款。

这个改动不需要动订单表结构，只要在售后单状态字段里加一个枚举值，并在商家的退款回调里判断这个状态才执行退款逻辑。对不熟悉完整流程的人，我建议先不动代码的默认退款逻辑，而是把自动退款配置改成手动模式，后台运营逐笔确认，月底对账时会少很多麻烦。

6.2 结算单增加按日维度查看

系统自带的结算单一般以周期为单位生成，常见的是周结或月结。但运营过程中经常要看某一天的实时数据，尤其是大促当天，按周结算的报表根本来不及反应。我给另一个项目做的就是加了一张“每日结算汇总表”，每天凌晨由定时任务把前一天的订单流水聚合成一条记录，包含订单数、销售总额、平台佣金、商家货款和退款金额。

CREATE TABLE dsmall_settlement_daily ( id INT PRIMARY KEY AUTO_INCREMENT, shop_id INT NOT NULL, settle_date DATE NOT NULL, order_count INT DEFAULT 0, goods_amount DECIMAL(10,2) DEFAULT 0, commission_amount DECIMAL(10,2) DEFAULT 0, refund_amount DECIMAL(10,2) DEFAULT 0, UNIQUE KEY uk_shop_date (shop_id, settle_date) );

这张表的目的是用空间换时间，把每天每个店铺的结算汇总结果固定下来，避免运营每次查日报都要对全量订单流水做聚合，查询速度和数据库压力都能明显改善。字段设计上，uk_shop_date唯一索引保证一个店铺一天只生成一条记录，定时任务重复执行时靠INSERT ... ON DUPLICATE KEY UPDATE做幂等更新，不会产生重复数据。

6.3 上线前做一次索引体检

日常维护里最容易省钱的一个动作就是给核心表补索引。DSmall 这类系统底层表字段不多，但随着数据量增长，商家后台的订单列表查询会变得越来越慢。我习惯用SHOW INDEX FROM检查关键表，重点关注 order 表的shop_id + order_status联合索引，以及商品表的shop_id + is_on_sale联合索引，这两个是商家后台最常触发的查询路径。

还有一个习惯是：每次改完数据结构，都要跑一次“下单 → 支付回调 → 发货 → 确认收货 → 售后申请 → 结算生成”全流程回归。开源系统的改动往往牵一发动全身，不动流程就去加字段，大概率会把某个状态机链路给误伤。我这么多年被坑出来的教训就是：先确认数据流再动手，先跑回归再谈上线。希望这些经验能帮到你。

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