代码里，尤其是接口处不要错，其他能看懂就完了

吃完了舒服啊，降低痛苦啊

Linux 只用作服务器，开发和日常还是 Windows ，Linux 好多软件游戏跑不起来，同时没遇到什么必须切换到 Linux 的问题，所以就保持 Windows 了。买不起 /无法接受 Mac

有些人总喜欢不管成功与否皆返回 200 ，于是为了鉴别成功失败（会对应不同的响应体 schema ），必须给所有请求的响应体包裹一个 wrapper ，彻底侵入响应体，既不考虑违反 HTTP 带来的麻烦（监控等等），还导致响应体必须是个 JSON （不然没法包裹了），美其名曰方便区分「系统异常」「业务异常」，实际上连故障和错误都没划分明白（这里点名批评 Java 的 Exception 类型）。
更有甚者，包就包了，他还把成功和失败时的内容载荷给你丢到 wrapper 的同一个字段里，导致必须先把 JSON 解析一次，知道了是成功还是失败，才能用正确的类型把载荷再映射一次，病得不轻。

@fhj 所谓的线程本地副本，是为了和现实世界中变量可能被优化掉 /存到寄存器里 /跑到高速缓存里等情况对应。volatile 保证“可靠一致的访问”（ JLS 原话），不是说不加就一定不一致了 （以上那些情况不一定会发生）
你这个例子就是因为种种原因，以上那些情况没发生，或者不良的副作用被别的因素抵消了

不存在什么业务异常、系统异常；业务上的冲突，是客户端发起的请求引起的，比如余额不足、用户名冲突等等，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 曾经有过一个方案可以，实际上是私钥上交