多商户多仓库SaaS进销存源码：数据隔离与库存并发实践

简介：这是一套面向企业信息化与进销存SaaS开发场景的多商户ERP管理系统源码包。系统支持总公司—子公司—门店三级组织架构，各企业数据完全隔离，同门店多仓库共享基础数据但单据隔离，不同门店的仓库也支持调拨，总公司与子公司账号可按需切换到门店操作，适合需要多租户隔离、多级权限与库存协同管理的云进销存项目二次开发。压缩包共1317个文件，整体约22.36MB，以php文件承载后端业务，js、css、html构成前端交互与页面，png、gif、jpg等图片素材用于界面，另含sql、csv、txt等配置说明，便于按模块检索。目前已有231人学习/下载。对开发者和部署运维者而言，这套源码提供了从扫描开单、多仓库调拨到SaaS营销版无限商户的完整闭环，可直接复用或改造，也能帮助理解多商户数据隔离与多级组织架构的设计实现。

1. 多商户多仓库SaaS进销存源码：真正难的从来不是扫码枪那一声响

一套标着“多商户、多仓库、带扫码、SaaS营销版、无限商户”的进销存ERP源码，功能听起来很杂，但真正难的不是扫码枪那一声响，而是“一套实例服务多家商户，每家商户还有多个仓库”时，数据隔离和库存并发这两件事。部署一套这样的系统，平台方可以不断开通新租户，每个租户自己开仓库、建SKU、做采购和销售单据，扫码枪扫一下就能完成出入库。

这类源码解决的是中小商贸企业的实际问题：要开分店、要管多个仓、要用手机或扫码枪快速录单，还要能发优惠券、做会员营销。对于有技术基础的个人开发者和软件服务商来说，在一套成熟源码上做二次开发，比自己从零建模快得多。

下面从选型、部署、核心代码、避坑、验证五个方向拆开讲，代码和表结构尽量给到可以直接抄的程度。如果你准备接手这类源码做交付，这篇应该能帮你省下几个周末的排查时间。

2. 源码架构与数据模型：多商户隔离、多仓库库存、扫码落库怎么设计

拿到压缩包先别急着解压跑起来。先花半小时把数据模型和目录结构读明白，比盲跑一通省时间。这类源码一般拆成平台管理端和商户端两套入口，平台端负责开通商户、配置套餐，商户端负责仓库、员工、SKU和日常单据。扫码也不是一个独立模块，它只是把条码转换成SKU的快捷录入方式，真正干活的是出入库单据和库存流水。

2.1 选型先想清楚：PHP单体为什么是这类源码的主流

市面上这个定位的源码包，主流实现是PHP单体加MySQL加Redis，前端走H5或者小程序，后台管理用单独的后台入口。和Java微服务版本相比，PHP单体在中小规模交付中有明显优势：部署轻、一台常规云主机就能跑、二次开发门槛低、改完刷新就能看到效果。Java版本虽然并发扩展性更好，但运维成本和开发环境要求高，几十个商户的体量根本用不上那套能力。

这里要先把标题里的“无限商户”说透。它通常指的是源码在授权层面不限制商户创建数量，并不是一台服务器能无限扛并发。真实影响上限的是数据库连接数、库存表的数据量、以及定时任务的执行速度。遇到动辄说“无限”的源码，第一反应应该是去看它有没有做Redis缓存、有没有读写分离的预留，而不是先高兴。

2.2 多商户数据隔离的三种方案与merchant_id索引陷阱

SaaS多商户第一问题是数据隔离。常见三种做法：共享库共享表加merchant_id，共享库独立schema，独立库。独立库隔离最彻底，但开通新商户要建库建表，运维成本高；独立schema在MySQL里实际还是同一套存储，只是逻辑命名空间；用得最多的是共享表加merchant_id，所有业务表都带商户字段，查询靠条件过滤区分。

这套源码常见的就是第三种。优点是开通商户零成本，缺点是代码漏掉一个条件就串号。先看一个标准查询长什么样：

SELECT s.sku_id, sk.sku_name, s.available FROM erp_stock s JOIN erp_sku sk ON sk.id = s.sku_id WHERE s.merchant_id = 10 AND s.warehouse_id IN (1, 2);

逻辑很简单，坑在索引。stock表的数据量上来之后，如果只在warehouse_id上建索引，商户条件无法走索引，会扫全表。正确做法是建联合索引，商户字段放最左：(merchant_id, warehouse_id, sku_id)。查询条件里固定有merchant_id的，索引才能稳定命中。没有索引的SaaS系统，做到每天几万条库存流水后，单据打开就明显变慢。

