企业官网建设流程全解析

做一个小型仓库进销存管理系统，标题听起来像是入门练手项目，但我真把这套东西从需求梳理到上线维护完整走了一遍之后，最直接的感受是：规模小不等于简单。商品档案、采购入库、销售出库、库存盘点、补货预警、数据统计，每一个环节背后都有一堆现实业务约束。账面库存和实际库存对不上、出库时发现库存是负数、导入 Excel 时规格乱掉，这些问题如果不在一开始把数据结构和业务流程想清楚，后面全是要加班擦的坑。

这套基于 Vue 的小型仓库进销存管理系统，主要面向还在用手工台账或 Excel 管理库存的中小仓库。系统把“进、销、存”三个动作串成闭环：采购入库时更新可用库存，销售出库时扣减库存，所有数量变化都留流水记录，最终通过库存表和统计看板把账面情况实时反映出来。整套系统可以独立部署，也可以作为现有后台管理系统的一个子模块嵌进去。

这篇文章我会按“设计与实现”的过程来写：先讲需求拆解和技术选型，再讲数据库表结构，然后是后端接口和业务逻辑，接着是 Vue 前端页面的具体实现，最后把部署上线和日常维护容易踩的坑一并整理出来。适合三类人看：准备自己动手做仓库管理系统的开发者、想找个真实业务场景练手的 Vue 初学者，以及要给客户交付小型管理系统但不想只交一堆 Excel 宏的初级项目负责人。

1. 需求拆解和技术选型，先想清楚再做

1.1 小型仓库在什么情况下需要一套管理系统

先别急着写代码。我接触过的几个需要这类系统的仓库，业务规模都不大，一般就是两三个人负责采购、销售和仓管，仓库面积也不大，SKU 数量从几十到三四百个不等。真正让他们头疼的不是“东西多到管不过来”，而是下面几个具体场景：

• 商品种类多了以后，Excel 里一行一个商品，规格、单位、采购价、销售价全挤在几列里，录入不统一。
• 两个人同时改同一张库存表，一人改了出货量，另一人不知道，账就对不上了。
• 月底盘库发现实物数量和账面数量差了一大截，又说不清是哪几笔出入库造成的。
• 老板问“现在有多少库存”“最近一周进了多少货、出了多少货”的时候，临时统计要花很长时间，还未必准确。

所以这套系统的核心目标不是做得多大，而是把“商品档案→入库→库存变化→出库→库存变化→统计报表”这个最小闭环跑通，并且保证每一步都有记录、可追溯。

在需求阶段我最强调的一件事是：不要一开始就想着做权限管理、多仓库、审批流这些扩展功能。小型系统最怕功能堆砌，重点把出入库流程和库存一致性做扎实，就已经解决了用户 80% 的痛点。权限可以只做管理员和操作员两种角色，多仓库也完全可以通过在商品编码上做前缀区分，留到后续再演进。

1.2 技术方案对比与选型结论

前端框架我选了 Vue 3，搭配 Vite 构建、Vue Router 做路由、Pinia 做状态管理，UI 组件库选了一款成熟的中后台组件库，图表使用 ECharts。后端选用 Node.js 的 Express，数据库用 MySQL。

选型理由我逐一说一下，这部分是很多新人最容易忽略的。

Vue 3 + Composition API 的写法，对中后台系统非常合适。一个页面往往包含表单、表格、弹窗、分页多个状态，用 setup 函数可以把同一块业务的逻辑集中在一处，而不是像 Vue 2 的 Options API 那样，数据在 data、方法在 methods、计算属性在 computed 里来回跳。而且 Vue 3 对 TypeScript 支持更好，虽然这个小系统我用的是 JavaScript，但后续如果要加人维护，迁移成本会低很多。

为什么不选 React？也不是不能选，而是考虑到这套系统的目标用户多数在中文技术社区找资料，Vue 的生态资料更集中，组件库也更贴合同类管理系统页面风格。这套系统本身没有复杂的跨端需求，Vue 已经完全够用。

状态管理用 Pinia 而不是 Vuex。Pinia 的 API 更简单，去掉了 mutations 这个概念，直接在 store 里定义 state、getters、actions，写起来更接近普通对象操作。对于进销存这种需要频繁在页面之间共享“当前用户信息”“最近选择的供应商列表”这类数据的场景，Pinia 轻量且好调试。

