第一次看到“二级目录代码”这五个字，录代是录代在同事老张的电脑屏幕上。他正对着一个电商后台的录代数据库表发愁，嘴里念叨着：“这个分类的录代二级目录代码怎么跟父级对不上？”我凑过去看了一眼，满屏的录代 category_id、parent_code、录代level 字段，录代像一串密码。录代

二级目录代码，录代说白了就是录代给网站或软件里“子分类”贴的标签。比如你打开一个卖鞋的录代网站，一级目录是录代“男鞋”“女鞋”，点进“男鞋”之后看到的录代“运动鞋”“皮鞋”“凉鞋”，每一个都对应一个二级目录代码。录代这串代码通常不长，录代几位数字或字母，但它的位置很关键——它得同时告诉系统两件事：我是谁，我爹是谁。

老张遇到的问题很典型。他负责的那个电商平台，早期分类少，二级目录代码直接用了自增数字，1、2、3、4 往下排。后来品类爆炸，运营人员手动加了几百个二级分类，代码开始乱：有的用 1001，有的用 A01，还有的干脆把一级目录代码拼上序号，比如 M-001。结果做数据统计时，同一个父级下的子分类代码前缀不统一，SQL 查询得写一堆 OR 条件，跑一次报表要等半分钟。

我见过设计得比较清爽的二级目录代码。一家做图书电商的朋友，他们的规则是：一级目录用两位大写字母，LA 代表文学，SC 代表科技。二级目录代码就是一级代码加三位数字，LA001 是“中国文学”，LA002 是“外国文学”。好处很明显——看代码就知道爹是谁，排序也方便，按字符串排就行。运营那边加新分类，只要顺着数字往后排，不会跟别的父级打架。

但代码这东西，设计得再好也架不住业务乱来。有一回我帮一个客户清理他们的分类数据，发现同一个二级目录代码 0305 竟然出现在三个不同的父级下面。问了一圈才知道，是三个运营小组各自建分类时，都用了“03”代表“食品”、“05”代表“进口”，但父级一个是“超市”，一个是“海外购”，还有一个是“企业采购”。代码重复了，数据就串了。后来他们不得不加了一个 full_path 字段，把一级和二级代码拼起来存，才算把这事摁住。

写代码的人容易犯一个错：把二级目录代码当成纯技术字段。其实它一半是技术，一半是业务。技术那边关心的是唯一性、索引效率、查询速度；业务那边关心的是可读性、可扩展性、跟运营规则对不对得上。我见过一个极端例子，某公司的二级目录代码用 UUID，一长串 550e8400-e29b-41d4-a716-446655440000。技术上没问题，绝对唯一。但运营想手动改一个分类的位置，对着这串东西根本不知道谁是谁，最后只能写个脚本批量替换。

如果你现在要设计一套二级目录代码，我会建议先别急着定格式。拿张纸，把未来一年可能增加的分类层级画出来。如果只有两级，代码里带上父级标识就够了；如果有三级甚至四级，那二级代码最好留出扩展位。数字和字母混用不是不行，但得统一长度，别一会儿两位一会儿四位。还有，别用自增 ID 直接当二级目录代码——数据库迁移或者分库分表的时候，你会哭的。

老张后来把他们的二级目录代码全量重构了一遍。规则很简单：一级两位字母，二级四位数字，前两位是父级序号，后两位是子级序号。改完那天他跟我说：“早该这么干，之前那堆代码，我自己看着都头疼。”我笑了笑，没告诉他，其实我见过更头疼的——有人用中文拼音首字母当二级目录代码，结果“男装”和“女装”都是 NZ，系统里两个分类永远分不清。

(责任编辑：热点)