从到货到出库：用 ModernWMS 跑一遍小仓库业务链

小仓库平时最难回答的三个问题是：“这批货到了吗？在哪个库位？现在能不能发？”

采购表里有一个数字，仓库 Excel 里是另一个数字，货架上的实物又是第三个数字。到货、上架、冻结、拣货和出库分散在纸单、表格与聊天记录里，数量还能勉强对，过程很难追。

ModernWMS 是一套 Vue 3 + ASP.NET Core 的开源仓库管理系统，提供仓库、库区、库位、商品、收货、库存、发货、盘点、打印和统计等模块。它适合拿来验证一件具体的事：一个商品从到货到出库，数量、库位和单据状态能否始终解释清楚。

先说限制。当前上游代码存在已经公开的认证、租户隔离和 CORS 风险；默认密码、JWT 密钥与数据库示例配置也不适合生产。下面的步骤仅用于绑定 127.0.0.1 的虚构数据 PoC，不要接企业数据库，不要开放到公网或办公网。

来源链接：https://github.com/fjykTec/ModernWMS

它管的是仓内过程

ModernWMS 的业务对象比一张库存表多得多。基础资料包括公司、用户、角色、仓库、库区、库位、商品、SKU、供应商、客户和货主。收货从到货通知开始，经过确认到货、卸货、分拣和上架；出库则覆盖库存分配、拣货、打包、称重、出库与签收。

ModernWMS 官方系统界面。实际菜单与字段以部署版本和权限配置为准。

仓内还可以做移库、冻结与解冻、库存调整、盘点，以及组合、拆分等加工操作。前端提供简体中文、繁体中文和英文，代码层可以看到 MySQL、SQL Server、PostgreSQL 与 SQLite Provider；当前部署文档主要维护前三种数据库脚本。

它不能直接替代 ERP。采购、销售、财务、成本核算和生产计划仍需要其他系统负责。仓库里也没有淘宝、京东、Amazon、Shopify 等现成连接器；要与 ERP、OMS、MES 或物流平台同步，技术团队还得处理字段映射、幂等、失败重试和状态回传。

先建一个隔离的本地 PoC

项目 GitHub 与 Gitee 已经出现明显分叉。GitHub master 的固定审计提交为：

1837e17e6017f3cb6aea93437d2370659ee9392b

GitHub 没有正式 Release 和 Tag。官方 Docker Hub 镜像也比较旧，因此试用时锁定镜像 digest，不使用浮动 tag：

mkdir -p modernwms-poc
cd modernwms-poc

docker pull \
  modernwms/modernwms@sha256:15d38de355cf6114f7616bf57cac1dd898101a5b1639321a04bb52733185b44b

docker run --name modernwms-poc \
  --detach \
  --restart=no \
  --memory=1g \
  --cpus=1.0 \
  --pids-limit=256 \
  --publish 127.0.0.1:8080:80 \
  --publish 127.0.0.1:20011:21011 \
  modernwms/modernwms@sha256:15d38de355cf6114f7616bf57cac1dd898101a5b1639321a04bb52733185b44b \
  ./run.sh

这里特意把宿主机 20011 映射到容器的 21011。README 示例使用 20011:20011，但镜像启动脚本里的后端实际监听 21011，直接照抄文档容易遇到登录超时。

浏览器访问：

http://127.0.0.1:8080

演示账号：

admin / 1

登录后可以立即修改密码，但改密码不能修复后端全局认证缺失。这个实例仍应保持 localhost-only。

用下面的命令确认端口没有监听所有网卡：

docker port modernwms-poc

期望看到：

80/tcp -> 127.0.0.1:8080
21011/tcp -> 127.0.0.1:20011

如果出现 0.0.0.0 或 [::]，先停止测试并修正端口绑定。

用一个商品建立基础资料

不要一开始导入公司的真实商品库。PoC 用最小数据集就够了：

仓库：TEST-WH
库区：收货区、存货区
库位：REC-01、A-01-01
供应商：TEST-SUPPLIER
客户：TEST-CUSTOMER
商品：测试水杯
SKU：CUP-BLUE-01
入库数量：10
出库数量：3

创建顺序建议按依赖关系来：先建仓库、库区和库位，再建供应商、客户、商品与 SKU。多人参与时，再增加一个普通库管角色和测试账号，检查菜单权限与操作权限。

