sorry 没看时间，忽略我

老哥还有位置吗

所有的 feature 分支合并到主分支之前，都需要先合一下主分支处理完冲突，而不是在这个 merge 中合并，因此 feature 分支和主分支的交点只有一个简单的 merge，如果发现某个 feature 分支的内容有问题，那么 revert 这个 merge 就好了。revert 的复杂度取决于你们在该 merge 的基础上做的改动量。

主要写 java 也写过 go，真想学一下咋把 go 写出 java 味。。

@suke971219 我就是后端啊，所以说只差个前端

6 了 idea 已经有了，就差个前端了

@myqa 说 API 差不多您肯定是没用过原生的 jedis 和 lettuce，“肯定使用上层包装”也是 6

确实有点为赋新辞强说愁的感觉；

楼主为了解决关系型数据库的模型、语义等和 Java 的对象模型不一致的问题，发明了一堆注解和一个 DSL ；
其他人为了解决同样的问题，发明了一个概念叫对象关系映射，同样的，发明了一堆注解和一个 DSL （ Criteria ）；

so，大家都是一样的东西，你这个咋就“完美的解决了上述两个问题”呢。。。

lettuce 的优点一直不是性能啊。。。而是可以复用的连接、易用的同步 API 、统一风格的异步 API 、完备的功能和对 Redis 新特性的支持

6 了

@gantleman emmmm 可能是我没说清楚。“游戏服务器对性能要求非常的高”这种结论一般是横向对比 web 服务器得出的，通常的逻辑链条是：游戏业务延迟敏感+连接数少运算量大 = 性能要求高 --> 要用 C++实现。我想说的是，在客户端的角度，服务器实现成什么样并没有区别，所以，没必要非得上 C++。

纯函数的话，这个想法是可行的。。然而纯函数的单测很容易写，通过这样的方法生成用例感觉绕路了。

其实不太能理解游戏服务器对性能要求非常高这种结论是怎么来的。。。对客户端来说，绝大多数 RTT 都在网络传输上，无论服务器实现成什么样，也就是响应时间增减几毫秒的问题，当然可能有个别业务特别耗时，但不会影响玩家的整体体验。因此，为啥非得上 C++呢。。。Java+ZGC 可以把暂停时间控制在 10ms 以内，大多数时候不超过 2ms 。。

盲猜是 Jackson，请自行实现 JsonDeserializer ；
其他的 json 库也都有类似设计。

如果对测试特性没有什么心理障碍的话，可以试试这个

https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/experimental.md#run---mounttypecache

可以缓存编译的中间产物

@ohoh 感觉你在嘲讽 yinxiang notebook

@passerbytiny
1. 序列化(Serialization)是将对象的状态信息转换为可以存储或传输的形式的过程，反序列化是相反的过程。JSON 是一种可以存储或传输的数据格式规范，因此把对象转换成 JSON 的过程就是序列化，把 JSON 数据转换为对象的过程就是反序列化。这中间并不需要转出来的 JSON 和原来的对象一一对应，甚至不需要转出来的 JSON 能通过反序列化还原为原来的对象。不是很懂你对序列化有什么误解。
2. 能举一个活得还不算差的基于 Java 序列化的 RPC 框架吗，我觉得同时支持多种序列化方式的 RPC 框架可能不能算，因为有选择的情况下，多数人应该不会选它。。
3. 由于历史包袱，Java 中的确存在大量的不被推荐使用的 API，它们可能没有被显式标注废弃，但的确是在被逐渐减少使用，包括旧的 DateTime 相关工具类、clone 方法，也包括 Serializable 接口。