@longfxxx #1 会自动初始化的
@whitehack #2 不加锁并不会 panic ，只是添加的数量不对，估计右边 panic 显然不是左边这个代码能产生的

你这图和你右边的输出似乎没啥关系吧

@iplayio2019 #3 replace 也需要间隙锁吧，似乎并不能解决这个问题来着

似乎你这个应该删除改成先查询出主键，然后用主键来删除，应该就没这个问题了吧，或者用外部锁来串行化也行，删除时可以先查询下看看，如果只有一条就改成更新估计可以提高一点性能吧

@banlifeather4 #18 你这个并没有解决问题吧，且不说最简单的设备不在线就走不通，毕竟不是大厂设备在线率不能比，再者用户改密码大多可能有异常登录之类的，既然异常登录了，那说不定 WS 就没用了呢，所以你这个方案是无所谓的正常改密码能正常踢下线，必须要改密码的异常情况恰恰可能反而踢不下线了，反着来么

技术不是难点，难点是如何让国家机关承认你提供的是合法有效的，如果你能搞定国家机关承认你提供的技术方案是合法有效的，技术实现真分分钟的事

@murmur #14 这两者不是一回事，前者叫复制，后者叫伪造

@huxiaofan1223 #8 因为好多不知道 cookiejar 的，所以各种传 cookie 和 session 对客户端不友好也真是。。

@banlifeather4 #15 我猜改密码这个的意思是用户登录了两台设备，在其中一台设备上改密码了，无法把另外一台踢下线，否则就得查询用户状态了，这样还不如用 session 了

所以服务端先循环读直到读取到 4 个字节解析出长度，然后再循环读直到读取到前面解析出的长度为止啊，客户端也是，没写全，就循环写后续数据就是了，做个切片就可以取出剩下的数据就是了，而且 go 的 write 缓冲区满了是阻塞写的

既然你已经想到不能避免重放，那就别怀疑了，没有人可以超越物理限制的，事实上这个是用来权限验证的，你看签名需要密钥吧，而这个不会放在参数里，一般没有防止重放攻击的作用，想防重放可以加入时间参数，签名校验成功后检查超过一定时间拒掉就是了

不是我说，这已经 2021 年了，大站点每日内部外部各种请求调用的都奔着万亿级去了，小站点依然受益于各种基础设施的进步，9 台那么大内存的 web 服务器处理每月几亿 pv 绰绰有余了吧，你说每月处理数百亿 pv 我感觉都能信了

你想的是对的，这就是分层抽象的逻辑

@Chad0000 #39 不，我说的只是下单失败的情况，按这个逻辑，Lock 库存需要在商品有效性检查的库存校验时就要完成，而实际业务中下单后续商品还有其它校验流程，接着还有地址检查，优惠券营销促销折扣，风控校验等等一系列过程，这些都是要做一致性绑定的，更不要说后面的支付流程了

@Chad0000 #35 那你这如何和下单流程的事务做绑定呢，先减库存的话，万一你这下单最后又失败了，你这库存如何恢复，后减库存的话，中间有时间差，也不能保证不超卖吧

@gosidealone #30 必然的啊，否则事务用来干嘛的，所以实际业务中多件商品下单这种操作如果不排序，分分钟死锁

@Augoror #21 app 都有“XXX 有权在不告知用户的情况下修改本协议”，这个肯定是违法的，你要是有闲有钱，去法院估计一告一个准，或者工信部投诉一把估计都能让 app 下架

听多了客户是上帝的宣传，所以是真要把自己当上帝了么？厂商提供的用户协议叫格式条款，你同意就用不同意就别用，厂商这么设计本来就是基于成本及商业利益考量，这本来就是双向选择的过程，厂商也没理由无原则迁就你啊，还“用户可以在不告知厂商的情况下修改本协议”，想什么呢，固然现实生活中比如微信这样的依据市场支配原则占据优势地位，但也只是代表他必须遵守更多规则承担更多责任，讨厌归讨厌，法律可不会因为你讨厌就偏向你的

sql 没问题，但是实际业务中意义及用处不大，正常的订单中不可能只买一件商品，以及下单过程中还有优惠折扣促销处理等等的流程，这样即意味着大量的回滚流程且开事务时间过长，效率不会很高，而且多件下单的时候很容易导致死锁问题

@h2dyn #1 我看还在，下不了么？

https://pan.baidu.com/s/1VG9wsPqXzMQOcodLrQNLOg
提取码：2q3z

那我建个新的吧

这视觉设计，没见过这么二的，方格设计人眼看去就是一片黑，搜索结果本身就是极其注重阅读体验的，啥都看不清还找啥，搜索本来找的就是结果，这是还得让我一个一个凑见慢慢看啊