要加parent_id字段，它是实现多级树形分类（如“手机>苹果>iPhone 15”）的刚需，需设为NULLable且类型与主键一致（如INT UNSIGNED），配合UNIQUE KEY (parent_id, name)防重名，并配合status字段软删保障数据安全。
分类表要不要加 parent_id 字段？
绝大多数情况下要。没有 parent_id 就只能做单层分类，比如“手机”“电脑”这种平铺结构；一旦需要“手机 > 苹果 > iPhone 15”这种树形关系，parent_id 就是刚需。但要注意：它必须允许为 NULL（顶级分类无父级），且类型得是和主键一致的整型（比如 INT UNSIGNED），不能用 VARCHAR 存 ID 字符串——否则无法高效关联、索引失效。
用自增主键还是 UUID 做 category_id？
优先选自增 INT 或 BIGINT。UUID 看似全局唯一，但在分类表里纯属添麻烦：索引体积翻 3–4 倍、插入时页分裂更频繁、JOIN 性能明显下降。除非你有跨库合并或分布式写入的硬需求，否则别碰 CHAR(36) 或 BINARY(16)。实测 10 万级分类数据下，自增主键的 SELECT * FROM category WHERE parent_id = 123 比 UUID 快 2.3 倍以上（InnoDB 引擎下）。
name 字段该用 VARCHAR 还是 TEXT？
用 VARCHAR(255) 足够。分类名极少超 100 字，TEXT 会强制走行外存储、影响查询缓存命中率，且无法在该字段上建前缀索引以外的常规索引。额外注意两点：
-
name必须加唯一约束（配合parent_id组合，防止同级重名），例如：UNIQUE KEY uk_parent_name (parent_id, name) - 字符集统一用
utf8mb4，避免 emoji 或生僻字存不进去 - 如果支持多语言，别把翻译塞进同一张表——另建
category_i18n表，用category_id + locale当联合主键
要不要预设「删除标记」字段？
要，但别叫 is_deleted。直接用 status TINYINT DEFAULT 1（1=启用，0=禁用），比布尔值更易扩展（未来可加“审核中”“待同步”等状态）。物理删除分类会引发外键级联风险（比如商品表关联着它），软删才是安全底线。顺手加上 updated_at 和 deleted_at（仅软删时更新），审计和恢复才有依据。
真正容易被忽略的是：所有业务查询必须默认加 WHERE status = 1，连后台管理列表都不能漏——曾经有项目因少写这一句，导致禁用分类在前端意外曝光。