官方业务界面截图。PoC 中使用虚构数据，字段和状态以当前部署版本为准。

这里有个很重要的验收点：前端看不到某个菜单，不代表后端 API 已经禁止访问。当前代码的全局 [Authorize] 被注释，部分对象操作也缺少租户过滤。权限验证不能只看页面按钮是否隐藏。

跑通 10 件商品的收货与上架

为 CUP-BLUE-01 创建数量为 10 的到货通知，然后按系统状态推进：

到货通知
→ 确认到货
→ 卸货
→ 分拣
→ 上架到 A-01-01

每一步都记录单据状态、实际数量和库位。上架完成后，分别从商品库存和库位库存查询这批货，预期结果是：

商品 CUP-BLUE-01 可用库存：10
库位 A-01-01 库存：10

如果团队需要管理批次、序列号、货主、上架日期或有效期，也应在这一轮里检查字段是否够用。功能列表再长，落不到自己的商品规则上仍然没有意义。

再发出 3 件，库存应剩 7

创建数量为 3 的发货单，继续完成：

创建发货单
→ 分配库存
→ 拣货复核
→ 打包
→ 称重
→ 出库
→ 签收

ModernWMS 官方业务页面。PoC 应重点检查单据状态、库位库存和操作记录。

出库完成后检查三处：商品库存、库位库存和发货单状态。理论结果都应能解释剩余数量 7。

再增加一个异常测试：先冻结剩余库存中的 2 件，再尝试创建超出可用库存的发货。观察冻结数量是否从可用库存中排除，解冻后能否恢复，操作日志有没有留下记录。

一条正常链路跑通，只能证明基础流程可用。冻结、短少、破损、移库和盘点差异更容易暴露业务规则不一致，PoC 至少要选一个异常场景。

生产前有几道硬门槛

ModernWMS 的 Apache-2.0 许可允许使用、修改和再分发，但开源不等于零成本。服务器、数据库、备份、培训、数据清洗、接口开发和升级维护都需要人负责。

当前代码进入生产前，还需要完成一轮实质性安全整改：

恢复后端默认认证，并为所有读写接口增加角色、租户和对象级校验；
用 Argon2id、bcrypt 或 PBKDF2 替换无盐 MD5 密码；
移除固定 JWT 密钥，统一签发和校验配置；
CORS 改为严格白名单或前后端同源；
关闭匿名注册、Swagger、Hangfire Dashboard 和敏感数据日志；
限制 Excel/JSON 导入大小、行数与字段长度；
使用受支持的 .NET 与 Node.js 版本，并完成兼容测试；
建立数据库迁移、备份恢复和回滚演练。

GitHub issue #57 已报告全局认证禁用与跨租户对象访问问题，issue #29 报告任意 Origin 反射。完成这些整改之前，即使加了 HTTPS、改了管理员密码，也不能把当前上游版本视为可直接上线的企业系统。

用验收结果决定是否继续

PoC 结束时，不要只留一张“安装成功”的首页截图。至少回答下面几个问题：

收货上架后，商品库存与库位库存是否一致；
出库 3 件后，剩余数量是否为 7；
冻结库存能否阻止错误分配；
单据状态能否解释当前作业进度；
普通库管能否越过权限读取或修改数据；
重启、备份和恢复后，库存与权限是否保持一致；
对接 ERP、商城或物流平台需要多少二次开发。

测试完成后删除容器：

docker rm --force modernwms-poc

ModernWMS 的模块覆盖已经足以帮助小团队梳理仓内流程。当前上游更适合做功能验证和二次开发基线。是否继续投入，应该由业务链、异常处理、安全整改和后续维护成本共同决定。

你所在的仓库，现在最难说清的是库存数量、货物位置，还是订单状态？

来源链接：

GitHub：https://github.com/fjykTec/ModernWMS

GitHub 固定提交：https://github.com/fjykTec/ModernWMS/tree/1837e17e6017f3cb6aea93437d2370659ee9392b

Gitee：https://gitee.com/modernwms/ModernWMS

官网：https://modernwms.ikeyly.com/

License：https://github.com/fjykTec/ModernWMS/blob/1837e17e6017f3cb6aea93437d2370659ee9392b/LICENSE

来源：https://github.com/fjykTec/ModernWMS