@ruxuan1306 你这样搞百害无一利啊，今天兼容了，明天又变样了你兼容不兼容，某日几种模式冲突了你怎么办，屎山多了你糊出 bug 了怎么办。这种接口本来就一挺简单的事，从源头把问题都解决了对大家都好

😰你希望它有什么功能

此外后端如果不是 bff ，你不能要求它完全按照前端页面设计，这 API Web 前端用完了客户端可能还得用呢，不是说你展示在一个地方后端接口就一定是一个字段，前端该做的事不能偷懒。

当然命名风格还是应该尽量统一一下，不要同一个接口都混合不同的命名风格。

不要尝试兼容，否则后患无穷，严格校验数据，出错就报 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 可以被静默忽略的特性一定会成为灾难。