随着智能设备使用规则上网的需求日益增长，我们需要着维护不同平台的软件规则。Stash 能让您在不同的设备使用相同的规则，获得一致的上网体验。

Stash 是一款 iOS 平台基于规则的多协议客户端，完全兼容 Clash Premium 配置，支持 RuleSet 规则、按需连接、SSID Policy Group 、JavaScript 脚本、MitM 、HTTP 改写、覆写配置文件等功能。

▎功能亮点

无缝兼容 Clash Premium 配置： 不需要一行修改，将你的 Windows / Mac 平台的 Clash 配置直接导入 Stash 即可使用。另外配合 Overwrite 功能，可以在保持订阅配置的前提下自由覆写配置内容。

Rule Set 规则集： 专门为海量域名优化的规则集加载器，Stash 在 iOS 15+ 下可以加载百万级 Domain 规则或 500,000+ IP-CIDR 规则的 Rule Set 文件，适用于去广告、地区 IP-CIDR 分流等场景。

MitM & Stash Engine： 支持使用 MitM 和 Stash Engine 捕获连接，捕获后的连接可以支持重写和脚本等高级功能。重写支持修改 HTTP header ，重定向或拦截等多种策略。脚本支持使用 JavaScript 改写 HTTP(S) 请求。

▎兑换码 🎁

AEEXFM66TFHL T7RRA4YATYKL A39LT4JT7WM3 RFXX9EWA6TKN Y4A3R9YEM6X9

与此同时，我们还会向楼层结尾为 8 的回复评论，PM 我们 Twitter （个人简介） 送出邀请码，如 8/18/28...188 。 回复评论请遵守 V2EX 社区规则，请不要用刷回复的方式 ❤️

买基金买了 4 万，亏了 6000 ，麻了

没登录之前，打开两个 b 站的网页 A 和 B ，在 A 网页登录，然后刷新一下 B 网页，发现 B 网页也显示登录了，这是什么原理呢？

官网链接： https://www.apple.com.cn/shop/product/MN713FE/A

地区是四川成都

2022 年 1 月 26 日～ 2 月 26 日，两口之家用了 437 度电（去年同期使用 273 度电），这非常的不正常。

现在已经打了 95598 了，95598 作为客服平台，只能反馈给所在片区。

所在片区的负责人说是我们冬天开取暖器造成的，翻看记录日用 20 度左右。 但是取暖器功率最高也就 1000 瓦，每天要开 10 个小时，30 天才够 300 度。（每天开 10 小时，取暖炉都得开坏了吧，更何况这个东西也不是每天开。）

现在片区负责人说：如果我怀疑表有问题，可以去把表拿到第三方检测，但需要自己出检验费，当然，如果表真的有问题，那么电力部门补齐、赔偿这部分费用。

但是问题又来了，在上周，电力部门说旧表达到使用年限，为整个小区全部更换了电表，旧电表已经被收回了。现在把旧表翻出来，还能是当时的表吗。

对了，顺便说一句，电器关完，电表没走了，已经排除偷电的可能性。

现在就想请教 V 友们
1 、这种表出问题的可能性大吗？

2 、现在如果真的让电力部门从仓库把旧表找出来，让我拿去检验，胜算的几率大吗？

3 、如果不是电表的问题，还有什么可能性，会使用那么多的电？

4 、现在应该怎么办呢？

刚发布的, 27 寸 5K 显示器，自带摄像头和音响，还有一颗 A13 芯片。没有 ProMotion ，也没有 microLED 没有 HDR 。

基本就是 LG Ultrafine 5K 的金属换壳版本。亮度从 500 到了 600nits 。同样的 P3 ，原生支持 TrueTone 。

售价 1599 美金，比 1299 美金的拉胯 LG 5K 还算良心了吧。

在等 27 寸 5K 显示器的下单了吗？

果然是两块 M1 Max 拼起来...

场景

订单存在 flag 字段，0 未支付，1 支付中，2 支付完成。 发起支付场景中，会先查询订单状态是否为 0 ，然后更新为 1 ，并且调用第三方支付系统获取 h5 的支付地址(耗时操作)。用户在 h5 上完成支付后，第三方支付系统会异步通知到后台服务。进行订单更新动作，并保存流水号。

具体代码

支付发起

支付发起之前，会查库，判断 flag 是否为 0 ，可以的才会继续

异步通知

接收到第三方系统的异步通知后，会查库，判断 flag 是否为 1 ，可以的话才会更新订单。

问题

高并发下，第一个线程查库，查到 flag 是 0 ，在数据库没更新完成的情况下，第二个线程也来查库，查到是 flag 也是 0.同时发起了支付。如何防止这种场景呢？假设在单节点情况下，直接加 synchronized ，可以避免。但是这样的话，是对所有的线程都进行了阻塞，实际情况下，我们只是要对相同订单进行阻塞。不同订单不进行阻塞的。

在异步回调的情况也是一样，也是要先查订单状态 flag 为 1 的话，才会进行下一步动作，如果并发情况下出现了 2 个线程都查到是 flag 为 1 怎么处理？

目前思路

加锁，但是锁了所有的线程，订单 1 多个线程同时发起支付的话，需要加锁阻塞，只能有一个发起成功，但是不能影响订单 2 的发起支付。实际上只是为了锁同一笔订单。

用乐观锁，然后数据库 update 的时候，where flag=某个条件。一定会有一个线程更新失败，更新成功的才会进行后续操作。这样的话，会对数据库有影响吗？

想请问大佬们，这种先查库得到条件，再根据条件做后续动作的场景，在高并发下应该如何处理呢？

家里电饭锅用了两年多了，锅底有很多划痕，现在煮饭锅底老是会粘住，所以想换一个，预算大概在四五百。

这几天看了一下某乎，说是铁釜的锅会比铝合金的好，电磁加热的比锅底加热的好，就是比较贵，低端的电磁加热似乎不推荐。目前看了几款美的和苏泊尔的，价格三百多的，似乎也不错。

想问下各位老哥有什么推荐的么。。谢谢。

场景：某小区不认外来的电动车进去
我询问了一下原因，保安耐心解释今天在做核酸，出来人比较多
我听到后如何表示谢意

跌跌不休，下面怎么走？

开源：提高省钱水平是一回事

节流：是另一回事

好奇各位的省钱方案