最合理的是单层Category类加自引用parentId字段；id用Long、name限50字符、parentId可空、sortOrder用Integer、避免冗余level字段。
商品分类用什么Java类结构最合理
直接用单层 Category 类加自引用字段，比硬套树形接口或继承更稳妥。多数电商后台的分类层级不超过5级，过度抽象反而增加维护成本。
-
id：主键，Long类型，不建议用String（后续做路径拼接、排序、分页时容易出错） -
name：非空，长度建议限制在 50 字符内（避免前端展示溢出或数据库索引失效） -
parentId：可为null，表示一级分类；不要设默认值0—— 会和真实id=0冲突 -
sortOrder：Integer，用于同级排序，别用double或String（排序逻辑变复杂且易错） - 避免加
level字段：它可由递归/路径计算得出，冗余存储易导致不一致
怎么查出带层级关系的完整分类树
别在 Java 层递归查库（N+1 问题），用一次 SQL 查全量再本地构树更稳。MyBatis 可用 @Query + 手动组装。
SELECT id, name, parent_id, sort_order FROM category ORDER BY parent_id, sort_order;
- 查完后用
Map按> parentId分组 - 遍历所有
parentId IS NULL的节点作为根，逐层向下找子节点 - 注意空指针：
parentId是Long类型，比较时用Objects.equals(parentId, current.id)，别用== - 如果分类数超 2000 条，考虑加
path字段（如"0-101-205"）加速查询，但需在新增/移动时维护
移动分类位置或调整父子关系要注意什么
这不是简单改 parentId 就完事。涉及路径变更、子树迁移、循环引用校验三个硬伤点。
- 更新前必须查一遍目标父节点是否是当前节点的后代（否则形成环）—— 写个递归方法查
path或临时缓存整棵树判断 - 如果用了
path字段，要批量更新整棵子树的path值（比如从"0-101-205"改成"0-302-205"），不能只改当前节点 - 事务必须包裹整个操作：改父节点 + 更新子树
path+ 更新所有子节点level（如有） - JPA 用户慎用
cascade = CascadeType.ALL：它可能意外删除子分类，应显式控制生命周期
前端传参和接口设计怎么防崩
分类管理接口最容易被绕过校验，尤其 parentId 和 sortOrder 这两个字段。
立即学习“Java免费学习笔记（深入）”；
- 接收参数统一用 DTO，不要直接绑定
Category实体类（避免攻击者传入id或createTime等只读字段） -
parentId必须二次校验存在性：查库确认该id对应的是有效分类，且不是自己或子孙 -
sortOrder入参范围建议限制在0–999，超出则拒绝（防止恶意填极大值影响排序稳定性） - 删除接口必须是逻辑删除（
isDeleted = true），物理删除要连带检查是否有商品关联（SELECT COUNT(*) FROM product WHERE category_id = ?）
operatorId、categoryId、oldParentId、newParentId 四个字段，排查时省一半时间。 
