此外，我想发表一个暴论，互联网中相当一部分 Bug 和岗位都是那些喊着用分布式锁的程序员凭空创造出来的。

同样的问题在 PostgreSQL 中不存在，PostgreSQL 使用 SERIALIZABLE 隔离等级时，这种 select + update 的并发操作，并发事务中后来的 update 操作会报错回滚， 这就是为了避免 lost update ，同时 PostgreSQL 也不允许刚才说的那种取巧的办法，同样会报错回滚，因为 PostgreSQL 认为并发操作导致的这种反常是一个问题。

MySQL 在默认的 RR 隔离等级下会产生 Lost Update 现象，会导致你的问题。
如果你一定要这么写，请考虑将事物隔离等级调整至 serializabel ，这是最简单粗暴的办法。MySQL 的这个隔离等级实现不良，性能可能比较差。
另一种办法：使用 SELECT...FOR UPDATE ，它会产生一个显示锁定，可以用于回避这个问题。
还有个取巧的办法：使用 UPDATE ... SET balance = balance - 100 这样的写法，MySQL 在这个情况下不会丢失更新，不会导致数据错误，只是如果你在前后 select 时，可能会发现 300 - 100 = 100 这样的诡异现象，MySQL 团队不认为这是个问题。

他们能不能跟这玩意儿合作一下，这多好听啊 https://aivoice.jp/product/gumi/

怎么总看这个帖子蹦上来

@Chad0000 CF 和阿里合作了？

感觉楼主这是心态问题，建议找时间休息休息调整一下

@lesismal 就算看不懂他这么回复也很怪吧，正常一点的回复甚至可以是要求对方手把手教，起码是正常回复

人家这话里的意思不就是 z-index 合不合理很难讲吗？事实上这东西就是没法评价合不合理。
人家还给你说明白了可以如何调整，你来句“果然大厂风范”，我倒是想知道你是什么意思了。
打架？
还是说你只能理解合理/不合理这种二值逻辑？

@nothingistrue 也不能这么说，这个数据库还是以城市为基准，只能说今天用的最多的是上海，翻翻数据库历史上还是有好多个子标签的

@hahastudio 这个标准确实不错，唯一的遗憾就是它好像不是那么权威

@xmumiffy UTC+N 表示的是自然时区，和 CST Asia/Shanghai 这种表示对法令时区不一样。不是准确不准确的问题，这根本就不是一种东西。

现在还是优先用 IANA 时区标签比较好，Asia/Shanghai 这样，虽然不是什么权威，但基本是比较好的事实标准

出国也难办啊，先不说前置学历要求，去欧洲要英语，去日本要日语，不过去日本的话可能语言学校可以用来缓冲一下

业务不诉诸技术诉诸什么？无非是不同的取舍而已，别说的这么清新脱俗。虽然我不赞同他的解决方案，但是你这种思想问题更大，他的方案不够严密只是水平问题，你这是路线问题。
不妨先想想所谓的「业务解决方案」真的只是业务吗。

@ysc3839 我用 GOOS=darwin go build 出来的程序似乎只是会弹一个警告对话框？通过一些技巧好像还是能运行的

@ysc3839 没有签名的程序 mac 是怎么处理的？非 mac 用户，交叉编译出来的程序也不会考虑 mac 下的要求

把每个参考文献都看一遍吗，很多参考文献都是新闻吧好像

DDIA 咋还能这么使劲读