简介面向电商及零售管理系统提供的一份现成商品分类库采用四级分类结构内含两千多条细分商品类别覆盖服装、食品、电子、日用等多个主流经营领域为不同规模商城提供统一规范的商品归类口径。压缩包整体为一个数据库脚本文件体积约531KB导入常见数据库即可自动生成分类数据表省去手工搭建分类体系的步骤部署成本低。这个数据库脚本既可用于前台商品上架、搜索与导航也可对接企业资源计划系统和客户关系管理系统支撑库存管理、订单处理及客户购买行为分析分类层级从大类到细类逐级展开便于精细化运营与数据统计。目前已有两千三百二十一人浏览学习适合正在启动电商项目、升级管理系统或重整商品数据的运营人员、开发人员与实施顾问使用。1. 商品分类库“最全最新”这个要求,到底在问什么做电商数据的人,八成被同一个问题折磨过:同一条商品,推荐库挂在“女装/裙装/连衣裙”,报表库挂在“女装/上衣/长裙”,两边数字对不上,谁都不敢说是自己的锅。我经手的某公司项目里,光这一件事就拖了两周数据迁移,最后查出来是两套历史类目口径没对齐。商品分类库不是一张 Excel 表那么简单,它是把层级类目、编码体系、属性模板和维护流程固定下来的一套公共数据底座。标题里“最全”和“最新”其实是两个运维维度:横向上品类覆盖够不够广,纵向上能不能跟上每个月冒出来的新品类。这篇文章就按“结构怎么定、文件怎么出、更新怎么跑、坑怎么避、质量怎么验”这个顺序,把一个能落地的方案讲透。2. 类目树的骨架怎么搭:层级、编码与属性的三层拆分2.1 类目树的层级设计:从一级行业到四级细分的取舍常见做法是把整个类目体系做成四级。一级按行业分,比如服饰、数码、食品、家居,这一级数量最少,通常 20 个以内;二级按核心品类分,比如“服饰”下面拆出男装、女装、童装;三级按款式或功能分,比如“女装”下面拆出连衣裙、半身裙、衬衫;四级按场景或细分风格分,比如“连衣裙”再拆出法式连衣裙、茶歇裙、通勤裙。这样一个商品能挂到足够具体的层级,搜索和推荐就能拿到有区分度的标签。但这不意味着层级越深越好。四级以上我一般不建议,维护成本会陡然上升。每多一级,就要多一套命名规范、多一遍审核流程,而且叶子节点越碎,商品误挂率越高。运营为了省事,会把“法式收腰显瘦连衣裙”整个塞进四级类目,这等于把属性当类目用。四级结构足够支撑绝大多数电商场景,关键是把每一级的粒度控制好。下面是一个参考样例:一级二级三级四级(叶子)服饰女装连衣裙法式连衣裙 / 茶歇裙 / 通勤裙数码手机智能手机大屏影音机 / 游戏手机家居厨房锅具不粘锅 / 铸铁锅 / 压力锅命名时有一条铁律:类目名里不允许出现颜色、季节、材质、品牌、人群。它们都应该是属性或商品标题里的内容。如果“女装”下面出现“红色连衣裙”和“冬季加绒连衣裙”,说明属性没有拆干净,后面避坑章节会专门讲这种情况。2.2 编码规则:为什么用纯数字编码而不是中文名类目名是人看的,编码是系统用的。两个体系必须分开,这是分类库设计里最容易偷懒又最致命的一步。直接用中文类目名做关联键,改一次名,所有历史数据全部失效;编码则不同,一旦生成就永久绑定,不随名称改变而改变。我常用的编码规则是:每级两位数字,从 01 开始,整体拼接成 8 位定长字符串。比如“01010101”表示“服饰/女装/连衣裙/法式连衣裙”,前两位是一级,前四位是二级,前六级是三级,全部八位是四级。这样设计有几个实打实的好处:一是排序稳定,数字升序就是类目树的遍历顺序;二是前缀查询极快,想找某个二级类目下所有商品,直接 WHERE category_code LIKE 0101%;三是定长 8 位在 Excel、数据库、接口传输里都整齐,不会出现长度不一的脏数据。编码生成要遵循两个约定:全库统一长度,不足位补零;每级预留 90-99 作为扩展段,防止某些品类增长过快导致编码段不够用。编码一旦发布,禁止删除、禁止改名、禁止复用。如果作废就置为停用,保留在库里作为历史引用,这是后面做增量映射的基础。2.3 类目属性拆分:类目属性与商品属性的边界划分类目定完之后,下一步是属性。属性的拆分决定分类库能不能真正挂到商品上,而不只是一棵好看的树。把属性放错位置,是后期返工的第二大来源。这里要先说清楚两个概念的区别。类目属性绑定在类目上,是该类目下所有商品都必须回答的结构化字段。例如“手机”类目下必须有品牌、屏幕尺寸、运行内存;“连衣裙”类目下必须有裙长、腰型、领型。商品属性则描述单个商品的个性化差异,例如“成色”“定制刻字”“颜色”。判断一条属性该放在类目还是商品上,有一条很简单的经验:如果这个字段的值在同类目商品里高度通用,它是类目属性;如果只是少数商品的特征,它是商品属性。“颜色”几乎人人都有,但它不影响商品作为“连衣裙”的本质,所以放商品属性。实现上,我建议单独维护一张“类目-属性模板表”,而不是把属性写进类目树的节点里。表结构至少包含类目编码、属性名、属性类型、是否必填、排序号。这样商品在上架时,系统能根据所挂叶子类目动态拉取必填属性表单,既保证了数据完整度,又不用改类目树本身。类目树只回答“它是什么”,属性模板回答“它有哪些结构化参数”,两者解耦,后面维护哪个都不至于牵一发动全身。3. 把类目树落成标准文件:一条命令生成双格式库的 Python 脚本3.1 类目输入数据的组织方式:用 Python 字典还是 YAML分类库最终是要交付给上下游系统的,常见交付格式是 JSON 负责程序读取,Excel 负责人工审核。但在生成文件之前,得先把类目树源码组织好。我习惯用嵌套 Python 字典直接作为唯一数据源,而不是把类目先写进 Excel 再转。原因很简单:嵌套字典天然反映树的父子关系,新建类目时只要找到父节点往里加一层;而用 Excel 维护树,每加一个叶子都要多写一行 parent_code,人工很容易写错。等类目规模超过几百个,再去排查某一行父编码写错,那感觉就是在解一道没有提示的数独。为了便于代码复用,源码里先定义一棵最小示例树,实际生产库里按同一结构扩展,节点数量多大都不影响脚本逻辑。# category_source.py CATEGORY_TREE { 服饰: { 女装: { 连衣裙: { 法式连衣裙: {}, 茶歇裙: {}, 通勤裙: {}, }, 半身裙: {}, }, 男装: { T恤: {}, 衬衫: {}, }, }, 数码: { 手机: { 智能手机: { 大屏影音机: {}, 游戏手机: {}, }, }, 笔记本: { 轻薄本: {}, 游戏本: {}, }, }, }这里的 key 是人类可读的类目名,value 是下一层子类目。叶子节点用空字典表示。Python 字典从 3.7 开始保持插入顺序,这对后续 Excel 行的排序很重要,不会出现类目顺序随机跳动的情况。等类目数量增长到两千以上,可以考虑拆成多个模块文件再合并,但单文件的嵌套结构不需要变。3.2 一段脚本同时输出 JSON 和 Excel:实现与参数说明生成脚本的核心是递归遍历。每进入一层,记录当前路径上的类目名,拼接出该节点的编码;继续向下递归;直到某节点没有子节点,就标记为叶子并写表。递归同时维护一个全量节点列表,供 Excel 展平输出。# build_category_files.py import json from openpyxl import Workbook # 从 category_source 导入类目树 from category_source import CATEGORY_TREE LEAF_MARK leaf # 叶子节点标记 DEFAULT_CODE_WIDTH 2 # 每级编码宽度 TOTAL_CODE_LEN 8 # 总编码长度 def _fmt_code(seq: int) - str: 把序号补零成 2 位编码段 return str(seq).zfill(DEFAULT_CODE_WIDTH) def _walk(tree, parent_code: str, level: int, path: list, rows: list): 递归遍历树,生成编码和拍平数据行 for sort_no, (name, children) in enumerate(tree.items(), start1): seg _fmt_code(sort_no) code (parent_code seg).ljust(TOTAL_CODE_LEN, 0) # 空字典表示无子节点,即叶子 is_leaf len(children) 0 rows.append({ code: code, name: name, level: level, parent_code: parent_code or None, is_leaf: is_leaf, sort_order: sort_no, }) if not is_leaf: node_path path [name] _walk(children, code, level 1, node_path, rows) def build_json_and_excel(output_json: str, output_xlsx: str): 生成嵌套 JSON 和扁平 Excel 两份分类库文件 rows [] _walk(CATEGORY_TREE, , 1, [], rows) # 嵌套 JSON:按树结构输出,方便程序直接加载 with open(output_json, w, encodingutf-8) as f: json.dump(CATEGORY_TREE, f, ensure_asciiFalse, indent2) # 扁平 Excel:每行一个类目,方便运营人工审核 wb Workbook() ws wb.active ws.title category_tree headers [code, name, level, parent_code, is_leaf, sort_order] ws.append(headers) for r in rows: ws.append([r[h] for h in headers]) wb.save(output_xlsx) print(ftotal nodes: {len(rows)}) if __name__ __main__: build_json_and_excel(category_tree.json, category_tree.xlsx)这段脚本的逻辑链路是:从根节点开始,每个节点先产出自己的编码和名称,再判断是否有子节点;有子节点就递归进去,没有就结束这条分支。sort_no从 1 开始递增,作为同级类目的排序号,直接控制 Excel 行的顺序和编码段的数值。parent_code seg利用编码的前缀特性,让子节点天然继承父节点的前几位,那里漏掉的位数用ljust补零,保证所有编码定长 8 位。运行前确认环境里装了openpyxl,一般用pip install openpyxl装一下。生成后可以快速查看输出文件,JSON 端应当是一棵嵌套字典树,压缩前几千个节点大概几十 KB;Excel 端每一行是一个类目,is_leaf字段取True的行就是叶子类目。这套脚本后续接增量更新时,只需要改CATEGORY_TREE的内容,输出格式不用再动。3.3 生成后的校验:先跑自检再入库的固定动作生成文件看似简单,真正上线前必须加一道校验,否则等下游系统报错再来查就晚了。常见做法是在脚本里加一个validate_tree函数,做三件事:检查编码格式是否符合定长 8 位且每级两位;检查每个节点的父编码是否真实存在;检查是否存在环。# validate_tree.py import re CODE_PATTERN re.compile(r^\d{8}$) def validate_tree(rows): 对拍平后的类目行做基本规则校验 code_set {r[code] for r in rows} for r in rows: if not CODE_PATTERN.match(r[code]): raise ValueError(fbad code: {r[code]}) if r[level] 1 and r[parent_code] not in code_set: raise ValueError(fmissing parent: {r[code]}) print(validate ok: all codes are 8-digit and parents exist)这段代码的检查逻辑很直白:编码格式错了,说明生成逻辑有问题;父编码不存在,说明源码树里混入了孤儿节点。这两类问题在类目库的日常维护里出现频率最高。环的问题比较少见,因为嵌套字典结构天然不会成环,但一旦改成从 Excel 导入,就一定要加环检测,用拓扑遍历的方式去判断有没有节点循环引用。校验通过后,JSON 文件直接交付给开发,Excel 文件交付给运营做人工二次确认,两道关卡都过了再入库发布。4. 让库保持“最新”的增量维护机制:新增映射表与更新闭环4.1 增量清单的表结构设计:新增、变更、停用三种操作分类库建成之后不会静止,每个月都有新品类冒出来,比如露营经济带火了“天幕帐篷”,直播电商让“氛围灯”从家居装饰里独立出来。全量重发一遍类目文件是最初级的做法,但会让下游系统面临两个问题:一是他们不知道哪些变了,只能全量比对;二是历史商品挂在旧类目上,全量替换后直接断链。正确的做法是建立增量维护机制,每次只发布变更集合。我用一张category_incr表来记录每次增量变更,核心字段就五个:操作类型、类目编码、类目名称、父编码、生效日期。操作类型只允许三种add、change、disable。add表示新增一个类目,change表示修改类目名称或调整父节点,disable表示停用某个类目,但不删除。每条记录带effective_date,下游系统按日期顺序重放增量,就能得到最新全量版本,不用等人工整理。CREATE TABLE category_incr ( id BIGINT PRIMARY KEY AUTO_INCREMENT, op_type VARCHAR(10) NOT NULL COMMENT add/change/disable, category_code VARCHAR(20) NOT NULL, category_name VARCHAR(100) NOT NULL, parent_code VARCHAR(20) NULL, effective_date DATE NOT NULL, remark VARCHAR(255), KEY idx_code_date (category_code, effective_date) );这里的category_code是增量变更的对象,parent_code配合op_type使用。add操作里parent_code是它要挂载的父类目编码;change操作里如果修改了层级,parent_code就是新父编码;disable操作里parent_code可以留空。每次发布前,脚本会自动读取从上次发布至今的增量记录,生成一份变更说明文件,内容包括本次新增了哪些叶子、停用了哪些类目、改动影响了哪些父子关系。这份说明比全量 Excel 对运营友好得多,他们只审核变化行,不用从头看一遍几千个类目。4.2 新旧类目映射表:迁移老商品的后悔药增量机制解决的是“新商品挂到哪”的问题,但老商品怎么办,是另一个容易翻车的点。比如“锅具”从“家居/厨房”里独立升为二级类目,原来挂在“厨房用品”下的所有锅具商品,类目编码全变了,如果不做映射,历史报表直接断档。所以我每次发布结构性变更时,都会同步生成一张新旧类目映射表,它本质上是一张后悔药。映射表不需要人工一条条维护,而是由变更脚本根据增量操作生成。核心字段就三个:旧编码、新编码、映射类型。映射类型取四个值之一:direct表示单纯改了个名或编码,商品不用重新归类;move表示整体移动到了新父节点下;split表示旧类目拆分成了多个新类目,需要按商品属性重新分配;merge表示多个旧类目合并成了一个新类目。生成映射表的逻辑里需要特殊注意split和merge,它们无法用一条规则自动完成,必须人工介入,但映射表先要把对应关系记下来,避免后续追溯时找不到源头。旧编码新编码映射类型说明020403030201move锅具整体移到家居/厨房020405030202, 030203split旧“炊具”拆成“锅具”和“灶具”020410030204merge旧“汤锅”“炖锅”合并为“炖煮锅”direct和move可以直接写 SQL 批量更新商品表,split和merge则需要通过属性或运营人工打标来二次确认。映射表存在的意义不是让脚本全自动解决所有迁移,而是给每一次变更留下可追溯的链路,让老商品在各种复杂情况里至少能查到“它原来在哪、现在应该去哪”。4.3 用 SQL 把映射表变成批量更新,先试跑再执行有了映射表,批量更新商品类目就不是玄学,而是一条标准流水线。流水线的第一件事永远是先查数量,再更新,最后对着数量校验。直接跑UPDATE的教训我见过太多次,十有八九是某条映射类型写错,把不该动的商品全挪了位置。-- 第一步:统计待迁移商品数,确认影响面 SELECT m.mapping_type, COUNT(*) FROM category_incr_mapping m JOIN product p ON p.category_code m.old_code WHERE m.mapping_type IN (direct, move) GROUP BY m.mapping_type; -- 第二步:确认数量正常后再执行更新 UPDATE product p JOIN category_incr_mapping m ON p.category_code m.old_code SET p.category_code m.new_code, p.mapping_type m.mapping_type WHERE m.mapping_type IN (direct, move);第一步的COUNT结果要和上一步增量清单里的move或direct记录数对上,对不上就停下来查原因。通常原因是老商品里混着一部分已经挂在其他类目下的编码,或者是映射表里的旧编码在商品表里根本不存在。第二步执行完之后,再跑一次SELECT COUNT(*) FROM product WHERE mapping_type IN (direct,move),如果结果为 0 说明全部迁移完成。对于split和merge,我会单独建一张待确认商品临时表,通过运营在后台按属性筛选后分批处理,处理完再从临时表移除。这套流程跑顺之后,一次结构变更是可以控制在半小时内完成的。5. 商品分类库上线避坑:5 个让类目体系翻车的现场与排查方法5.1 现象 1:类目树出现环,递归遍历直接栈溢出某次我把一个从外部采购的类目库导入系统,脚本跑着跑着直接报RecursionError: maximum recursion depth exceeded,一开始以为数据量大,后来发现是某个节点的父编码指向了自己的子节点,形成循环引用。嵌套字典手工维护不会出现这种问题,但一旦从 Excel 批量导入,人工填parent_code填串行,环就出现了。排查办法是写一个递归函数,遍历时把当前路径上的祖先编码集合传下去,如果发现某个节点的父编码已经在祖先集合里,立即报错并打印出这条环的完整路径。修复方式也很直接,把 Excel 里那一行的parent_code改成正确的父节点编码,重新导入即可。这件事之后我把环检测写进了每次导入的必经流程,不再靠报错来发现。5.2 现象 2:编码段不够用,新品类挂不进去类目发展速度超过编码设计预期,是“最全最新”需求里最尴尬的场景。我当时按每级 2 位数字设计,一级类目最多 99 个,二到四级同理。一开始完全够用,结果只用了两年,某个品类因为直播渠道爆发,二级类目从 30 多个涨到 90 多个,眼看要撞到上限。如果重新设计编码长度,所有历史数据要跟着迁移,代价极大。真正的教训是:每级固定 2 位没有错,但必须预留扩展段,把 90-99 这十个编号封存,只留给未来拆分使用,日常新增从 01-89 段里按顺序取。如果你预感到品类扩张凶猛,直接上 3 位编码段,总编码长度提升到 12 位,代价只是多几个字节,但十年内基本不用再动结构。5.3 现象 3:叶子节点定义不一致,统计口径对不上这个坑特别隐蔽,它的表现是:开发说自己统计的叶子类目有 800 个,运营说自己维护的叶子有 1200 个,两边对着电脑吵了一下午。最后查出来是定义不统一。开发判断叶子的标准是“没有子节点”,运营的判断标准是“层级等于 3”。只要类目树里有某个二级类目直接挂商品但下面没有子类,这两种口径就会差出一个零头。解决方法是把叶子标记显式化,在生成 JSON 和 Excel 时直接写is_leaf字段,并且规定全库只能以这个字段为准,不允许任何人用级数推断。这一个改动消灭了后续无数次的扯皮。5.4 现象 4:把颜色当类目,类目树组合爆炸“最全”这个词很有迷惑性,有人会理解为把所有商品特征都塞进类目树,于是“黑色连衣裙”“白色连衣裙”“加绒连衣裙”全成了叶子节点。我见过一棵被撑到上万节点的树,光连衣裙就占了几百个叶子。这类组合爆炸的根源是没做属性拆分,把颜色、材质、厚薄这些商品属性当成了类目。类目的意义是区分“商品的品类差异”,不是“同一品类下的款式差异”。修复合并的时候非常痛苦,一个人工审核了一周。正确的做法是回到第 2 章的属性模板,把颜色等维度挪到商品属性表里,类目树只保留真正影响品类判断的维度。5.5 现象 5:老商品迁移了一半就停了,新旧库数据对不上某一次执行批量类目迁移,UPDATE 语句跑了几百万行之后,数据库连接超时,事务回滚,但有一部分商品已经提交到了新类目。结果新旧编码在商品表里并存,报表数据对不上,运营投诉一片。根因是把迁移当成了一次性操作,没有考虑中断恢复。现在我的固定流程是:任何批量迁移都先写dry-run脚本,把影响范围打印出来;正式执行时,每 50 万行一个批次,每批次包一个事务,批次内成功就提交,失败就回滚并记录断点;全部跑完后,再做一次全量对账,确认所有旧编码都已映射到新编码,任何残留都视为失败。这套分批事务的做法还能在出现问题的时候精确定位到失败批次,不用从头排查。6. 用四个指标验证分类库质量:覆盖、准确、深度与迁移成功率6.1 覆盖率与命中率:用抽样商品验证类目够不够全分类库做完之后,怎么知道它真的“全”?我的习惯是从在售商品里随机抽 100 条,不看答案,手工判断每一条应该挂在哪个类目,然后去库里查这个类目是否存在。能找到的比例就是覆盖率。如果覆盖率低于 90%,说明类目树缺了某些实际在售的品类,先补齐再谈别的。抽样商品时要刻意混入新品和长尾商品,只抽爆款会掩盖缺失。准确率则是另一个指标,抽另外 100 条商品,由两个人分别标注然后跟分类库的给定类目对比,一致的比例就是准确率。这两个指标一个衡量“全”,一个衡量“准”,缺一不可。6.2 类目库自检脚本:深度、环检测与悬挂节点一次查完每次发布新版本类目库之前,我都会跑一遍自检脚本,把基础结构问题拦截在交付之前。脚本会输出四个数值:总节点数、叶子节点数、最大深度、悬挂节点数,同时对环做一次检查。节点数可以直观看到规模变化,最大深度超过 4 就说明有人违规加深了层级,悬挂节点数大于 1 则说明有父编码不存在。# category_audit.py import json with open(category_tree.json, r, encodingutf-8) as f: tree json.load(f) total_nodes 0 leaf_nodes 0 max_depth 0 def audit(node, depth): global total_nodes, leaf_nodes, max_depth total_nodes 1 max_depth max(max_depth, depth) if not node: # 无子节点,视为叶子 leaf_nodes 1 for child in node.values(): audit(child, depth 1) audit(tree, 1) print(ftotal{total_nodes}, leaf{leaf_nodes}, max_depth{max_depth})这个脚本的原理是递归统计,空字典判定为叶子,最大深度通过递归层数记录。跑出来的leaf数量要和上一版对比,如果一次增量后叶子数暴涨了几百个,大概率是有人把属性塞成了类目;如果max_depth大于 4,那就要回去看是不是多建了层级。把这类检查写进发布流水线,比等下游系统发现异常再排查要省心得多。至于商品归属的准确率,我建议每个月随机抽 200 条商品做一次人工复核,把误挂的样本整理成清单反馈给运营,不断修正分类库的边界。做分类库越久越明白一个道理:最全的分类库不是把几千类目堆出来就完了,而是让每一件商品挂到对的类目上。某次我为了追求“全”硬塞了一堆生僻叶子,结果商品匹配准确率掉到六成,运营和开发互相甩锅,最后花了两周清理合并。现在我的习惯是每次发布前先跑一遍自检脚本,再抽 50 条商品做命中验证,达标了才交付。“最全”让人兴奋,但“最准”才让人睡得着觉。希望这些经验能帮你在搭分类库的第一天就避开我踩过的坑。本文还有配套的精品资源点击获取