@wzzzx 当然是拆需求呀，譬如一个大需求拆成 3 个功能，那么建 3 个 feature 分支不就好啦

看了半天也没明白楼主在说啥。。。拦截对象的意思是一旦实例化某个特定类型就先拦截，然后在拦截器里面处理完了再实例化？那不如这个类型的构造函数里面处理这个逻辑好了。还是类型已经实例化，但在调用对象方法时候进行拦截？这种策略模式就解决了，要什么 aop 。

所以不要什么流行学什么，而是用到什么学什么。

对着吹确实不舒服，和温度没关系。楼主可以买几个挡板，不买挡板也可以把伞打开挂上面。

哈希匹配莫说上万，就是几千万也是一样的速度。但有些带路径参数的 url 就做不了哈希，只能上正则，正则匹配就要遍历数组了。

所以优化的办法就是把哈希和正则分成 2 个集合，先哈希再正则。

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

翻出去就正常

二次验证才是正道

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

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

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

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

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

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

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