商品分类实体应采用单表自关联设计，含parentId、sortOrder、status字段；推荐内存构树或MyBatis嵌套映射查全量数据；需校验循环引用；提供树形与平铺两类接口，后者依赖path字段提升性能。
商品分类实体怎么设计才支持多级嵌套
Java里做分类管理，核心是解决父子关系建模。用单表自关联最常见，Category 实体里必须包含 parentId 字段，类型为 Long 或 Integer，值为 null 或 0 表示一级分类。
容易忽略的是排序字段和状态字段：sortOrder（Integer）控制前台展示顺序，status（如 Integer 类型，1=启用，0=禁用）避免物理删除影响关联数据。
不建议用递归查询逐层查子类——N+1 问题明显；更稳妥的做法是查出全量分类后在内存中构建成树结构，或用 MyBatis 的 <resultMap> 配合 collection 做一次查询嵌套映射。
MyBatis 查询分类树的两种写法差异
一种是 XML 中用 <select> + <resultMap> 嵌套：
立即学习“Java免费学习笔记（深入）”；
<resultMap id="CategoryMap" type="Category"> <id property="id" column="id"/> <result property="name" column="name"/> <result property="parentId" column="parent_id"/> <collection property="children" ofType="Category" resultMap="CategoryMap"/> </resultMap> <p><select id="selectAllCategories" resultMap="CategoryMap"> SELECT id, name, parent_id FROM category ORDER BY parent_id, sort_order </select>
另一种是 Java 层手动组装：先查 SELECT * FROM category ORDER BY parent_id，再遍历列表，用 Map<Long, Category> 缓存所有节点，对每个节点设置 children 列表。
前者依赖 MyBatis 的嵌套能力，但 SQL 返回结果集必须按父子顺序排列，否则 collection 映射会漏数据；后者更可控，适合后续要加缓存或过滤逻辑的场景。
新增/修改分类时怎么校验循环引用
用户可能把 A 设为 B 的父类，又把 B 设为 A 的父类，导致无限递归。不能只靠前端限制，后端必须校验。
校验逻辑需递归向上追溯父链（注意设最大深度防栈溢出），检查新 parentId 是否等于当前分类 ID，或是否出现在当前分类的任意上级中：
- 查出当前分类所有祖先 ID（含自身），用
SELECT id FROM category WHERE id = #{id} OR parent_id = #{id} OR ...不现实——推荐用递归 CTE（MySQL 8.0+/PostgreSQL）或内存遍历 - 更通用做法：从待更新分类出发，沿
parentId向上找，每跳一次存入Set<Long>，若遇到重复 ID 或达到 10 层深度则拒绝保存 - 更新前先查原记录，若
parentId未变，可跳过此校验
为什么分类接口要区分「树形列表」和「平铺列表」
前端管理页通常需要带缩进的树形结构（用于拖拽排序、展开收起），而商品发布页只需要下拉选择——此时传整棵树反而浪费带宽和解析时间。
建议提供两个接口：
-
GET /categories/tree：返回嵌套 JSON，层级深度建议限制在 5 级内，超深分类应提示“请拆分大类” -
GET /categories/flat：返回扁平列表，含id、name、level（1/2/3…）、path（如"1/5/12"）字段，方便前端按需渲染缩进或生成面包屑
平铺接口的 path 字段特别关键——它让前端无需递归就能知道层级关系，也便于数据库按路径做范围查询（比如查某一级下的全部子类）。
真正难的不是写出来，而是当分类数过万、并发编辑频繁时，树形查询响应变慢、路径更新一致性难保证——这些得靠缓存预热和路径字段冗余来扛，而不是硬拼递归SQL。