后端用 Node.js Express，是因为我自己熟悉这套链路，前端写 Vue，后端写 Node，全栈都用 JavaScript，语言统一，小项目就少一套维护成本。如果你更熟悉 Java Spring Boot，那后端完全可以用 Java 重写，本文的核心在数据结构和业务流程，这部分逻辑对语言不敏感。

数据库选了 MySQL，关键是事务能力。入库、出库一定会涉及“写单据 + 更新库存 + 写流水”三个操作，必须保证要么全部成功、要么全部回滚，这个要求在文件型数据库上实现起来要多费不少劲。MySQL 用 InnoDB 引擎，开启事务后就能很自然地把这些写操作用事务包起来。

2. 数据库设计：先把业务关系理清楚

2.1 核心实体与业务闭环

数据库是这套系统的地基。我设计表结构时，先画了业务闭环，再反推需要哪些表和字段。整个过程可以这样描述：

采购人员到货后录入入库单，入库单里有多条商品明细，每一条明细对应一个商品 SKU，入库同时增加库存表中对应商品的库存数量，并且往库存流水表里写一条“入库”记录；销售人员下单发货时，创建出库单和明细，库存表中对应商品数量扣减，流水表里写一条“出库”记录；整体库存表只用来冗余汇总当前数量，流水表才是判断数据是否正确的依据。

按照这个闭环，最少需要这几张表：

• 商品表（goods）：存每个 SKU 的基础档案信息。
• 供应商表（supplier）：入库单关联的往来方。
• 入库单表（inbound_order）+ 入库单明细表（inbound_item）：一张主表对应多张明细表，记录每次采购入库。
• 出库单表（outbound_order）+ 出库单明细表（outbound_item）：记录每次销售出库。
• 库存表（stock）：保存每个商品当前最新的库存数量，这是冗余字段，但它能直接支撑列表展示和查询，不用每次动态汇总流水。
• 库存流水表（stock_flow）：记录每一笔库存变化的明细，包括变化前数量、变化后数量和来源单据号。
• 用户表（user）：存登录账号和角色，系统虽然小，但至少要有谁能操作、操作人是谁这个审计能力。

2.2 商品、库存、流水三张表的设计

商品表是整个系统的数据基础，我最初的版本漏掉了两个字段，后面又补上了，现在看看设计得非常必要。第一是商品编码，这个字段必须唯一，且一旦创建尽量不要修改，因为后面所有单据明细都通过商品编码关联到历史记录；第二是预警库存量，用于在列表页做低库存提醒。

商品表的核心字段如下：

这里的 decimal(10,2) 是故意为之，价格不能用 float，原因在后面“金额精度”部分单独说。

库存表结构简单，但有一处需要提前想好：商品表和库存表是一对一关系，还是先建一条记录再更新？我建议在创建商品时同步初始化一条库存记录，数量为 0，这样后面入库出库时永远用 UPDATE 操作，不需要每次判断“记录存不存在”，能减少很多分支逻辑。

库存表字段：id、goods_id、quantity、updated_at，其中 goods_id 唯一索引。

流水表是这套系统排查数据问题的灵魂。我设计它的核心思路是：单看库存表能知道“现在有多少”，但永远不知道“为什么变成这个数”，流水表就是补齐这个“为什么”。每次入库、出库、手动盘盈盘亏调整，都必须写一条流水。

流水表字段：

我在 before_qty 和 after_qty 上吃过亏，最初版本这两个字段没加，结果有一天库存表被人手动 UPDATE 改错了一个数字，我根本查不出来是从哪笔操作开始的。加了变动前和变动后数量以后，只要对比相邻流水号的 after_qty 和下一行 before_qty 是否相等，就能快速定位断档。

2.3 订单表结构和其他辅助表

入库单主表字段包括：入库单号、供应商 id、操作员 id、备注、创建时间。明细表包括：入库单 id、商品 id、数量、采购单价、金额小计。

一个容易忽略的细节是入库单号不要直接用自增 id 当单号对外展示。一是用户习惯看到“RK20250101001”这种有业务含义的单号，二是在出库单里我们还要引用入库单号做来源追溯，带前缀的单号在 Excel 对账时更好辨认。我的单号生成规则是：业务前缀 + 日期 + 三位流水号，比如 RK20250101001，当天流水号满了就自动重置为 001，同时用数据库唯一索引保证不重复生成。

出库单表结构和入库单类似，只是把供应商换成了客户名称。有朋友问为什么不是客户表？小系统我建议先用一个 varchar 字段存客户名称，不要为了扩展性一开始就建客户主数据表。等以后有固定客户，再单独拆客户表也不迟，否则前期录入成本会拖慢整个系统的上手速度。

