specMap.values --->>> iter
name += " " + value;
体现了JSON 的强大之处。
tb_spec id --->>> varchar  所以要转换成 String
category -- >>> ???
整个方法要被事务管理，既然加了事务管理，那么提示 interfaceClass = SpuService.class
这是由于被动态代理之后发布的服务是动态代理的service interface
使用cglig 的动态代理方式，并且在@Service(interfaceClass = SpuService.class)
同时操作多个数据表，要保证他们同时成功，如果同时不能成功，那么就让他们同时失败。
然后在参数的位置加上@RequestBody
可能因为他不是一个简单的实体类吧，毕竟在pojo中定义了的，而且类型相符合，所以不写@RequestBody 行不行?
品牌? 是什么？
找到品牌的列表，很常见的需求，我只看小米的手机，我只看苹果的手机？
一个品牌有多种产品也就意味着有多个分类
比如说小米的电子产品，小米也有平衡车。
联合主键。或者没有主键的表，都不会生成实体类。
很明显，这种表只是用来维护关系，而并非对应生活中 的实体entity pojo
手动创建pojo 只有两个字段 维护着两张表的主键。
比如手机的分类下有一些品牌，而实际上这些品牌不会出现太大的变动。
很有可能一个衣服的品牌，根本就不会出现在手机的分类下面。知道了吗？
注意到这里的分类是三级分类。

specMap.values --->>> iter
name += " " + value;
体现了JSON 的强大之处。
tb_spec id --->>> varchar  所以要转换成 String
category -- >>> ???
整个方法要被事务管理，既然加了事务管理，那么提示 interfaceClass = SpuService.class
这是由于被动态代理之后发布的服务是动态代理的service interface
使用cglig 的动态代理方式，并且在@Service(interfaceClass = SpuService.class)
同时操作多个数据表，要保证他们同时成功，如果同时不能成功，那么就让他们同时失败。
然后在参数的位置加上@RequestBody
可能因为他不是一个简单的实体类吧，毕竟在pojo中定义了的，而且类型相符合，所以不写@RequestBody 行不行?
品牌? 是什么？
找到品牌的列表，很常见的需求，我只看小米的手机，我只看苹果的手机？
一个品牌有多种产品也就意味着有多个分类
比如说小米的电子产品，小米也有平衡车。
联合主键。或者没有主键的表，都不会生成实体类。
很明显，这种表只是用来维护关系，而并非对应生活中 的实体entity pojo
手动创建pojo 只有两个字段 维护着两张表的主键。
比如手机的分类下有一些品牌，而实际上这些品牌不会出现太大的变动。
很有可能一个衣服的品牌，根本就不会出现在手机的分类下面。知道了吗？
注意到这里的分类是三级分类。