现在手上是 AOC 卢瓦尔，用了 1 年，感觉可以。
现在准备再买一台，但是卢瓦尔不讲价，我现在准备上 AOC U27N3C

为什么要回怼，为什么要帮他醒悟，这种人就让他傻逼一辈子好了

午休, 并且要平躺, 只需要 15 分钟,就可以解决你的问题.

同意 18 楼，定义好 鸡与鸡蛋，这个问题很容易解释

这太离谱了. 就算是人人都骂的百度网盘, 也没不要脸到这种程度吧.
太可怕, 我准备迁出坚果云了.

@kevinonepiece
以我个人的使用经验, 我觉得多次简单查询对比关联查询有以下好处:
* 有效使用数据库缓存
* 关联的表多了,且没有用好索引, 一次查询的时间就更长. 这种并发查询多了, 就会导致数据库压力骤增. 例如:一次查询要 100ms,那么在未来很可能成为慢查询,进而可能导致雪崩.
* 减少锁的竞争
* 尽量降低数据库压力, 毕竟数据库的扩容比服务器扩容难多了. 在开发时,就让 sql 足够简单, 未来一旦出现数据库瓶颈, 大部分的代码不用考虑 sql 优化了, 直接升级数据库吧.
* 随着数据量的增加, mysql 的执行逻辑也会变化. 虽然开发时不是慢查询,但以后可能就会变成慢查询.
但并不是所有的关联查询都拆分, 对于效率非常高的关联查询, 还是不要拆分.

1. 简单查询用 ORM, 稍复杂的都直接写 sql
2. 把复杂查询拆成多个简单查询.

现在的 mac 还能做到长时间不关机？

1. 根本原因是你们的 leader 没有尽责.
2. 如果我是"老大哥", 我会说服 leader 落实编码规则.
如果我是"老工程师", 我才不胡惯着你. 公司不需要老好人.
如果我是你, 我不会来这抱怨, 自己代码没写好, 被别人指出, 那是我的荣幸.

"老大哥"和"老工程师"技术都好, 一个指出你的问题, 一个顺应你的风格, 你就对他们表现出不同的态度, 你可能需要反思自己.

另外, 代码规范与风格是两码事, 这两个人比较不合适.

谁最终为该系统负责，那就听谁的。当然，还是要以理服人，举例说明该方式在未来的隐患。

影响薪资的除了年限，还有学历和能力，能力又分多个方面，对薪资的影响都很大，你在这问，根本没有意义，不如去看看招聘信息

@zdt3476 polardb 不能代替分区分表吧, 分区分表是根据业务键来分的, polardb 做不到.
polardb 主要是计算资源弹性, 存储分布式. 即使它能根据索引让数据分布于不同的磁盘上, 也做不到跟你的需求完全一致的吧.

goland 可以让你专注于开发本身, 而不是各种插件的安装配置.
vscode 的 go 插件, 我用了一段时间, 不稳定, 放弃.

同意 6 楼观点。直接发帖就行了，没必要搞技术群。群的形式也很难对一个问题进行针对性的讨论，天然就不适合。

这不是类型擦除导致的, 而是因为你就没有传入具体类型, 程序自然不知道你要反序列化为什么玩意.
jackson 在反序列化 json 时, 需要传入目标类型的 TypeReference, 其中需要指明泛型的具体类型. 如果没有指定, 同样不能反序列化.
jaxb 也是一样.

即使能实现, 那也是通过遍历,或者你指定的一些规则, 去猜测这个泛型可能的具体类型.

在微服务中使用 spring security oauth2 后, 我很后悔.
因为需要实现一些其中没有的 但并不复杂的特性, 得先看大量源码, 然后再改. 真折磨人.
花费的时间比自己手写都要长.

当然, 也可以说是自己选型失败, 对 spring security oauth2 的细节不熟悉, 导致与需求不符.