另外我设计了一张 system_config 表，就两个字段：config_key、config_value，用来存系统名称、默认供应商之类的配置项。进销存系统看起来是业务系统，其实也有不少界面参数要改，把所有硬编码的前端展示文本收拢到这张表，后期改起来不用重新发版。

3. 后端业务逻辑：入库、出库、库存更新的实现

3.1 接口清单和项目分层

这套系统的后端接口数量控制在 15 个以内，按模块划分为认证、商品、入库、出库、库存、统计六个部分。

认证相关：登录、获取当前用户信息、退出登录；商品模块：商品列表（分页 + 搜索）、新增商品、编辑商品、删除商品；入库模块：创建入库单、入库单列表查询；出库模块：创建出库单、出库单列表查询；库存模块：库存列表、盘点调整；统计模块：首页看板数据。

对于这种规模的系统，我不会把后端分层搞得太重，Controller、Service、Model 三层足够了。Controller 只做参数校验和封装返回格式，Service 层处理核心业务逻辑，Model 层通过数据库访问层操作表数据。重点业务逻辑全部集中在 Service 层，好处是未来如果前端换掉，api 层不用动。

3.2 入库单创建的完整实现

入库是库存增加的唯一起点，在事务处理上要非常慎重。我用伪代码把入库单创建的完整过程拆解一下，这部分是整个后端最核心的地方。

