做药店中药仓库管理系统这件事，是我帮一个做医药流通的朋友处理库存管理需求时真正动起来的。当时他们还在用Excel记录几百种中药饮片的进销存，效期、批次、养护记录全靠人工翻台账，一到盘点就头大。我调研了一圈之后，定了thinkphp+vue这套技术栈来做整个系统，最后交付的版本跑得很稳，这里把设计与实现的过程完整复盘一遍，给同样准备做仓库管理类系统的朋友一个参考。
这套系统本质上解决的是中药仓库管理中的三个核心问题：批次级库存追踪、效期预警、以及采购入库到出库领用的全流程记录。适合的业务场景是单体药店、中小型连锁药店以及中药饮片批发商，技术上则是一个标准的thinkphp后端 + vue前端前后端分离项目。
我把整个设计和实现拆成了几个部分来讲：先聊需求分析和业务建模，再讲技术选型与项目架构，然后重点拆解数据库设计和核心接口实现，最后是前端落地、部署上线和踩坑记录。每一步都会给出关键代码和设计理由，希望能帮你少走弯路。
1. 项目启动前：先理清中药仓库管理的真实痛点
1.1 中药仓库和西药仓库管理为什么差别很大
很多朋友一听"仓库管理系统"，第一反应是把常见的小商品进销存拿过来改改就能用。但真正深入中药仓库的日常操作之后，你会发现完全不是一回事。
西药大多是标准化生产的成品药，一个SKU对应一个批号，有效期明确，包装规格相对统一。中药饮片则完全不同：同一味药材可能来自不同产地、不同供应商、不同采收季节，质量差异很大，必须按批次管理；而且中药饮片对存储条件敏感，容易受潮、虫蛀、走油，必须有养护记录和效期管理；再看销售和处方环节，中药处方抓药经常一剂需要十几味药材，每味几克十几克，但入库时却是按公斤来的，这就牵扯到单位换算。
所以说，中药仓库管理系统的核心不是简单的增删改查，而是如何精细地追踪每个批次的药材从哪来、放在哪、什么时候到期、哪个批次先出库。用面向普通商品的库存逻辑去套中药业务，一定会出问题。
1.2 业务流程梳理与功能清单
动手写代码之前，一定要把业务流程捋清楚。我一般习惯先画一遍实际业务串联图，再转成功能清单。这个项目里，核心业务链路是这样的：
供应商供货，采购员做采购单，药材到货后验收，验收合格后入库并生成批次库存记录；日常销售或处方抓药时，从批次库存中按先进先出原则出库扣减；库存不足或效期临期时提醒采购和养护人员；仓库管理员定期生成养护任务，记录养护结果；最后所有操作都有流水记录，方便追溯。
基于这个链路，我把系统划分为六大功能模块：
- 基础数据管理：药材字典、药材分类、供应商档案、仓库货位
- 采购管理：采购单创建、审批、到货验收、采购退货
- 库存管理：批次库存查询、效期预警、库存盘点、报损出库、库存流水
- 出库管理：处方/销售出库、领用出库、出库单管理
- 养护管理：养护计划、养护任务执行与记录
- 系统管理：用户、角色、权限、操作日志、数据字典
功能范围不是拍脑袋定的，而是把仓库管理员、采购员、药师、店长这几个角色的日常工作逐一列出来，再合并去重得到的。这里要记住一句话：需求阶段多花一天，开发阶段少返工一周。
2. 技术选型：为什么是ThinkPHP + Vue
2.1 后端用ThinkPHP的现实考量
技术在真实项目里从来不是越新越好、越复杂越好，关键是团队熟不熟、维护成本高不高、和现有业务系统好不好对接。
这套系统后端我选了ThinkPHP 6.0.12 LTS版本，原因有几个：
第一，中小型团队甚至个人开发者对ThinkPHP非常熟悉，文档齐全，生态成熟，出了问题能快速找到解决方案。LTS版本意味着长期维护，安全性有保障。
第二，ThinkPHP内置了ORM、路由、中间件、验证器、命令行等常用能力，对于进销存这种典型的管理信息系统来说开发效率很高，不需要额外引入重量级框架。
第三，性价比。药店管理系统本身的并发量并不高，一台便宜的单机服务器跑PHP-FPM完全够用，不需要为了追求高大上而上微服务、消息队列这种东西，那是给自己挖坑。
后端整体的分层，我按ThinkPHP官方推荐的模式来组织：Controller负责接收请求和返回响应，Service层负责业务逻辑，Model层负责数据操作，Validate负责参数校验。小项目里很多人图省事把业务逻辑全写到Controller里，但一旦需求变多、逻辑变复杂，Controller会膨胀得非常快，后期维护会很痛苦。
2.2 前端用Vue的取舍
前端选了Vue，更具体地说是Vue 3 + Element Plus + Vite + Pinia + Vue Router + Axios这套组合。
为什么用Vue而不是JQuery服务端渲染模板？核心原因是交互体验。仓库管理虽然以表格和表单为主，但还是有不少需要即时反馈的地方，比如库存检索、出库单动态添加明细、效期预警的图表展示，这些用SPA来做会很顺手，而且维护起来比在HTML里拼字符串干净得多。
Vue 3的Composition API对于复杂业务组件的代码复用非常友好。比如多个模块都要用"药材选择器"这个通用功能，用组合式函数抽取出来之后，到处都能复用，不用再复制一大段options代码。如果你还在用Vue 2的Options API写大型项目，我建议尽早切换，写完这个系统你会发现两者的组织效率差距确实很大。
UI组件库用了Element Plus。前面热词里提到的"自动导入ElementPlus"、"elmessage未定义"这些坑，后面我会专门讲。选Element Plus理由很简单：组件齐全、文档清楚、企业管理系统尤其适合，表格、弹窗、表单、日期选择这些高频组件都有现成方案。
2.3 前后端分离的联调约定
前后端分离不只是技术上分开，协作方式也要有明确约定。这个项目从一开始就定了几条接口规范：
- 所有接口统一返回JSON结构：{ code: 0, msg: "success", data: {...} }，成功时code为0，失败时code为业务错误码
- 认证用JWT，请求头带Authorization: Bearer
- 分页参数统一是page和limit，分页返回结构统一是{ total, list }
- 所有时间字段统一用Y-m-d H:i:s格式
- 涉及金额和数量的字段，由后端统一用decimal类型传给前端，前端不参与精度运算
这些约定看着琐碎，但能省掉无数联调时的扯皮。我见过太多前后端各搞一套返回格式，最后联调阶段天天改代码的例子。提前定好规范，大家按规矩做事，开发效率会高很多。
3. 数据库设计与核心业务实现
3.1 表结构设计的核心思路
数据库设计是整个系统的地基，我前前后后改了三个版本才定稿。核心表大概有这些：
- 药材字典表 medicine：id、名称、编码、拼音码、分类、规格、库存单位、采购单位、换算比例、养护条件、默认保质期、库存上下限
- 供应商表 supplier：id、名称、联系人、电话、地址、资质信息
- 批次库存表 batch_stock：id、药材ID、批次号、供应商ID、货位ID、数量、单位、生产日期、有效期、入库时间、状态
- 库存流水表 stock_log：id、药材ID、批次ID、变动类型（入库/出库/报损/盘点调整）、变动前数量、变动数量、变动后数量、关联业务单号、操作人、操作时间
- 采购主表 + 采购明细表：purchase_order 和 purchase_order_item
- 出库主表 + 出库明细表：stock_out 和 stock_out_item
- 用户/角色/权限表：user、role、permission 及关联表
- 操作日志表 op_log
设计时几个关键决策，我展开说一下。
中药必须做批次管理。为什么？因为同一味药材不同批次的效期、质量、供应商都不同。如果只按药材汇总库存数，会出现一个严重问题：系统显示有库存，但实际这批药材已经过期了。批次库存表把数量精确到每个批次，出库时才能按先进先出(FEFO)原则选择最先到期的批次扣减。
设计一个统一的库存流水表。所有库存变动都往这张表里写，采购入库写一条入库流水，销售出库写一条出库流水，盘点调整也写一条。全链路可追溯，审计的时候只要查这一张表就行，不用去翻无数张业务表。这也是和普通进销存系统一个很重要的区别。
药材字典里的单位和换算比例单独设计。举个例子，有的药材入库按公斤记录，但处方抓药按克出库。我加了一个单位和换算比例字段，入库50公斤，出库时换算成50000克，所有业务操作前先统一到一个基准单位，避免搞混。
3.2 库存变动核心代码实现
数据库设计好之后，接下来是库存变动的核心逻辑。这部分是整个系统的灵魂，出库扣减、入库增加，每一行代码都要谨慎。
以出库为例，核心流程是：校验库存，按先进先出选择批次，扣减批次库存，写入流水。整个流程必须在一个数据库事务里完成。思路大致是这样的：
public function outStock(array $items, string $bizType, string $bizNo) { Db::startTrans(); try { foreach ($items as $item) { $medicine = Medicine::where('id', $item['medicine_id'])->lock(true)->find(); if (!$medicine) { throw new \Exception("药材ID:{$item['medicine_id']}不存在"); } // 这里先汇总校验，防止批次分散导致误判 $totalStock = BatchStock::where('medicine_id', $item['medicine_id']) ->where('status', 1) ->sum('quantity'); if ($totalStock < $item['quantity']) { throw new \Exception("药材:{$medicine['name']}库存不足"); } // 先进先出扣减批次库存 $remainingQty = $item['quantity']; $batches = BatchStock::where('medicine_id', $item['medicine_id']) ->where('status', 1) ->where('quantity', '>', 0) ->orderBy('expiry_date', 'asc') ->orderBy('created_at', 'asc') ->lock(true) ->select(); foreach ($batches as $batch) { if ($remainingQty <= 0) break; $deductQty = min($batch->quantity, $remainingQty); $batch->quantity -= $deductQty; $batch->save(); StockLog::create([ 'medicine_id' => $item['medicine_id'], 'batch_id' => $batch->id, 'change_type' => $bizType, 'before_qty' => $batch->quantity + $deductQty, 'change_qty' => -$deductQty, 'after_qty' => $batch->quantity, 'biz_no' => $bizNo, 'operator_id' => $this->uid, 'remark' => $item['remark'] ?? '', ]); $remainingQty -= $deductQty; } } Db::commit(); } catch (\Exception $e) { Db::rollback(); throw $e; } }这里的要点有几个：首先每读取一次库存就加锁，避免并发下超卖，行锁比表锁代价小很多；其次查询时按 effective_date 排序，先到期的批次先扣减，符合药品先进先出的原则；再次每次扣减都记录变动前后的数量，以后出任何问题都能追溯是谁在什么时候动了库存。
入库逻辑类似，但要注意采购单可能分批到货，所以批次号生成规则要保证唯一。我采用"日期+随机数"，例如20250615001，每天从001开始递增，简单明了。入库时还要同步更新药材字典的最近入库时间、最近供应商等信息，方便后续采购决策。
3.3 效期预警和养护任务实现
效期预警是一个必须有但不能做得太复杂的模块，我采用了查询时动态计算的方式，不额外存冗余字段。
每味药材的有效期可能不同，有的中药饮片保质期36个月，有的只有12个月。我在药材字典里配置了默认保质期。预警规则就两条：临期90天提醒采购和仓库不再补货，临期30天强制要求报损或特别审批出库。
具体实现是写一个查询接口，按每个批次的有效期减去当前天数，打上"正常/临期/过期"的标记。因为批次量不大，每次全量计算一遍也没压力。同时利用ThinkPHP的自定义命令行任务，每天凌晨扫描一次临期批次，生成待办通知写入消息表。这里有一个重要的细节：如果药店的经营规范有GSP要求，临期和过期批次必须人工复核确认之后才能从系统里销账，不能自动删除，所以我的design是保留历史状态，只在状态字段里做流转。
养护任务的逻辑则是把"哪些药材需要定期检查"配置到药材字典里，然后系统按设置的时间间隔自动生成任务。比如易受潮的药材，养护周期设为15天，每到周期就生成一条待养护记录，仓库管理员执行完养护后填写结果，系统记录日志。这个功能实现起来不复杂，但对实际管理帮助非常明显。
4. 前端Vue落地与联调细节
4.1 前端项目结构与路由权限设计
前端项目用的Vite初始化，目录结构大致这样的：
src/ api/ # 接口请求封装 assets/ # 静态资源 components/ # 通用组件 composables/ # 组合式函数 router/ # 路由配置 store/ # Pinia状态 views/ # 页面组件 utils/ # 工具函数路由权限这块，我用了最通用的方案：路由守卫+动态权限控制。用户登录后拿到角色权限列表，前端根据权限动态生成菜单和路由。Vue Router的 beforeEach 守卫里做三件事：判断token是否存在、判断是否已拉取用户信息、判断当前路由是否在权限列表里。没有权限就跳到403页面，没登录就跳到登录页并带上回跳地址。
router.beforeEach(async (to, from, next) => { const token = localStorage.getItem('token') if (!token) { if (to.path === '/login') return next() return next(`/login?redirect=${encodeURIComponent(to.fullPath)}`) } const userStore = useUserStore() if (!userStore.userInfo) { try { await userStore.getUserInfo() const hasPermission = userStore.hasPermission(to.meta.permission) return hasPermission ? next() : next('/403') } catch (e) { userStore.logout() return next('/login') } } return next() })这里要注意，路由权限如果全靠前端做是不安全的，黑客可以通过改前端代码绕过。所以后端接口仍然要校验权限，前端控制只是优化体验，真正的安全防线必须放在后端。
4.2 表单校验、表格展示与接口封装
管理系统的书写量基本都在"先做表格再点编辑"这种模式里。我基于Element Plus封装了一个PageTable组件，把搜索条件、数据表格、分页器给包在一起，页面里只要传配置就能渲染。好处是写新页面很快，坏处是自由度下降。封装了一定的通用能力之后，开发效率提升非常明显。
表单部分，Element Plus有 Form 校验能力。但要注意，Rules的校验触发时机要配置对。我是这样处理的：必填字段在 blur 和 change 时都触发，数字字段统一转成数字再校验范围，日期字段要注意 format 问题。
Axios的封装里，响应拦截器统一处理 code 不为 0 的错误提示，HTTP 401 时自动跳登录页并清除本地状态。还有一点，请求拦截器里要加上loading配置，避免用户在操作时重复提交。像出库单这种重要的操作，按钮在提交后要立即做 loading 置灰，防止同一张单子被提交两次。
接口这块再补一句thinkphp监听SQL的常见位置问题。经常有人问，我在哪里能看到系统执行了什么SQL？ThinkPHP中一般建议注册Db::listen回调，放在 service-provider 或者公共函数里统一处理。比如在 app/provider.php 里绑定一个事件监听，输出到日志文件，方便排查慢查询和异常SQL。
// app/provider.php 或者中间件中 Db::listen(function($sql, $time, $explain) { // 写入日志文件，线上环境可以只在debug模式开启 Log::channel('sql')->info("[$time ms] " . $sql); });4.3 联调阶段翻车实录
前后端联调时最容易出问题的几个点，这里列一下，全部是我实际踩过的：
第一是跨域。ThinkPHP后端默认不允许跨域，Vue开发服务器在 localhost:5173，后端在 localhost:8088，直接请求肯定报错。我的方案是在后端写一个全局中间件，配置允许的跨域来源、请求方法、请求头，并在处理OPTIONS预检请求时直接返回200。生产环境如果前端和后端部署在同一域名下，就不用这么费劲了，nginx反向代理就能解决。
第二是时间格式化。PHP返回的时间字段是2025-06-15 10:30:00，前端如果直接用 new Date() 去格式化，有的浏览器会报Invalid Date。因为iOS对带空格的日期格式解析有兼容问题。我在Axios的响应拦截器里统一做一层数据清理，遇到日期字符串就替换成T分隔再处理，从源头规避各种兼容问题。
第三是Element Plus组件的自动导入问题。用unplugin-auto-import和unplugin-vue-components可以自动按需引入组件和API。但要注意，自动导入只负责模板里的组件，像ElMessage、ElMessageBox这种直接通过JS调用的API，如果没在配置文件里显式引入对应样式，会出现"为什么elmessage还是提示未定义"或者样式丢失的问题。需要在vite配置的ElementPlusResolver里设置importStyle: 'sass'并引入对应样式变量，或者干脆在main.js里完整引入Element Plus的样式，图个省心。
我在项目里最终选择了手动按需引入主要组件，ElMessage直接全量引入，这样一个万金油方案最稳定。很多一键生成的工具配置文档不会主动告诉你这些坑，碰到了只能靠经验。
5. 核心模块实操：从采购到出库的完整链路
5.1 采购入库的完整流程实现
采购入库是库存数据的源头，如果这块设计得不严谨，后面全盘崩。我的实现流程是这样的：
第一步，采购员创建采购单，填写供应商、采购日期、期望到货日期，然后逐行添加采购明细，每行选择药材、填写采购数量、采购单价。提交后单据状态是"待审批"。
第二步，店长或采购负责人审批。审批通过后状态变更为"已审批"，此时系统锁定采购数量，不允许随意修改。这个环节看似多余，但在实际药店管理中非常有用，能防止采购人员私自从供应商加购一些不合理的品种。
第三步，到货验收。仓库管理员在系统里点"验收"，输入实际到货数量，如果和采购数量不一致，可以写差异原因。验收完成后系统自动生成入库单，按实际到货数量生成批次库存记录。批次号设置为当天日期加序号，比如20250615001批次，记录生产日期、有效期、进货价、供应商。
第四步，系统自动写入库存流水，并把本次入库关联到采购单和供应商上，形成完整的溯源链条。
这里有个细节：中药饮片验收时需要填养护条件、生产批号等信息，这些字段我直接从药材字典带出来，减少了手工录入。同时入库操作发生时，系统会检查是否已有同品种同批次的库存记录，如果有不会自动合并，而是要求人工确认能否合并。为什么要这样？因为中药饮片的"同批次"定义非常严格，必须是同一个生产批号，如果仅凭外观相似就合并库存，未来追溯会出大问题。
5.2 出库单与处方抓药的联动实现
出库模块里最有挑战性的是处方抓药场景。这个系统面向的主要场景是药店销售，处方流程是这样的：药师录入处方，系统按处方中的药材明细自动生成出库单，保存时自动检查每个药材的库存是否充足，如果库存不足，直接提示缺哪味药、差多少数量，方便药师决定是否联系患者换药或调货。
如果库存充足，出库单提交后，系统生成一个预占扣减记录。注意这里做了个"锁定库存"的设计，避免两个药师同时操作，明明库存还有，却都被提示不足。
具体实现，我在 batch_stock 表上加了 locked_quantity 字段。出库单创建时先把数量加到锁定值上，真正出库时扣掉库存和锁定值，未完成出库但超过一定时间的单据自动释放锁定库存。
这个细节在一开始设计时我漏掉了。第一版系统直接做减法，结果遇到过这种情况：两个药师同时给两个患者开同一味药，系统显示库存5公斤足够，但两个人同时点了提交，一个成功一个失败，患者体验很差。后来加上了锁定机制，这个问题才彻底解决。
另外，出库明细里我还会记录处方号，这样就能回溯"这批药是哪位患者、哪个处方用掉的"，在发生药品质量问题时能第一时间完成药品召回和患者通知，GSP审查时这就是救命功能。
5.3 库存盘点与报损流程
中药仓库的盘点和普通仓库最大的区别，在于中药饮片会发生"自然损耗"——药材水分蒸发会减少重量，储存过程中可能生虫而被丢弃。系统里的库存数量和实物数量往往有差异，所以盘点模块不仅要能记录差异，还要能说明差异原因。
盘点方案我实现了两种：盘点单模式和库存调整单模式。
盘点单模式是定期做全盘或抽盘，盘点单状态是"草稿"时，盘点人员在里面录实盘数量，录完后提交审核。审核通过后系统自动生成盘盈盘亏单，并调整库存。
库存调整单模式适用于日常小规模调整，比如某味药受潮扔了一公斤，直接在系统填一个报损单，说明原因、关联药材和批次、填数量，审核后自动出库扣减。
这两种模式本质上都走同一条底层链路：创建单据、审核、更新批次库存、写流水。我在Service层抽取了一个统一的库存变动方法，盘点、报损、采购入库、处方出库都调同一个方法，保证底层逻辑一致，而不是每个模块各自写一套扣减代码。这也是为什么我刚才说Service层抽取业务逻辑很重要，如果这些逻辑散落在Controller里，根本没法做到统一管理。
权限在这一块也必须严格。库存调整、报损单这类操作必须要高权限角色才能审核，我用了ThinkPHP自带的权限中间件，在路由配置里指定权限标识，比如 stock:adjust:audit 只有管理员角色能访问。为了防止越权操作，后端每个接口都要校验，不能只在前端做权限控制。
6. 常见问题与排查技巧实录
6.1 库存负数、并发超卖和数据显示异常
这个问题几乎每个做进销存系统的人都会遇到。我先把我踩过的坑按频率排个序：
库存变负数。排查下来最常见的原因是并发操作没加锁，两个请求同时读到库存为1，同时扣减成了负库存。解决办法是查询库存时加上 ->lock(true)，这样MySQL会锁定这行数据直到事务结束。另外一个原因是流程上有些出库单处于草稿状态但已经扣了库存，用户反复提交导致的。这个通过锁定库存机制解决了。
超卖。和库存负数同源，也是并发问题。除了行锁之外，我在出库前做了一次汇总库存预检，两重校验基本能挡住99%的问题。剩下的1%比如极端高并发场景，还可以通过数据库层的库存字段非负约束来兜底。
分页数据错乱。最容易出现的情况是列表查询时没有固定排序条件，数据库返回顺序不稳定，翻页重复或漏数据。解决办法是排序字段一定要唯一，一般用主键ID做最终排序条件，保证分页稳定。
再补充一个高频问题：时间查询范围不对。PHP默认时区可能是UTC，而中国要用东八区，如果没设置date_default_timezone_set('PRC')，查询"今天"的数据会凭空多出8小时。这个问题排查起来很隐蔽，因为不是所有功能都会出错，只有依赖日期统计的时候才暴露。
6.2 ThinkPHP和Vue项目日常开发常见的坑
我在开发这套系统时，遇到的比较典型的坑列个表格，方便你对照排查。
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| 前端显示正常，但请求报401 | token过期或未携带Authorization头 | 检查Axios拦截器，确认请求头设置正确，服务器时间是否偏移 |
| 后端接收不到PUT/DELETE请求参数 | PHP默认对application/x-www-form-urlencoded以外的content-type解析受限 | 前端统一用POST+JSON，或后端配置json body解析 |
| 表单提交后提示"数据错误" | 后端验证器校验失败但前端未显示具体错误信息 | 后端统一返回出错字段名+原因，前端在表单中高亮显示 |
| 上传图片返回404 | 路由配置未开放public上传目录访问权限 | 检查nginx或apache的静态资源alias配置 |
| 部署后刷新页面404 | 路由是history模式，nginx未配置try_files | nginx配置 location / { try_files $uri $uri/ /index.html; } |
| ThinkPHP连不上MySQL | 端口、账号、socket方式不对 | 检查.env文件，确认DB_HOST、DB_PORT配置 |
| 分页查询很慢 | 大数据量下未走索引 | 给外键、日期、状态字段加索引，用explain检查 |
6.3 部署上线的主要步骤
开发完成后，部署上线也是一个高频问题。我的做法分三步走：
第一步，后端部署。购买一台云服务器，安装Nginx+PHP-FPM+MySQL。把ThinkPHP项目代码放到站点目录，配置好.env数据库连接信息，确保storage目录有写权限。Nginx配置需要注意把站点根目录指向public文件夹，并配置好PHP-FPM的fastcgi_pass参数。
第二步，前端部署。Vue项目执行npm run build生成dist静态文件目录。有两种部署方式：第一种是直接把dist目录放到后端Nginx站点下，用同一个域名访问，这种方式最简单，不会遇到跨域问题；第二种是分开部署，前端静态文件放CDN或独立服务器，后端接口跨域调用，这种方式需要额外配置跨域中间件。
第三步，日志与告警。上线之后把ThinkPHP的日志级别调整为生产模式，关闭debug输出。同时配置sql日志和错误日志轮转，防止磁盘爆满。我还会写一个简单的定时任务，每天跑一遍效期预警扫描并推送消息到运营群，让系统从"被动记录"变成"主动提醒"。
稳定运行后，这套系统在朋友药店的日常管理中使用率非常高，批次效期预警尤其受欢迎，仓库管理人员再也不用翻柜子挨个看有效期了。整个项目从需求梳理到最后上线，前后大概用了一个月左右的工作量，如果你已经有一定前后端基础，这个周期是可复现的。
最后分享一个让我改进最大的经验：无论系统做得多花哨，数据准确性永远是第一位的。做仓储管理系统，宁可功能单一一点，也不能让库存数据出现假账。代码可以重构，功能可以迭代，但如果用户对数据的信任崩塌了，这个系统的价值基本就归零了。所以每一次库存变动都要记录全链路流水，每一笔单据都要有明确的状态流转，这些基础工作做到位了，系统才真正可靠。