2.3 多仓库库存模型：分仓库存表为什么不需要再加总库存

多仓库和多商户是两个独立维度。商户确定后，仓库之间是物理隔离的库存关系：A仓的库存和B仓的库存不能互相顶替，调拨得走调拨单。核心库存表的设计通常是这样：

CREATE TABLE `erp_stock` ( `id` int unsigned NOT NULL AUTO_INCREMENT, `merchant_id` int unsigned NOT NULL DEFAULT 0, `sku_id` int unsigned NOT NULL DEFAULT 0, `warehouse_id` int unsigned NOT NULL DEFAULT 0, `available` int NOT NULL DEFAULT 0, `locked` int NOT NULL DEFAULT 0, `updated_time` datetime DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `uk_merchant_sku_wh` (`merchant_id`, `sku_id`, `warehouse_id`), KEY `idx_merchant_wh` (`merchant_id`, `warehouse_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

available是可用库存，locked是订单占用库存。下单时先锁库存，收款后再扣available并释放locked，取消订单则回滚锁定的数量。很多新手会再加一张总库存表，觉得查询方便，但实际上总库存和分仓库存同时更新，事务一致性很难保证，对不上账时根本不知道信哪张表。总库存需要时直接用SUM聚合实时算，不需要单独维护。

每次库存变动都要落流水表，这是对账的最后防线。stock_flow表至少要有商户、SKU、仓库、变动数量、业务类型（采购入库、销售出库、调拨、盘点、期初）、关联单据号。流水只增不改，出问题还能顺着单号倒查。

2.4 扫码模块是怎么组成的：扫码枪、摄像头和服务端条码匹配

进销存里的“带扫描”，通常指两种设备：USB扫码枪和手机摄像头。扫码枪本质上是一个键盘输入设备，扫一个条码等于敲一串字符再带一个回车；手机摄像头则是调用摄像头识别条码后填入输入框。所以前端要做的事情并不复杂，真正的匹配逻辑在后端。

服务端拿到条码要按优先级找SKU：先精确匹配条码字段，匹配不到再尝试去掉前后缀的模糊匹配，再不行就让操作员手动选择商品。这里给出一段接收扫码输入的入口示意：

$code = trim(input('code')); $sku = Sku::where('barcode', $code)->first(); if (!$sku) { // 去掉常见前缀后缀，比如 0 开头补位 $cleanCode = ltrim($code, '0'); $sku = Sku::where('barcode', $cleanCode)->first(); } if (!$sku) { throw new \Exception('条码未识别，请手动选择商品'); }

注意，手机端调摄像头扫码，H5页面必须在HTTPS环境下才能调起相机权限，这是浏览器安全策略决定的。扫码枪则没有这个限制，但要注意输入法状态，这个问题后面避坑章会单独展开。

3. 把源码在本地跑起来：环境配置、数据库初始化与首个商户创建

本地跑通的最小目标是看到一个后台登录页，并且能创建出第一个商户。建议直接在Linux云主机或虚拟机上操作，Windows下PHP版本坑多，路径带空格还会引出一堆玄学报错。整个部署过程按环境初始化、代码放置、数据库导入、后台建商户四步走，顺序不要乱。

3.1 本地运行环境：PHP版本、扩展清单与安装命令

先确认依赖组件。这套源码常见组合是PHP 7.4或8.0、MySQL 5.7或8.0、Redis 6、Nginx。PHP版本直接看源码里的语法兼容性，如果代码用了构造函数属性提升这类特性，至少要PHP 7.4起步。扩展方面，最常缺的四个是bcmath、gd、mbstring、redis。

以Debian系为例，装完基础环境后补扩展：

apt-get update apt-get install -y php8.0-cli php8.0-fpm \ php8.0-mysql php8.0-redis \ php8.0-gd php8.0-bcmath php8.0-mbstring php -m | grep -E 'bcmath|redis|gd|mbstring'

bcmath负责金额精度计算，缺失时营销金额计算会直接报未定义函数；gd负责验证码和商品图片缩略，安全登录页离了它转不出来；mbstring处理中文SKU名和导出文件，没有它导出Excel时中文全变乱码。装完之后用grep确认扩展已加载，再进入下一步。

3.2 解压后先读目录：入口文件与nginx根目录指向

解压后先看目录结构，通常长这样：

erp/ ├── app/ │ ├── controller/ │ ├── model/ │ └── service/ ├── config/ ├── public/ │ └── index.php ├── runtime/ ├── extend/ ├── route/ └── install/

绝大多数404问题出在站点根目录指错。Nginx的root必须指向public目录，而不是项目根目录。否则访问后台时，PHP能找到文件但URL重写全部失效，路由全跑到前端控制器上。伪静态配置也要跟着开，把不存在的文件请求都转发到index.php：

location / { try_files $uri $uri/ /index.php?s=$uri&$args; }

runtime目录要给写权限，否则编译模板、生成日志、写缓存全都会失败。权限命令是chmod -R 777 runtime，生产环境改成php-fpm用户拥有即可。

3.3 导入初始化数据库并配置连接：prefix参数不要乱动

拿到源码包通常会附带初始化SQL文件，名字可能是erp_init.sql或install.sql。先导入：

mysql -u root -p < erp_init.sql

导入完成后，去看config下的数据库配置。一般会有一个database配置文件，也可能跟.env环境变量文件配合。核心配置写出来是这个意思：

return [ 'type' => 'mysql', 'host' => '127.0.0.1', 'port' => 3306, 'database' => 'erp_saas', 'username' => 'erp_user', 'password' => 'YourStrongPass', 'prefix' => 'erp_', 'charset' => 'utf8mb4', ];

prefix是表前缀，千万别看它不顺眼就改。改前缀相当于把所有表名换一遍，除非你连源码里所有模型文件名一起改，否则启动第一时间就是各种“表不存在”。另外，密码里如果带特殊字符，注意配置文件是单引号还是双引号包裹，省得被转义坑一次。

3.4 初始化顺序：先建商户再建仓库，最后建员工账号

数据库通了你就能打开安装向导或默认后台登录页。第一次进来，初始化顺序有讲究：

1. 在平台端创建第一个商户，设置套餐和到期时间。
2. 进入商户后台，先建仓库，仓库名称编码要规范。
3. 创建SKU和商品分类，SKU编码建议按品类规则生成。
4. 最后创建员工账号，绑定角色和仓库权限。

顺序不能反。很多源码的收银端登录后要拉取“当前员工可操作的仓库列表”，这个列表是按员工和仓库的绑定关系过滤的。如果先建员工再建仓库，员工登录后仓库选择器是空的，操作员会以为系统坏了。建员工的时候还要分配权限组，扫码出入库、盘点、查看报表这些菜单都在角色权限里，漏配一个菜单，前端表现是“按钮消失”，排查起来容易误导人。

4. 核心代码走读：商户权限过滤、库存扣减、扫码出入库和营销计算

环境跑通之后，二开碰得最多的是四块代码：模型查询自动带商户条件、库存并发扣减、扫码出入库接口、营销金额计算。这四块也是决定系统后期稳不稳的关键。

4.1 商户权限隔离的关键：用模型全局作用域兜底

多商户系统最怕的是开发者在某个新接口里忘写merchant_id，数据串得一塌糊涂还不好查。很多源码会在模型基类里做一层兜底，常见写法是全局作用域。这是一个Eloquent风格示例，ThinkPHP的模型过滤器思路完全一样：

trait MerchantScope { public static function bootMerchantScope() { static::addGlobalScope('merchant', function ($builder) { $builder->where('merchant_id', merchant()->id()); }); } }

这个Trait挂到所有业务模型的基类上之后，每次静态调用查询都会自动追加商户条件。merchant()是一个全局助手函数，从当前登录态里取商户编号。

但要注意，全局作用域只保护模型查询和关联查询。你用原生SQL、查询构造器或者写子查询时，它管不到。所以避坑守则是：二开一律走模型层，禁止为了图方便写裸SQL查业务表。如果实在要写，必须显式拼上merchant_id，并在代码评审时重点盯这一行。

4.2 库存扣减别用先查后改：事务加锁或条件更新

很多第一次做进销存的人写扣库存都是“先查出来，判断够不够，再减掉”。这个逻辑在并发场景下必翻车。两个收银员同时买同一个SKU，都读到库存还剩1件，都判断“够”，都执行减1，结果是库存变成负数。正解是让“判断+扣减”成为一个原子操作。

用事务加行锁的写法看这一段：

DB::transaction(function () use ($skuId, $warehouseId, $qty) { $stock = Stock::where('merchant_id', merchant()->id()) ->where('sku_id', $skuId) ->where('warehouse_id', $warehouseId) ->lockForUpdate() ->first(); if (!$stock || $stock->available < $qty) { throw new \RuntimeException('库存不足'); } $stock->available -= $qty; $stock->save(); StockFlow::create([ 'merchant_id' => merchant()->id(), 'sku_id' => $skuId, 'warehouse_id' => $warehouseId, 'change_qty' => -$qty, 'biz_type' => 'sale', 'biz_no' => $orderNo, ]); });

lockForUpdate会给这条库存记录加行级排他锁，第二个请求必须等第一个事务提交后才能读，所以不会出现并发扣超。库存流水和库存扣减放在同一个事务里，保证任何一方失败都能回滚。如果不方便用事务，也可以换成条件更新：

UPDATE erp_stock SET available = available - ? WHERE merchant_id = ? AND sku_id = ? AND warehouse_id = ? AND available >= ?;

执行后检查受影响行数，等于0说明库存不足。这种写法少了行锁等待，并发量高时更推荐。

4.3 扫码出库接口：条码解析、防重复提交与扣减联动

扫码出库是收银端最频繁的接口。它的完整路径是：前端收到扫码枪回车事件→把条码传给后端→后端按条码找SKU→校验库存→扣减并生成销售明细分录。接口里要处理两件大事：条码清洗和防重复提交。条码清洗解决的是全角字符、空格、回车残留问题；防重复解决的是扫码枪连击导致同一商品被扫两次。

public function scanOut(Request $request) { $code = trim($request->input('code')); $sku = Sku::where('barcode', $code)->first(); if (!$sku) { $sku = Sku::where('barcode', 'like', $code . '%')->first(); } if (!$sku) { return error('条码未识别，请手动选择商品'); } // 当前订单下做3秒防抖，防止扫码枪连击重复提交 $lockKey = 'scan_lock_' . $orderNo . '_' . $code; if (!Cache::put($lockKey, 1, 3)) { return error('条码已提交，请勿重复扫码'); } // 复用库存扣减逻辑 deductStock($sku->id, $warehouseId, 1, $orderNo); return success([ 'sku_name' => $sku->sku_name, 'price' => $sku->price, ]); }

Cache::put的第三个参数是过期秒数，这里设3秒，既不影响同一种商品连续扫多件，也能拦住误触连击。注意防抖只是第一层，真正的幂等判断还是要靠订单状态：再次提交相同订单明细时，应该走“已经存在则加数量”而非重复插入。扫码枪的输入框要留意回车事件，别阻止默认提交，否则扫码枪回车唤不醒查询。

4.4 营销版金额计算：会员价、满减、优惠券、分摊的执行顺序

营销版和基础版的差别，主要在订单金额计算这一层。常见执行顺序是：会员价优先→满减→优惠券→尾差分摊。顺序错了，同一笔订单能算出完全不同的金额。金额计算必须在服务端做，不能信任前端传来的合计金额。前端可以看，后端必须重新算。

一个简化的计算流程：

// 所有金额统一转成“分”计算，避免浮点误差 $amount = (int) round($sku->price * 100); // 第一步：会员价覆盖原价 if ($memberTier && $sku->member_price > 0) { $amount = (int) round($sku->member_price * 100); } // 第二步：满减，按商品行参与金额判断 if ($orderTotal >= $rule['min_amount']) { $amount -= (int) round($rule['discount'] * 100); } // 第三步：优惠券抵扣，不超过当前剩余应付 $couponAmount = min($amount, $coupon->value); $amount -= $couponAmount;

优惠券、满减规则都要带merchant_id和时间窗口字段，跨商户的营销规则是常见的数据泄露点。分摊时处理尾差，最后一行的明细金额用“订单总额减前面明细合计”来填，保证订单头与明细总和永远一致。营销规则启用之后，注意后台要能配置适用仓库，否则多仓库场景下A仓的活动被B仓用掉，对账时会产生莫名差异。

5. 部署与二次开发避坑：几个容易让系统翻车的配置点

这套源码跑通不难，真正花时间的是那些不报错但结果不对的问题。下面五个坑是我每次接手类似系统都要排查一遍的地方，每条按现象、原因、解决展开。

5.1 坑一：商户A看到了商户B的订单和会员数据

现象：商户A的管理员登录后台，在会员列表或订单列表里能看到其他商户的数据；统计数据偶尔是全部商户的汇总，需要手动还原本商户数据才能对上。

原因：模型层全局作用域管住了常规查询，但二开时有人图方便用了原生SQL，或者直接查询了中间表、关联表，漏写merchant_id条件。也可能是登录时没有正确初始化商户上下文，导致全局作用域里的merchant_id取出来是空值，查询条件被直接忽略。

解决：先确认入口中间件有统一的商户身份注入，再全局搜索代码里的Db::query和原生select语句，逐一补上商户条件。排查时可以临时打开SQL日志，看每条业务SQL是否都带merchant_id条件。后期团队约定：所有跨表查询必须走模型关联，原生SQL需要额外提交说明原因。

5.2 坑二：并发销售时库存被扣成负数

现象：两个收银员同时卖同一个SKU，订单都成功生成了，库存却变成了负数，而且库存流水里的变化数量看着也没错，就是汇总对不上。

原因：扣库存用了“先查后改”的非原子操作。两个请求都查到剩余1件，都判断够卖，然后分别执行扣减，最后一个请求把库存扣到了-1。

解决：改事务加行锁，或者用条件更新。条件更新的方式简单直接：UPDATE带available >= ?条件，执行完判断影响行数，0就说明库存不足。注意一条SQL把扣减和判断合并，不要拆成两步。另外，库存扣减、流水写入、单据状态更新必须放在同一个事务里，单独在外面先扣库存再写单据，失败时就得人工对账。

5.3 坑三：扫码枪扫出来的条码多字符或者丢位

现象：扫码枪扫同一件商品，有时候扫得出来，有时候提示条码未识别。把扫进去的码打出来看，前面多了个“a”，或者全角数字占了两字节，甚至最后少了一位。

原因：扫码枪本质是键盘输入，输入法在中英文切换状态时会干扰录入结果，中文全角状态下数字和字母会被替换成全角字符。还有一部分扫码枪会按厂商配置追加回车符或前缀码，代码没做清洗就直落库。

解决：前端扫码输入框加正则清洗，只保留数字和字母；后端在接收条码时统一trim并过滤非可见字符。识别不了的时候，可以尝试按条码后几位或者去掉前导零再匹配，但模糊匹配范围别放太宽，否则两个相似条码会对应错商品。收银端页面上加一个输入法锁定提示，让操作员保持英文输入态，能省掉一半这种问题。

5.4 坑四：定时任务没挂，库存快照和报表一直不更新

现象：系统跑了一周，日常单据都正常，但库存预警、积分过期、优惠券失效这些功能全没反应，日结报表数字停留在部署当天。

原因：源码里用命令行执行定时任务，部署时只配了Web环境，没有配置crontab，计划任务从来没运行过。有些源码甚至把库存快照生成也放在定时任务里，不跑库存统计就是旧数据。

解决：找到源码里的command或task目录，确认计划任务入口，然后用crontab挂上。一般像这样：

# 每天凌晨 2 点执行库存结转与优惠券清理 0 2 * * * cd /data/www/erp && php think schedule:run >> runtime/cron.log 2>&1

日志一定要落文件。这样定时任务哪天没跑，还能通过日志时间定位是脚本卡住还是cron本身没触发。上线前把任务列表打印出来核对一遍，别漏了。

5.5 坑五：核心文件加密或绑定域名，本地跑不起来

现象：代码部署好后，登录页正常，但一进入核心业务页面就白屏，查看文件发现是乱码；或者页面提示“授权域名不匹配”，必须改成特定域名才能访问。

原因：交付方对核心模块做了代码加密保护，加密文件绑定了授权域名或服务器IP。本地用localhost或测试IP访问时授权校验失败，导致整个模块不可用。

解决：先看源码包里有没有license、授权key之类的配置文件，按有效渠道的流程绑定当前测试域名。注意这里的核心是确认你拿到的授权范围是什么，能不能用于本地开发和二开调试。如果加密文件无法解密，要评估加密部分覆盖了哪些模块，是否影响你的改造计划。遇到这种情况，最稳妥的做法是在正式采购前要求对方提供完整可读源码，并在合同里写清交付物形态，避免二次开发时被加密文件挡住。

6. 上线前的完整验证：用最小订单流把系统跑一遍

源码部署完，别急着给客户演示。先按最小业务流完整走一遍，能发现八成以上隐藏在配置里的问题。这里列一张验证表，照着走，每一步都确认结果。

这八步走完，核心链路基本通了。再加两个进阶点，能少走很多弯路。

第一，移动端对接时，H5扫码页面必须提前准备HTTPS证书，本地开发可以用内网穿透临时顶一顶，正式环境直接配证书。第二，SKU和期初库存多半要走Excel导入，导入模板的列名不要手动改，代码是按模板列名解析的，多一列少一列都会报错；导入前先清一遍模板里的格式符号，省得把不可见字符带进数据库。

库存这条路最怕对不上账。我做这类项目最深的一个教训是：线上库存和账面库存不一致时，不要急着改库存，先查流水。流水完整，问题一定在单据创建逻辑；流水不全，问题就在事务边界。先保流水，再修余额，账才能平。希望这些踩过的坑能帮到你，至少在你上手这套系统时，少熬几个盯着日志发呆的凌晨。

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