@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 可以被静默忽略的特性一定会成为灾难。

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

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

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