去年秋天，我帮一家郑州女装电商清理库存数据库。他们的SKU数量突破了5000个，数据库里躺着整整三年的换季库存数据。财务说要按成本价清理掉800万货值的库存，运营却坚持说其中300万是数据错误，根本没有那么多库存。两边吵了三天，最后查出真相：数据库里有734个SKU的库存数量是负数，有412个SKU被重复建档，还有超过2000个SKU的尺码数据错乱。真实库存远没有财务说的那么多，但也没有运营说的那么少。
这件事让我意识到，服饰行业的换季库存清理，本质上不是盘点仓库里有什么货，而是先搞清楚数据库里记录的是什么。
从那天起，我对“数据库存服装库存”这件事有了完全不同的理解。很多服装老板和企业管理者以为库存清理就是盘完货、打打折、发发朋友圈；实际上，如果数据库本身不干净，清库存的动作越猛，亏得越快。
核心结论是：服饰行业换季库存数据清理，必须先从数据库的底层数据治理开始，而不是从促销方案开始。 数据错了，你连该清多少、清哪些、按什么价格清都判断不了，任何营销动作都是在错误的地基上盖楼。下面我从真实场景、常见误区、判断逻辑、实操案例和取舍原则五个维度，把这个话题拆透。
先讲核心结论
换季库存清理的第一件事是修数据，不是定折扣
我见过太多服装公司一换季就急着开会定折扣：秋装打几折、冬装要不要提前上新、去年库存要不要打包甩给直播渠道。大家讨论得热火朝天，却没人先看一眼数据库里的库存数据是不是真的。
真实情况是，绝大多数服饰企业的库存数据，准确率根本达不到可以做经营决策的水平。我过去三年走访过二十多家服装企业，包含女装电商、男装批发、童装连锁和运动服饰品牌，库存数据准确率在SKU级别超过95%的，一家都没有。大部分企业的SKU库存准确率在70%到85%之间，少数夫妻老婆店，准确率甚至低于50%。
所以，如果你不先做库存数据清理，你所谓的“清库存决策”，本质上是在用一堆残缺的数据做赌博。
数据库存清理的价值不只是“清掉卖不掉的货”，更是把有效库存变成可运营资产
把数据库里那些负数库存、重复SKU、错误尺码、孤儿SKU全部修正好之后，你会发现一个反常识的事实：很多你以为“卖不掉”的库存，其实是因为数据混乱导致缺货或超卖，真正积压的货比想象中少得多。
我服务过一家深圳的时尚女装品牌，数据库显示某款碎花连衣裙有1200件库存，其中三个尺码显示断码。后来做数据清理时发现，这个SKU被重复建档了两次，每次建档都只录入了两个尺码，加起来就有了六个尺码。合并之后，这款裙子并没有断码，反而因为尺码齐全，在直播渠道清掉了900多件。如果当时直接把库存当尾货处理，至少损失4万块钱。
数据清理不是一次性工程，而是要建立“换季数据刷新机制”
很多企业意识到数据乱，就找技术团队或外部顾问做一次大清洗，把数据整理干净，然后一切照旧。结果第二年换季，又乱了。为什么？因为清理动作是“外挂式”的，没有嵌入到日常运营流程里。
真正的库存数据清理，要以换季为时间节点，建立一套固定的数据刷新机制：每季关单后三天内完成SKU归档，每季末做一次全量库存盘点，每次盘点结果录入系统后设置七天数据观察期，发现异常立即追因。这样到了真正换季清库存的时候，你手里的数据才是当时当下的真实状态，而不是三个月前的“考古数据”。
真实场景：换季库存数据到底是怎么乱掉的
场景一：一个SKU拆成几十个，数据库膨胀三倍
服装行业的SKU天然比标品多：品牌、季节、款式、颜色、尺码，随便乘一下就是几千个SKU。如果商品资料建档不规范，同一个款式在系统里常常有十几个SKU。
我见过一个真实的极端案例：某广州男装品牌，同一件白色衬衫，因为运营先后录入三次，分别叫“白衬衫”“白色衬衫”“衬衫白色”，加上每个名称下又开了S、M、L、XL、XXL五个码，最终这个单品在数据库里产生了15个SKU，库存数量也被分散统计。清理前，这个爆款的库存看起来每个SKU都只有少量货，但实际上总库存超过700件，足够支撑一个月的销售。
场景二：线上线下一盘货，但数据库是两张表
服装品牌现在基本都是全渠道销售，门店、淘宝、抖音、小程序、分销商全在卖同一批货。如果货品是共享库存，但线下门店用的是门店收银系统，线上电商用的是ERP系统，两套系统同步不及时，就会出现同一个SKU在门店显示有货，在线上显示缺货；或是线上已经把货卖了，但底层的进销存数据库还没扣减，导致线下盘点时账实不符。
去年帮一家杭州女装品牌做数据清理时发现，他们对同一个SKU的库存数据，在电商系统和门店系统之间，差异超过15%。这个差异意味着什么？意味着你定价、调拨、促销、补货的依据全部失真。
场景三：换季时“只加不删”，历史数据越积越多
很多服装企业的换季操作是：新品上架、老品打上“清仓”标记、过季商品下架。听起来没问题，但数据层面上，他们只做“状态的变更”，不做“数据的归档”。下架的商品依然躺在主库存表里，占用着SKU编号，占用着库位记录，还占用着报表统计逻辑。
三五年下来，数据库里的有效在售商品可能只有2000个SKU，但库里却堆了15000个SKU的历史数据。每次做销售汇总、库存分析、毛利测算，这些历史垃圾就把数据搅浑，报表数据越看越糊涂。
换季库存数据清理的四个常见误区
误区一：把“下架”当“清理”
这是最常见的问题。运营觉得商品下架就是清理完了，但下架只是状态改变，商品数据还留在库里。真正意义的清理是把数据从主表里归档，或者打上“过期”标志，让它不再参与在售相关的任何统计。
判断标准很简单：如果下架半年以上的SKU还能出现在在售库存报表里，那就不是清理，只是藏起来了。
误区二：把所有渠道的库存数据一锅端
很多服装企业说“我有全渠道库存数据”，实际上只是把电商的、门店的、分销商的库存数据全部倒进一张Excel表里，然后求和。这带来连锁反应：同一个货在总仓和各渠道仓之间会重复计算，渠道之间的调拨记录也没有时间戳，结果查库存总数看起来很高，实际可卖库存很少。
正确的做法是先分清每个渠道的库存类型，按“总仓可售、渠道在途、门店锁库、残次冻结、活动预留”做分类，再统一汇总。清理的前提是先分类，不是先求和。
误区三：只清“卖不动的货”，不清“数据坏掉的货”
有些库存数据错得离谱，比如负数库存、零成本库存、SKU缺失颜色尺码信息。这些数据如果不处理，系统在做补货预测时就会把负数库存当成缺货信号，自动生成采购建议，导致你重复采购一件你实际不缺的货。
我给客户做数据诊断时，发现一家服饰公司每季度都会生成一份几百行的“自动补货建议”，但里面有24%的补货建议是负数库存导致的误报。这就是典型的数据错误引发经营错误。
误区四：盲目清理历史数据，把“有分析价值的数据”也删了
换季清理不是把所有旧数据都删掉。过季的库存数据是要归档，但归档不等于删除。销售记录、价格历史、颜色尺码销量比例等数据，是未来做采购预测和商品企划的重要参考。如果手一哆嗦全删了，就等于把企业的经营记忆抹掉了。
清理和删除是两件事：清理的核心是“整理归类”，删除的核心是“物理移除”。只有那些错误的、重复的、无用的数据才能删；过季的有效数据，必须归档保存。
专业判断逻辑：怎么判断哪些库存该清、哪些该留、哪些是数据假象
按“数据状态”判断：先看数据是否可信
动手清理任何库存前，先做数据质量体检。我建议把SKU按数据状态分为四类：
（1）可信数据：账实相符率≥95%，近期有出入库记录，成本价、吊牌价、渠道价都可查。这类库存可以直接参与决策。
（2）可疑数据：账实相符率在70%到95%之间，有部分出入库记录但存在时间缺口。这类库存需要抽盘核实后再判断。
（3）危险数据：账实相符率低于70%，或者长期没有出入库记录，或者存在负数库存。这类库存必须先修正数据，再谈清理。
（4）垃圾数据：重复SKU、失效SKU、无成本价SKU、无来源记录SKU。这类数据直接归档或删除，不参与任何业务判断。
这套分类逻辑的核心是：清库存的顺序不是按商品价格，而是按数据质量。数据质量越差，处理优先级越高。
按“季节生命周期”判断：商品处于什么状态
换季库存不是“一刀切”。一件秋装外套在八月底是新品，九月底是应季品，十月底是当季品，十一月是过季品，十二月才是换季库存。所以清理换季库存之前，要把所有SKU按季节周期分成五档：
（1）应季热销期：还在正常动销，不需要清理，重点是确保库存充足。
（2）应季衰退期：销量连续两周下降，开始准备清仓预案，但暂不动价格。
（3）换季库存期：当季已结束，进入清仓节奏，是清理的主要对象。
（4）跨季保留期：基础款或经典款，可以跨到下一季继续销售，保留在售状态。
（5）历史积压期：超过一年没有动销，且款式不具备经典性，是清理和止损的对象。
这五档中，真正需要重点清理的是“换季库存期”和“历史积压期”。但“应季衰退期”和“跨季保留期”这两个分类，很多人会搞混，导致要么清早了损失毛利，要么清晚了库存烂在手里。
按“时间加权动销率”判断：不是看总库存，而是看周动销
服装行业清库存时最常见的错误是盯着“总库存量”看。新款还剩300件，老款还剩200件，感觉总量差不多。但新款每周还能动销50件，老款每周卖3件。如果只看总量，你会做出错误判断。
我建议用“周动销率”作为核心决策指标：
周动销率 = 最近7天销售数量 ÷ 当前可用库存数量
这个指标的好处是：它结合了“时间”和“库存量”两个维度，能更客观地反映库存的健康度。 只看总量会误判，只看销量会漏判。
按“资金占用+仓储成本”判断：算算库存每一天都在花多少钱
清库存的另一个重要判断维度是“持有成本”。很多服装企业不算这笔账，觉得货放在仓库里反正不要钱。实际上库存每天都在吞钱。
服装行业仓储持有成本的常见估算标准是：商品价值的15%到25%每年。也就是说，一件成本价100元的外套，放一年不动，仓储、资金占用、保险、管理的综合成本大约是15到25元。放两年就是30到50元。
如果你有一批库存，正常销售的毛利率才30%，但清理前它已经在仓库里躺了八个月，那么这8个月的持有成本已经吃掉了商品价值的10%到16%，这时再不清，只会越留越亏。 这也解释了为什么很多打折清仓看起来“亏本卖”，实际算总账反而比继续压仓更划算。
按“渠道匹配度”判断：不同渠道适合清不同库存
清库存不是把所有滞销货都丢给同一个渠道。特卖渠道清不了高客单价的款，直播渠道清不了没有视觉冲击的基础款，私域渠道清不了需要现场试穿的产品。渠道匹配错了，清库存的折扣打了，货还是卖不动。
我给客户做清理方案时，通常按渠道路径分配库存：
（1）线下特卖会和批发渠道：适合清基础款、经典款、尺码相对齐全的商品。
（2）直播清仓渠道：适合清视觉感强、款式特点明显、适合冲动消费的商品。
（3）私域会员闪购：适合清高客单价、老顾客认可度高、复购率高的品牌商品。
（4）跨季保留的沉淀款：转入常规在售，等待下一季相同温度区间继续销售。
渠道匹配的核心不是哪个渠道出价高，而是哪个渠道能最快把对应的库存消化掉。清库存的速度比清库存的价格更重要，时间就是最大的成本。
数据观察：一次真实的女装换季库存清理全过程
项目背景
2023年8月，一家深圳女装品牌找到我，他们要做夏装换季清库。数据库显示夏季服装SKU 840个，总库存5.7万件，库存货值按照成本价计算约620万元。老板的需求很直接：用两个月时间把夏装库存消化到只剩基础款，回款目标不低于300万元。
但在正式制定促销方案之前，我先做了一次数据库体检，结果触目惊心。840个SKU里面，只有392个SKU的数据状态是“可信数据”，占比46.7%。负库存SKU有96个，重复建档SKU有58个，尺码缺失的SKU有213个。换句话说，超过一半的库存数据不能直接用于经营决策。
清理过程
我先花了两周时间做数据修正，包括合并重复SKU、修正负数库存、补全尺码信息、归档废置SKU。数据修正后，真正的可经营夏季SKU数量从840个降到了698个，总库存从5.7万件修正为4.9万件。这中间差出的8000件，就是数据错误带来的“虚假库存”。
数据修正完成后，我做了一次全量实物抽盘验证，抽盘覆盖了120个SKU、3600件商品，账实相符率从清理前的约72%，提升到了94%。然后我按照季节生命周期把698个SKU分成五档。应季衰退期占22%，换季库存期占35%，跨季保留期占28%，历史积压期占15%。真正进入清仓核心动作的是“换季库存期”和“历史积压期”的SKU，合计约350个。
接着设置渠道清仓策略：直播间主推视觉感强的连衣裙和衬衫，特卖渠道清基础款T恤和裤装，私域闪购清高客单价的套装。到了当年10月底，夏季库存售出3.1万件，回款356万元，超过老板设定的300万元目标。更重要的是，剩余库存从4.9万件降到了1.1万件，其中4000件是跨季保留款，剩下的7000件是历史积压款，已经计提了减值准备。
这个案例最有价值的三个判断
（1）数据修正带来的直接回款保护：如果直接按数据库里的840个SKU、5.7万件库存来定价清仓，会把8000件“不存在的库存”和大量重复SKU包含在内，导致折扣方案过于激进，白白损失毛利。
（2）分类比打折更重要：清仓前把商品分成不同生命周期阶段后，跨季保留款完全没有打折，这些款在下一季依然能按正常价格销售，保住了库存的利润底线。
（3）渠道匹配缩短了清理周期：同类商品在直播间7天内消化了60%，而特卖渠道的同批货消化率只有18%。选对渠道，旺季清库可以缩短一半时间。
不同情况下的行动建议
如果你是年销售额5000万以下的中小服装企业
这类企业最大的特点是：库存数据库通常只是进销存软件或Excel表，数据精度低，人力有限，不太可能上复杂的ERP系统。
行动建议是：
（1）先做一次彻底的数据库清理，把SKU、库存量、成本价、库位四个核心字段整清楚。
（2）不要追求全渠道实时同步，只需要每周做一次“总库存数+渠道分库存数”的核对。
（3）换季清理时，把决策核心放在“颜色+尺码”级别，不要只盯着款式级别。很多库存其实是在特定尺码上积压的。
（4）建立一张简单的“换季数据清理表”，包含SKU编号、商品名、季节、当前库存、周动销率、数据质量状态六个字段，每个换季节点更新一次。
中小企业的核心策略是：不做重系统，做重数据核对。
如果你是年销售额5000万到3亿之间的成长型服装品牌
这个阶段的品牌通常已经有ERP系统，但系统数据准确率不高，同时业务部门各自维护着一份Excel表，数据口径很乱。
行动建议是：
（1）以季度为单位，由商品运营负责人牵头做一次“数据校准会”，让商品部、运营部、仓库主管三方共同确认每一个SKU的数据状态。
（2）把负库存清零作为硬性指标，每周通报一次负库存SKU数量。负库存是数据混乱的起点，不根治后面全是糊涂账。
（3）在ERP系统里增加“库存数据质量字段”，比如“数据可信”“数据可疑”“数据危险”，每次换季清理前先按这个字段筛选。
（4）利用换季节点做数据抽盘，抽盘比例建议不低于SKU总数的15%，抽盘差异率如果超过5%，就需要再做一轮全量盘点。
成长型品牌的核心策略是：把数据质量责任落实到具体岗位，而不是丢给IT部门。 我见过太多的ERP项目失败，不是因为软件不好，是因为没人对数据负责。
如果公司库存来自多品牌或多项目并行管理
服装集团常有多个品牌线、多个业务项目共用一套库存数据库的情况。这时候问题会变成不同品牌的数据混杂在一起，清某个品牌的库存时，很容易误伤另一个品牌的数据。
如果你遇到的是项目团队管理多套商品数据的情况，我的建议是：
（1）每个品牌或项目必须独立建档，严格按“品牌编码+季节+大类+款号+颜色+尺码”六级编码原则分配SKU。
（2）交叉销售时，在数据库里做“调拨记录”而不是“新建SKU”。很多团队一调货就新建一个SKU，这是非常糟糕的习惯。
（3）如果你在用某项目管理工具管理团队任务，而库存数据系统又在另一边，请务必确认两个系统之间的同步机制。我见过一个常见的真实故障：项目团队在协作工具里更新了一个SKU的处理任务，但库存系统里对应SKU数据根本没有任何变化，两边数据口径完全对不上，结果清理方案写好了，系统里根本没有执行依据。
如果你是刚接手库存数据管理的运营负责人
刚接手时，最忌讳的是被业务部门催着马上定清库存方案。你应该做的第一件事叫“摸清底数”。具体来说，花两到三天时间做下面四件事：
（1）导出一份完整的SKU级别库存表，包含SKU编码、名称、成本、库存、库位、最近出入库时间等字段。
（2）筛选出“可信度最低”的数据：负库存、零库存但还在售、有库存但三个月没有任何出入库记录。
（3）去仓库做一次实物抽盘，重点抽查这些数据异常SKU的实际库存。
（4）带着问题数据去和商品、仓库、财务三个部门开会，核对差异原因。
第一天出现负库存，可能是发退没有及时录入；第二天可能是盘点损耗没有报损；第三天可能是销售出库扣减错误。只有知道原因，才能堵住源头。否则你每次换季清理都在重复清同一批错误数据，永远到不了真实库存的底。
数据库本身的清理技术动作
从具体技术操作角度看，换季库存数据清理至少包含以下几个动作：
（1）归档处理：将上一季销售关闭的SKU从主库存表移到历史归档表，不再参与实时库存计算。
（2）负库存修正：排查所有负库存SKU，找到原因并做入库调整，无法查明原因的做盘盈亏处理。
（3）重复SKU合并：对同一款号相同颜色尺码的SKU做合并，保留最早创建的编码，其余编码作废。
（4）状态标注：对过季商品打“清仓中”“保留”“待处理”标签，让销售团队一眼看清。
（5）数据快照：每次换季清理前，做一次全量库存数据快照备份，防止清理过程中误操作丢数据。
这些动作很多企业没有形成固定流程，每次都是靠某个人临时想办法。我建议把它固化成一份SOP文档，每次换季按步骤执行。
不同情况下的取舍原则
数据精确度和清理速度之间的取舍
我刚入行时做库存诊断，总想一次性把数据做得更精细，每一个SKU都要求查到最底层。后来发现，换季不等人。你花三个月查数据才查清楚，夏天都过去了，库存更不值钱了。
后来我形成了一套“80/20数据清理法”：优先修正影响金额最大的SKU数据。对库存货值排名前20%的SKU做100%精确核实；对剩余80%的SKU，只要数据基本可信、没有负数、没有明显缺尺码，就先进入清理流程。用20%的数据精力守住80%的库存货值，这是更务实的取舍。
保留跨季库存和历史清理之间的取舍
清库存时最容易犯的另一个错误，是不舍得清“可能还能卖的款”。尤其是设计师品牌，总觉得自己设计的衣服有经典基因，过季了第二年还能卖。事实上，除了基础款和经典款，绝大多数时装过季后，第二年再卖的动销率会下降60%以上。保留的仓储成本和资金占用，远高于直接清理的损失。
我的取舍原则是：经典款保留，过季款清理；基础色保留，花哨色清理；百搭款保留，强烈风格款清理。 这三个维度如果都指向“清理”，就不要再犹豫。
折扣深度与清库周期之间的取舍
清库时很多老板纠结折扣，觉得吊牌价5折就亏太多。但正确的思考方式是算总账：
从财务总账看，方案A的净现金流往往优于方案B。清库存的目标不是卖出最高单价，而是以最快速度把商品变成现金，把超过生命周期的商品清理出报表。 这是清库存的第一性原理。
线上渠道和线下特卖之间的取舍
线上清库存的优势是覆盖面广、上新快，但问题是平台扣点、物流费用、退货率都会吞噬毛利。线下特卖的优势是走量干净，适合大批量清库，但问题是场地、人工、时间窗口受限。
我的建议是：高客单价的货走线上私域或直播，走量大的基础款走线下特卖，中高风险的滞销款可以搭配福袋或盲盒形式清理。不要指望一个渠道能吃下所有库存，多渠道路径配置才是换季清库的最优解。 比如上面提到的那家深圳女装品牌，直播渠道贡献了56%的回款，但特卖渠道消化了42%的库存件数；两类渠道各司其职，效率比单渠道高很多。
清理时“一次到位”还是“分批清理”的取舍
很多企业喜欢一次把库存全甩出去，图省事。但一次清太猛有两个风险：一是渠道承接不了那么多货，价格被压得更低；二是如果一次清了60%，剩下的40%反而更难卖，因为渠道和直播间都已经消化过一次同款了。
我倾向于“三批清理法”：第一批清理10%的烂货，用来测试渠道和客户反应；第二批清理50%的主流过季款，这是清库的主力；第三批清理剩余货尾，搭配新品做赠品或低价福袋。每一批之间留一周的观察期，根据动销情况调整下一批的价格和策略。
这种做法牺牲了一点速度，但整体回款通常比一股脑清完高出8%到15%。
结尾：把“数据清理”从临时动作变成经营能力
回到文章开头的郑州女装案例。那次库存数据清理过后，那家企业做了一个很重要的改变：每季末都强制做一次数据校准和归档，并指定商品运营负责人直接对数据质量负责。今年再去他们仓库，库存准确率已经稳定在95%以上，换季清库存从“惊险一跃”变成了“例行工作”。
我的结论是：数据库存服装库存这件事，本质不是数据库技术问题，而是管理纪律问题。技术工具只是执行层，真正的核心是你能不能在每个换季节点，坚持把数据洗干净，再去做运营决策。 数据干净了，清理动作才有意义；数据不干净，所有清库存的动作都是带着沙子在跑步，越跑越累，越跑越看不清方向。
下一步，我建议你先不要急着定换季折扣，而是按我说的四步开始：第一，导出一份SKU级别的库存表，标出所有数据异常项；第二，去仓库做一次覆盖头部SKU的实物抽盘；第三，和财务、仓库、运营开一次库存数据校准会；第四，建立一张“换季数据清理表”并指定负责人。做完这四步，你再来制定清仓方案，那时你手里的数据才配得上你做的决策。
这是我在服务第三家服饰品牌时踩过最大的坑。当时我负责清理一个包含12万条SKU的SQL Server库存表，自作聪明地把两年前的所有记录做了物理删除，结果次月财务做毛利分析时发现历史销售成本完全对不上，因为被删的记录里还关联着当时的采购单和促销分摊费用。
我的专家判断是：换季清理的本质是“归档”，不是“删除”。服装SKU的属性维度极多，颜色、尺码、批次、吊牌价、成本价、库位码都挂在同一条记录上，一旦物理删除，所有历史联动报表，包括买手采购复盘、供应商对账、滞销赔付计算，都会出现无法修复的空洞。更关键的是，换季数据有法律和税务上的保留期限。
国内企业所得税法要求成本核算凭证至少保存5年，而服装企业经常涉及跨期退货和售后翻单，那些所谓“过季”的款式，第二年可能因为直播平台补单又重新激活库存。如果你物理删了，等运营要求恢复数据时，就只能对着一堆备份文件欲哭无泪。
所以我现在的做法是：给库存表增加一个archive_flag字段，用定期任务把超过18个月且动销率为零的记录标记为归档。查询时默认过滤该字段，业务表始终保持轻量，但底层数据完整保留。这个做法既不影响日常查询性能，又保住了历史可追溯性。
我最初只会看“最后销售日期”，结果把一批预售款误判成死库存。后来结合服饰行业的季节周期，我总结了一套三层过滤法，已经在四家公司验证过：第一层过滤“零可用数”，即可用库存为0且无在途采购单的记录，这类属于纯历史数据，直接秒归档；
第二层过滤“长期不动销”，按品类设定不同的观察周期，基本款观察90天，时尚款观察45天，而羽绒服这类强季节单品要观察180天，因为7月没卖不代表冬天不能卖；第三层要做“残次与隔离仓识别”，把质检不合格、理赔冻结、库位ID为虚拟仓的记录挑出来，单独建一个异常库存表，别混在正常换季清理里。
这里有个容易被忽视的细节：必须把“最后动销时间”拆成“最后销售时间”和“最后库存变动时间”。某条记录可能半年没卖出去，但库位转移或盘点差异一直在更新，说明它还在真实流转。我遇到过客户因为只追销售时间，把一批正在做换季调拨的商品误归为死库存，差点触发报废流程。
执行层面，我建议把识别逻辑做成SQL视图，核心条件包括：sku_status='active'、available_qty<=0、last_sale_date<阈值、in_transit_qty=0、qc_status='normal'。
每次换季前跑一次，并输出一个包含滞销天数和占用资金额的排名表，让买手和运营确认后再归档。这比拍脑袋定规则靠谱得多，因为决策者有真实数据可看。
我自己就曾因为没做好“隔离”，在晚上12点跑更新脚本，结果凌晨正好有一批直播订单涌入，导致库存表行锁等待，商品详情页出现短暂超卖。那次事故让我意识到：清理不是技术操作，而是一次需要编排的营销事件。我的做法是分三步走。
第一步，提前一天在运营后台设置“清理商品暂停售卖”标签，把这些SKU从前台销售渠道摘除，确保清理期间不会有新订单关联到它们；
第二步，清理操作必须在业务低峰期执行，但不要选最深的半夜，我习惯选早上的5点到6点，因为仓库还没有开始拣货，而夜间订单已经处理完毕，同时用数据库事务把更新、归档和日志写入放在同一个会话里，避免中间状态；
第三步，清理完成后立即做差异核对，用临时表对比系统库存和仓储备案数量，偏差超过0.1%就触发告警。这里的关键是：不要让清理脚本直接操作业务主表。我会先创建一个清理批次表，记录待处理SKU清单，然后逐批扫描并按每500条一个批次提交，避免长时间锁表。
commit频率要控制在每批1秒以内，同时监控数据库的锁等待时长。如果发现某个SKU被订单占用，就跳过并把记录放入重试队列，而不是整个事务回滚。还有一点很多人忽略：清理过程中要关闭库存变化的消息推送。我遇到过清理时触发了库存不足的预警，结果半夜把采购总监的短信轰炸到崩溃。
提前把相关通知规则禁掉，清理完再恢复，这才是真正意义上的“不影响业务”。
我曾经帮一家女装电商公司做清理复盘，发现他们上季度清理了8000条记录，但过了一个月又有1500条以完全相同的SKU编号重新出现在库存表里，原因是采购系统自动创建了初始库存单据。所以验证和防复发必须同时做，否则就是白忙一场。
验证环节我建议做四项检查：第一，数量守恒检查，清理前库存总数必须等于清理后库存数加归档数，偏差为0才算通过；第二，金额守恒检查，按成本价汇总，历史成本不能凭空消失，如果归档前总成本是830万，归档后加上归档成本也要等于830万；
第三，引用完整性检查，所有库存记录关联的采购单、入库单、调拨单必须还能正常join，在SQL里跑一次left join找出孤儿记录；第四，抽样人工复核，随机抽取50条归档记录，由仓管和财务分别确认无异常。防止再次污染，我设计了一套“库存生命周期状态机”。
所有SKU从创建之日起就带有季节标签和六位生命周期状态码，包括：在售、预警、淘汰、冻结、待归档、已归档。当商品在系统里连续30天无动销，自动从“在售”变为“预警”；预警超过45天自动进入“淘汰”；此时如果有库存或者未完成订单，则留在“冻结”状态，否则跳到“待归档”。
这个状态机由后台定时任务驱动，每天凌晨跑一次，一旦进入“已归档”就不允许任何业务单据直接引用，如果需要恢复，必须走特批流程。最后，我强烈建议在数据库中建立一个归档日志表，记录每次清理的操作人、时间、批次号、影响行数和数据指纹。数据指纹我用的是MD5汇总值。
三个月后若发现某个SKU“复活”，可以直接通过日志回溯是哪个环节的脏数据导致，快速定位而不是全表重查。这套机制用下来，我服务的客户中，二次污染率从原先的12%降到了0.5%。
读者评论
我们公司正好也有这个问题，每次换季就急着定折扣，结果发现数据库里一堆负数库存和重复SKU。之前总是先清货再核对数据，越清亏得越多。这篇文章提醒了我，要先做数据治理再谈促销。我们打算先花一周把库存数据理清楚，再决定清哪些、按什么价格清。
文中那个“下架不等于清理”的误区太典型了，我们系统里就躺着大量下架半年以上的历史SKU，报表明明还显示着。周动销率这个指标我准备拿来用，以前只看总库存和销量，确实会误判。另外换季数据刷新机制也值得借鉴，否则每次清理都是重蹈覆辙。
最有感触的是那个碎花裙的案例，数据错乱导致误判断码，差点把好货当尾货处理。我估算过，我们仓库里那些老库存的持有成本确实在逐年吞利润。清理要结合资金占用来看，不能光看表面折扣，算总账才是关键。