不要尝试兼容，否则后患无穷，严格校验数据，出错就报 bug 让后端改。一旦提到兼容，你很难定义清楚兼容的边界，到时候指不定出什么幺蛾子。
@bianhui 反爬应该用工程手段解决，而不是让人直接在代码里写 abcd 。至于你说的第二个问题，接口和内部实现无关，不应因为内部实现影响接口，这点对前后端都一样。

你要是担心数据库 group by 构造月份比较慢，我倒是觉得你可以试试 select (里面放 12 个 select)😁
但我往往选择相信数据库（

@n37r09u3 有个为中专准备的春季高考，是允许高中生报名的，但是高中生报名就只能考大专（中专生可以考本科）。

@sir283
@plasticman64
@soleeee
我现在想办法弄了个函授，虽然还没下来，但是之前看 top up ，似乎都对专业有要求😥必须是连贯的

此外 Java 的 volatile 有额外的语义，所以也没法和 C 对应，这样做 microbench 可能你们很难说明什么问题

@lesismal #145 <del>吹 Kotlin 时间到</del>

launch{
coroutineScope{ // 这个是作用域
launch{ 协程 1 }
val r = async{ 协程 2 ，async 有返回值 }
r.await() // 获取协程 2 的返回值
}
// 以上协程全部执行完，才会到这里，在此之前卡在括号里(因为 scope)；
// 协程 1 2 是兄弟，他们共属于外面的协程，也就是这里，顶层的 launch ；
// 因为没有 try-catch 捕获错误，一旦 1 2 出错，至少会一直取消到这里（协程支持取消）
}

写并发是不是心智负担大大降低🤣

@lesismal iseki0🤣互 fo

可以，去聚合函数里看看，肯定有

@lesismal 🤣🤣🤣这种特性可以极大降低编写并发代码的心智负担呐，我不信你不用 errgroup.Go 它就类似这种东西，只不过是个手动挡的🤣🤣🤣

对数据库而言乐观锁往往是特殊工况下的 workaround ，而且和业务关系密切，框架管它干嘛…

@lesismal
关于 async await 这个啊，给你看个 Kotlin 的例子
coroutineScope{
launch{ doSth() }
async{ getSth() }.await()
}
launch async 各开了一个协程，任何一个未捕获的报错都会导致沿着父子兄弟关系向上逐层取消（直到捕获或者是监视器域）此外 scope 内协程执行完毕前控制流也不会离开 scope 。这是 Kotlin 的 “结构化并发”。

你说 Java 封装的太狠这件事我一定程度上赞同，春天系我也不喜欢用…
此外轻量级线程确实是你说的这种意思，IO 等做了处理，否则就没意义了。

@lesismal 你说的没错，进程间通信机制这样的东西就是大厦的基础，是砖头，但是编程时如果每次自己去搬这一个个砖头这既不符合 DRY 的原则也不够“少”。async await 算是结构化并发的一种落地形式。
你不能说封装的程度高就一定是不好的，软件工程是权衡和妥协，君不见 Go 相比 C 不是也隐藏了许多细节吗，每个函数开头插入栈空间检查未必是个多么高效的选择，当年也有人因为用了“高级语言”就被喷浪费了机器性能。
systemd 出现之前，如今一个 .service 文件搞定的事情要一位 bash 熟练工写上成吨的 .sh 还不一定好好解决问题。看上去 shell 里的每一个命令都好简单啊，但是组合起来的结果你能说这是“简洁”的吗。当然这个我不多说，我相信每一个工程师都很清楚。

此外 Java 的轻量级线程和 Go 的 goroutine 差不多一回事，当然 syscall 该卡还是卡，go 也是在 IO 等等地方特殊处理掉的，这个不是应用程序自己做点什么就能解决的。（其它关于 Java 的内容我就不评论了，这个看场合见仁见智

@lesismal 事实上如果 Java 在绿色线程出现之后不能及时安排好结构化并发，我敢说 unhandled exception 可以被静默忽略的特性一定会成为灾难。

@lesismal 我似乎并没有鄙视 Go 这种 panic 即退出的设计，我只是说下这个设计在没有结构化并发时几乎是必然的，不知道你在激动什么……

Go 的 goroutine 本身设计我不认为太大问题，但它的暴露形式就值得商榷了。难以直接被使用的 "go" 变成了关键字，errgroup 这种东西反而变成了 x 库。
“标准库没有就值得一喷”，标准库什么都半残那还叫什么标准库？我也没说标准库必须要带一套结构化并发，毕竟 go 出现的相对来说还是比较早的，但是 go 关键字的存在，除了更好打广告外，几乎看不到什么必要性。

Go 中 goroutine 未捕获 panic 导致整个程序退出这是在这个整体设计下的一个必然，Java 的 Thread 不这么设计，它并不鼓励程序甚至是业务代码中动不动就开一个 Thread ； Kotlin 的 coroutine 不这么设计，是因为人家有结构化并发，君不见 Java 绿色线程出来后马上也在讨论结构化并发的问题了。
Go 这边不搞这个，那如果 goroutine 在发生例外时不 crash 整个程序，可能就是个维护灾难了。

Java 的 try catch 和受检异常怎么说呢想法是好的，但标准库中的类型划分个人认为有待提高，太多该被归于 Error 的东西被归类到 Exception 中了。

Go 的问题主要是消极路径的代码在毫无收益的情况下污染了积极路径的代码，而且因为处理是完全手动的，所以很容易出现人为错误（忘了 if 忘了 return 什么的）。这个问题不要用可以加 linter 来辩解，语言本身设计缺陷需要加一堆其他东西就已经是个问题了，说 Go 做的好的，看看 Zig 和 Rust 这么做的吧。

你们使用 IDEA 而非诸如 Maven/Gradle 的构建系统吗，脱离 IDE 时怎么办啊

Go 的 comparable 其实是可做相等比较的意思…和比大小不沾边。