不存在什么业务异常、系统异常；业务上的冲突，是客户端发起的请求引起的，比如余额不足、用户名冲突等等，4XX ；服务端的异常，比如数据库无法连接、资源不足等等属于故障，5XX

时至今日 HTTPS 已成基本前提，大多数场景不需要再考虑劫持这种稀奇古怪的事情了，为了规避劫持改变系统设计有些得不偿失

我也支持以 2XX 表示成功，以 4XX/5XX 表示失败，并在失败时内部包含业务用错误码的做法。这样的好处主要是不侵入响应体，可以兼容响应体是 JSON 以外内容的情况，同时也极大规避多态反序列化

早期的时候状态码非 2xx 会被篡改，同时没有传输层安全，所以衍生出了这种怪用法。现在很多人改不了，有些前端、后端因为自身水平问题竟然会告诉你不是 200 的就没法统一封装······然后他们还觉得他们这种统一封装的方法挺好，所以就这样了呗（直到现在在某些特殊的场景还会存在 200 劫持行为···）

不要把 user id 当隐私信息，id 这种东西保不齐什么地方就露出去了，不要依赖它保证安全性

看一看 Linux 的 keyring 机制？不管是不是 jwt ，凭据存储都是个问题，我看大多都无所谓了，直接往哪一丢谁爱看谁看了…

如果是扣库存，只要保证别 100 个商品，结果 10000 个请求打到数据库上、也别同一时间点 100 个请求全都在数据库上扣同一个商品，就没什么可担心的，数据库的性能足够。
扣余额就更简单了，限制下不要让一个用户同时发起一堆请求（这本来也该限制吧）
实现上可以用 update cas ，但存在限制不方便时直接 Serializable 性能不一定差（ PostgreSQL ）

@DinnyXu 这种需要全表扫来扫去的 SQL 一般都不会经常跑，也就是个定时任务，一个小时刷一遍排行榜之类的

个人不倾向这里用开窗，题目中感觉并没有明确提出开窗统计的需求，更多的其实是就是把多个统计维度的数据攒到一块了，那 with 几下感觉更好一点

@DinnyXu 如果性能敏感，以至于需要给其中的部分子查询增加额外的缓存，那才会选择拆开；否则这种简单查询直接一个 SQL 是最优解，不管是性能上还是功能上。

@movq 其实父类子类本来就搅合在一起了，不差构造函数这一点吧

用 with 拆开会更好一点

这东西因人而异因键盘而异，舒服就完了，我要总用小拇指按下左上的键，一会儿就抽筋了

@firechat 曾经有过一个方案可以，实际上是私钥上交

阿里的技术手册，其他实体应当仅供参考。

用 Kotlin 吧，Web 楼上有说 quarkus 或者 vertx 自己动手。忘了 Kotlin 还有个 ktor

什么是“自研”工资

还能返现金，这是什么操作

对工作没有明确影响，增加行业壁垒而已嘛，卷，请继续~~~