仓库主管把 ERP 截图发过来，显示某型号可用库存 1200 件。拣货员跑到货架，第三层只剩两箱，还有一箱在半路，一箱被质检锁了。这种对不上，八成不是系统算错，而是「实时」这两个字被理解得太宽。
大部分进销存里说的实时库存查询，查的是账面可用量，不是货架上的实物。真正要看的字段至少三个：现存量、锁定量、在途量。可用量等于现存量减去锁定量，只盯第一个数字，拣货一定出问题。
先确认查询口径，再谈准不准
同一个 SKU 在总仓视图是 1200，切到库位视图可能只有 300。有的系统默认按仓库汇总，有的按库位。页面上一般有个维度下拉，很多人没注意。查之前先问清楚：这个数含不含待出库、含不含质检冻结、含不含调拨在途。
刷新慢不等于数据旧
前端页面 30 秒自动刷新一次，看着挺实时。可后台如果是每 10 分钟跑一次汇总任务，页面刷得再勤也是旧数。判断方法很简单：改一笔单据，立刻点手工刷新，看数字动不动。不动，问题在汇总任务；动了，问题在缓存。
缓存常见的坑是 Redis 里存了整张库存表。单据审核后只清了列表缓存，没清详情缓存，于是列表新、详情旧。排查时拿接口返回的原始 JSON 和页面数字对比，一眼就能看出来。
高频轮询反而拖慢实时性
有的团队为了追求实时，让前端每 2 秒查一次全仓库存。几百个 SKU 一起查，数据库直接被拖住，最后所有人都慢。更稳的做法是按需查：先给汇总数，点进某个 SKU 再拉明细；或者审核单据时推一条消息，前端收到再刷新。
如果你只是想在仓库现场用手机扫码看库存，重点不是刷新频率，而是离线缓存和库位准确性。先把盘点差异压到千分之三以内，再谈秒级同步。数字本身不准，实时到毫秒也没意义。