多拆几个 feature，每个 feature 对应一个 feature 分支。然后大家各写各的 feature 代码，提交的自己对应的 feature 分支就好了。
要注意的是拆分 feature 时不要让代码有交集。如果有公共的代码，提取出来交给专门的人负责，或者在动这部分代码的时候相互打个招呼。

翻出去就正常

二次验证才是正道

@tctc4869 真想造轮子就自己造呗。如果不是，我劝你还是 http 吧……

楼主如果自己用，那随便整一个协议就完了。如果要开放接口，还是乖乖用 http 吧。虽然效率低，但优点是方便。你整个别的什么 gRPC 这种，如果需要专门搞个 client 的话，还真的挺费事。

楼主你说的运动 -> 运动鞋 -> 足球鞋是一个 3 级分类，但「让一双足球鞋能在客户点击这三种类目时都能展示出来」，可以通过给足球鞋打三个标签（运动|运动鞋|足球鞋）来实现。

楼主说的速度起飞，大概就是 30 毫秒的响应时间变成 3 毫秒。这点提升其实体验并没有那么明细，所以根本不重要。

不用考虑，直接大厂。刚毕业，你想啥呢？你哪来的信心能解决创业过程中的各种问题？

多画几个思维导图，把层次结构和关系先理理清楚，然后把不必要的都干掉，剩下的就是简单的了。

@sampeng 微服务还真不需要专职的运维。我们团队也就十来个人，里面还包括了 4 个测试，并没有运维，但我们玩微服务还是很溜。如果没搞微服务，还真的应付不来 4 个产品的疯狂输出。

MySQL 单表的各位是不知道有 MongoDB 吗？

微服务从麻烦到真香，中间只差几个工具而已。你需要 CI/CD 、自动化的容器化部署、全链路日志追踪、能够进行统一身份认证和鉴权的网关。最好还要有用户管理、权限管理、消息管理、账户管理、统一支付接口等等。当这些都具备的时候，微服务就能够让你专注于业务了，一两天功夫一个业务就简简单单发布上线，真香。

打工商局电话投诉会比较有用。

mybatis 也可以用注解，不写 xml 。

譬如：
/**
* 查询报表模板
*
* @param dto 查询参数 DTO
* @return 报表模板集合
*/
@Select("<script>select id, `code`, `name`, remark, is_invalid from icc_template where tenant_id = #{tenantId} " +
"<if test = 'keyword != null'>and (`code` = #{keyword} or `name` like concat('%',#{keyword},'%')) </if>" +
"order by created_time</script>")
List<TemplateDto> getTemplates(SearchDto dto);