async function createInbound(req, res) { const { supplierId, items, remark } = req.body; // 1. 参数校验：items 不能为空，数量必须大于 0，单价不能是负数 // 2. 生成入库单号，例如 RK + 日期 + 三位流水号 // 3. 开启数据库事务 return await db.transaction(async (tx) => { // 4. 插入入库单主表记录 const orderId = await tx.insert('inbound_order', { order_no, supplier_id: supplierId, operator_id: userId, remark }); // 5. 遍历明细，插入入库单明细表 for (const item of items) { const amount = Number((item.price * item.quantity).toFixed(2)); await tx.insert('inbound_item', { order_id: orderId, goods_id: item.goodsId, quantity: item.quantity, price: item.price, amount }); // 6. 更新库存表 await tx.execute( 'UPDATE stock SET quantity = quantity + ? WHERE goods_id = ?', [item.quantity, item.goodsId] ); // 7. 查询当前库存，写入流水表 const currentStock = await tx.selectOne( 'SELECT quantity FROM stock WHERE goods_id = ? FOR UPDATE', [item.goodsId] ); await tx.insert('stock_flow', { goods_id: item.goodsId, change_type: 'inbound', change_qty: item.quantity, before_qty: currentStock.quantity - item.quantity, after_qty: currentStock.quantity, source_no: orderNo }); } return { orderNo }; }); }

这段逻辑里有三个关键点：

第一，事务包装。入库单、入库明细、库存更新、流水写入这四件事必须在一个数据库事务里完成。如果只插入单据而库存更新失败，或者库存更新成功但流水没写上，库存数据就失真了。

第二，SELECT ... FOR UPDATE。库存更新后我立刻把这条库存记录锁住再查询，避免并发情况下读到过期数量。虽然小型系统的并发量不大，但这个习惯是必须的，不然两个入库单同时操作同一个商品时，流水里面的 before_qty 和 after_qty 会乱。

第三，金额字段用 toFixed(2) 保留两位，但要注意这只是展示层面的技巧，真正可靠的做法是前端传过来金额就按“分”为单位，后端处理时也按整数运算，最后再转成“元”展示。

3.3 出库与库存扣减的防呆处理

出库逻辑和入库在结构上是对称的，但要额外做三件事：检查库存是否充足、扣减库存时禁止出现负数、处理部分出库的特殊情况。

检查库存是否充足最直观的做法是在事务开始前查询库存数量。但不要只查一次，因为在“查询”和“扣减”之间，别的请求可能已经把库存改了。正确做法是在 UPDATE 语句里写条件判断：

const result = await tx.execute( 'UPDATE stock SET quantity = quantity - ? WHERE goods_id = ? AND quantity >= ?', [item.quantity, item.goodsId, item.quantity] ); if (result.affectedRows === 0) { // 说明库存不足，抛出业务异常，整体回滚 throw new Error('商品库存不足'); }

这个写法利用数据库行锁保证原子性，比“先 SELECT 再 UPDATE”更安全。affectedRows 为 0 表示没有一行满足条件，也就是当前库存不够扣，这时回滚整个出库单，直接给前端返回“库存不足”的提示。

部分出库的场景也要考虑：比如客户下单 100 件，仓库里只有 80 件，业务上可能允许先发 80 件、剩余 20 件等有货再发。这种情况下我建议不要把“创建出库单”和“扣减库存”强绑定，可以在出库单明细上增加一个“已发货数量”字段，前端只允许用户对确定有货的部分做扣减操作。小型系统可以先不做预订单模式，但不要把部分出库的需求完全忽视，否则客户用一段时间后一定会提这个需求。

4. 前端页面实现：围绕 Vue 的组件化落地

4.1 工程目录、路由与状态管理

后端业务逻辑清楚之后，前端实现其实就变成了“把这些数据用合适的页面展示出来，并且操作起来顺手”的过程。我的 Vue 前端工程目录结构是这样的：

src/ api/ // 接口封装，按模块拆文件 goods.js inbound.js outbound.js stock.js dashboard.js assets/ components/ // 公共组件 PageHeader.vue GoodsSelector.vue GoodsSkuTable.vue router/ index.js stores/ user.js app.js views/ login/ dashboard/ goods/ inbound/ outbound/ stock/ statistics/

组件拆分的原则很直接：一个页面里被重复使用的部分就抽成组件。我最开始写的时候，入库单和出库单页面都用到了“商品明细编辑表格”，表格里每一行要选择商品、填数量、填单价、自动计算金额，这个组件我在入库和出库两个页面里各写了一遍，后来统一抽成了 GoodsSkuTable，改 bug 时只改一处，节省了很多时间。

路由设计我用了嵌套路由。整体布局是一个 Layout 组件，内部包含侧边菜单和主内容区，各个业务页面挂在 Layout 下面。路由配置里设置了一个前置守卫，检查本地是否有 token，没有就强制跳到登录页，这个功能看起来简单，但没有它系统就会变成“任何人打开页面都能看到所有数据”。

4.2 通用列表页的实现套路

商品管理页是最典型的列表页面：顶部是搜索栏和新增按钮，中间是表格，底部是分页。我用代码片段展示一个列表页的核心逻辑，你会看到 Vue 3 + Composition API 在组织这类页面时非常规整。

<script setup> import { ref, onMounted } from 'vue' import { getGoodsList } from '@/api/goods' const loading = ref(false) const list = ref([]) const total = ref(0) const queryParams = ref({ pageNum: 1, pageSize: 10, keyword: '' }) async function fetchList() { loading.value = true try { const res = await getGoodsList(queryParams.value) list.value = res.data.list total.value = res.data.total } finally { loading.value = false } } function handleSearch() { queryParams.value.pageNum = 1 fetchList() } function handlePageChange(page) { queryParams.value.pageNum = page fetchList() } onMounted(fetchList) </script>

这个页面的关键点在于让搜索、分页、列表重新加载三个操作共用同一个 queryParams 对象和一个 fetchList 方法，避免把逻辑写散。搜索按钮点击时把页码强制重置为 1，否则会出现“搜索后停留在一个不存在的大页码”的问题。

商品列表表格中，商品编码列我会加一个等宽字体样式，因为编码经常要跟人电话沟通，等宽字体读起来不容易看错。状态列用 tag 标签展示“启用/禁用”，库存数量列做条件样式：库存为 0 显示红色，小于预警库存显示橙色。这些样式判断直接在表格列渲染函数里写就可以了。

4.3 入库单、出库单的明细编辑表单

出入库单页面是整个系统里交互最复杂的部分，因为要面对一个“动态表格”：供应商或客户信息是表头，商品明细是若干行，每一行都要选商品、填数量、填价格，还要在底部实时汇总总金额。

我在这个页面上用了一个相对成熟的做法：明细数据用一个响应式数组维护，每一行是一个对象；用户点击“添加行”时向数组 push 一个空对象；删除行时从数组里 splice 掉对应位置。要注意的是，Element Plus 的表格在动态添加行时，必须给每一行绑定唯一的 key，我直接使用自增的临时字段 rowKey，避免 Vue 复用 DOM 导致输入框内容错乱。

选择商品这一列，我封装了一个商品选择器组件，弹窗里支持搜索，选中后把商品 id、编码、名称、参考价回填到当前行。这里有一个组件通信的细节：子组件选中商品后，不能直接修改 prop 对象，必须通过 emit 事件把商品数据传给父组件，由父组件更新当前行数据。有些新手会直接在子组件里改 prop，运行起来偶尔能生效，但一遇到复杂交互就开始出现数据更新不同步的诡异 bug。

每行数据里，数量和单价变化时金额自动重算。我用 watch 监听每一行的 quantity 和 price，只要变化就重新计算 amount 字段。这里有个性能问题，行数上百以后逐个监听会产生大量 watcher，所以我在封装这个表格组件时实际上是在一个统一的 input 事件处理函数里做重算，而不是给每一行单独建立 watch。

4.4 库存看板与报表可视化

库存看板是这套系统最能“让用户觉得钱没白花”的页面。我在首页集成了四个统计卡片：商品总数、库存总价值、今日入库单数、今日出库单数，下面接两个图表：最近 7 天出入库趋势折线图、库存数量 Top 10 的条形图。

图表我使用的是 ECharts，Vue 封装方式没有用第三方封装库，而是自己写了一个简单的图表组件，核心逻辑是：组件初始化时创建 echarts 实例，当传入的 option 发生变化时调用 setOption 更新，组件卸载时销毁实例。

import * as echarts from 'echarts' const chartEl = ref(null) let chartInstance = null onMounted(() => { chartInstance = echarts.init(chartEl.value) chartInstance.setOption(props.option) }) watch(() => props.option, (newOption) => { chartInstance.setOption(newOption) }) onBeforeUnmount(() => { chartInstance.dispose() })

关键点有两个：第一，ECharts 实例必须在 mounted 之后创建，因为此时 DOM 才真正渲染出来；第二，组件卸载时一定要调用 dispose 释放资源，否则页面多次切换路由后会出现内存泄漏，图表响应也会变得迟钝。

仪表盘数据在后端查询时，最近 7 天数据可以用一个日期分组查询实现，前端只需要把查询结果转换成 ECharts 需要的格式。我建议这种统计接口单独做一张汇总查询，不要在前端对明细数据做 reduce，数据量大了以后浏览器会卡。

5. 项目落地过程中的高频问题和避坑经验

5.1 商品编码与 SKU 设计

这个坑我差点踩进去却没完全避开。最初设计商品表时，商品就是商品，名称加个型号字段就完事了。结果客户在录入一款 T 恤时发现，同一款 T 恤有红、白、黑三个颜色，每个颜色还有 S、M、L 三个尺码，如果他们按一个商品录入，库存就会混在一起，没法回答“黑色 M 码还有几件”。

解决方案是引入 SKU 概念：每一个颜色加尺码的组合都单独建一条商品记录，商品编码按规则拼接，比如 TSHIRT-BK-M。商品名称可以保持一致，但编码、库存、价格全部独立。听起来是这个系统变复杂了，但这是仓库管理的真实需求。

实际操作中，我在新增商品弹窗里增加了一个“批量生成 SKU”的辅助功能，用户填好基础名称和规格维度后，系统自动生成多条 SKU 记录，省的让用户一条条输入。这个功能并不复杂，后端接一个数组参数，循环插入商品表，但使用体验提升非常明显。

5.2 金额精度和浮点运算问题

进销存系统涉及大量金额计算，JavaScript 的浮点数精度问题是必须面对的。0.1 加 0.2 在控制台跑一下就知道，结果是 0.30000000000000004。如果直接把这种值存入数据库、再跟 Excel 对账，很快就会发现差了几分钱。

我的处理方式是两层配合：数据库层面，所有金额字段使用 DECIMAL(10,2)，由数据库保证精度稳定；后端与前端传参时，金额统一以“分”为单位用整数传输，需要展示成“元”时再除以 100 并用 toFixed(2) 格式化。这样把浮点运算降到最少，比较容易避免“差一分钱”的问题。

前端展示时我封装了一个 formatMoney 函数，它接受以分为单位的整数，返回带上千分位和小数点的字符串：例如 12345 显示为 123.45。这个函数被用在订单金额列、库存总价值、报表汇总等多个地方，统一来源，避免各写各的格式化逻辑。

5.3 分页、搜索和列表刷新

分页搜索最常见的 bug 就是删除列表某一行后，当前页码超出总页数上限，导致表格出现空白。比如用户在第 3 页，这一页只有 1 条数据，把这 1 条删掉以后，总页数从 3 变成 2，但前端 queryParams.pageNum 还停留在 3，请求过来自然查不到数据。

我在删除接口拉取最新列表之后，加了一步判断：

async function handleDelete(row) { await deleteGoods(row.id) const maxPage = Math.max(1, Math.ceil((total.value - 1) / queryParams.value.pageSize)) if (queryParams.value.pageNum > maxPage) { queryParams.value.pageNum = maxPage } fetchList() }

搜索防抖也是一个细节。商品列表页面我监听了 keyword 的变化，但不会每次输入都发请求，而是用了一个 300ms 的防抖函数。不然用户输入一个字，请求一次，中文输入法组合拼音时还会触发无效请求，这个体验非常糟糕。

5.4 库存一致性和数据回滚问题

进销存系统上线后我建议开发一个“库存校验”脚本，定期比对：每个商品当前的库存表数量，是否等于该商品所有入库流水正向变动之和加上所有出库流水负向变动之和。这个脚本我只用了一条 SQL 就能实现：

SELECT s.goods_id, s.quantity AS stock_qty, SUM(CASE WHEN f.change_type = 'inbound' THEN f.change_qty WHEN f.change_type = 'outbound' THEN f.change_qty ELSE f.change_qty END) AS flow_qty FROM stock s LEFT JOIN stock_flow f ON f.goods_id = s.goods_id GROUP BY s.goods_id, s.quantity HAVING stock_qty != flow_qty;

只要结果不为空，就说明某笔操作没有完整执行——要么库存更新了但流水没写，要么流水写了但没更新库存。这个校验脚本我放在了一个管理页面里，手动触发，因为自动跑定时任务在小系统里容易被忽视，手动触发反而简单直接。

6. 部署与后续维护建议

6.1 前端打包与 Nginx 配置

系统开发完成后，前端通过 Vite 直接打包成 dist 静态目录，丢到 Nginx 上就能跑。我第一次部署时踩了个经典坑：直接配置完 root 和 index 就访问，结果是首页正常，但刷新二级页面全部 404。

原因很简单，Vue Router 使用了 history 模式，页面 URL 类似 /goods/list，Nginx 找不到对应的静态文件就报 404。解决办法是配置 try_files，把所有路径都回退到 index.html：

location / { root /usr/share/nginx/html; index index.html; try_files $uri $uri/ /index.html; }

另外还要在根目录放一个 .env.production 文件，把接口地址换成生产环境的域名。前端代码里所有接口调用都走一个 api 基础路径，不要散落在各个页面里写死地址，否则上线改接口地址要全局替换，实在痛苦。

6.2 数据备份与日常检查

小型仓库系统很可能没有专职运维，数据库备份这件事必须提前自动化。我在服务器上写了一个简单的 shell 定时任务，每天凌晨执行 mysqldump 导出 SQL 文件，保留最近 30 天，然后同步备份到另一个目录。

日常检查比备份还重要，因为你总不能等数据丢了再恢复。我建议每周看一次后台的“库存校验”结果，顺便看一眼流水表里有没有异常的负库存记录。负库存通常说明出库接口校验逻辑有漏，也可能是有人手动改了数据库，早发现比晚发现好处理得多。

6.3 从这套系统还可以怎么延伸

系统做完以后，客户会自然提出更多需求，这些需求完全可以在当前表结构上延伸。比如给商品表增加条形码字段，配合扫码枪就能在出入库时直接扫码录入，不需要手输编码；比如增加 Excel 导入导出，客户可以把旧系统里的商品档案批量迁移过来；比如增加操作日志表，把用户登录、新建订单、修改商品这些关键动作都记录下来，方便追溯。

如果要扩展多仓库，只需要在 stock 表和库存流水表上都增加一个 warehouse_id 字段，同时让入库出库单也带上仓库属性，查询时按仓过滤即可。这套改造在当前数据结构上做起来比较平滑，不会推倒重来。

做这类管理系统，我个人最深的体会是：系统能不能跑起来，取决于前后端代码的质量；系统好不好用，取决于表结构和业务逻辑是否贴近真实场景。一套仓库进销存管理系统真正的价值，不是那个漂亮的表格页面，而是每一次出入库操作都能准确反映到库存数量上，每一笔数量变化都能在流水里找到源头。这中间没有太多需要炫技的地方，需要的是把每一步业务逻辑老老实实设计清楚，把每一处防呆校验做扎实。技术选型上选 Vue 还是 React、后端用 Node 还是 Java，都可以按团队情况换，但库存一致性这个事情，做得稳，比做得炫更重要。