@d3js #20 想想苹果为啥禁止越狱？羊已经圈好了，怎么可能会希望羊能自己开门跑了。解锁 BL ，就是手机领域的圈羊标志。日厂索尼不懂圈羊，一加至少到现在为之没想要圈羊，所以一直都是能自由解锁 BL 的。摩托罗拉、三星开始不让解锁，后来圈羊失败了，就让解了。华为就是国人典范了，初始阶段诱羊的时候各种自由，羊引诱够了就锁门了。小米更是典范中的典范，关了门都还要做出来门还开着的假样子。

这玩意要看地方：欧美那里就是租房；日本就是名买实租（来得时候买，走得时候卖，说是买房，实际上就是租房）；国内是能无压力买就买，买不了就租。

国内租房最大的问题是：房东随时都可能卖房。就是政府的廉租房，你都可能因为房东卖房而必须搬迁。

自己给了权限，还问别人能不能看。相当于自己拖了衣服，还问别人有没有看到。

深入使用 GIT 即可。

门槛低但上限高，同时学习曲线是阶梯型的（有资质的人平缓前进，无资质的人被淘汰，没有捷径）。这个是 Java 最特色的，同时是优点和缺点。

比较编程语言，这就跟比较英语跟法语一样，毫无意义。

核心问题——开了 Java 插件，资源占用比 IDE 还高——不解决，其他的在搞都没意义。

为了照顾不懂 TOTP 协议，和不知道二维码本质就是一串字符的小白，2fa 的使用方式一般仅提供二维码自动设置，不提供 TOTP 密钥/TOTP 协议 URL 手动设置。然后遇到了不知道密钥可能是动态生成的小白。

@kingjpa #9 员工跟老板是什么关系？以前的狗奴才都没有你的奴性重。

因为 createDeserializationContext 有重载。

公共分支不能做 rebase ，提前把 rebase 排除。

@k423 背调重要看得是历史工资真实度，和有没有竞业风险，有些还会看学历真实度。我不敢保证 100%不会背调离职原因，但是一般不会。这玩意没啥意义，而且就算查出来了也用不了，涉嫌职业歧视。

面试的时候可能会问，这时候要么不回答要么如实回答，一般都是随口一问，真要是招人的（而不是 KPI 面试）大多不在意这些。一定不要回答成主动离职，不诚信才是大忌，另外还有可能主动离职还不如被裁。

名义上主动离职不能领失业保险。但劳动法规定了就是暴力开除也不能在离职证明上写不利于员工再就业的信息，导致对外展示的离职原因，100%是员工个人意向。

脸皮厚点，该领就领。

不开插件的 vs code 。

接 #17 再说一些业务上的事。这篇要说的重点是：性能优化不是对业务透明的纯技术实现，好的性能优化往往判随着业务优化（即业务功能变更）。

先把那三个 SQL 转化成业务描述，这样更方便一些：
SELECT * FROM `api_credits` WHERE `uid`='22' LIMIT 1
——①、查询出指定 uid 的当前积分情况
UPDATE `api_credits` SET `credits1`=`credits1`-'100' WHERE `uid`='22' AND `credits1`>='100'
——②、对①查出来的积分，做积分扣减操作（原本的逻辑应该是「如果当前余额大于阈值，则计算最新余额后，更新为最新值」这种代码）
INSERT INTO `api_credits_log` SET `uid`='22', `cid`='3', `credits`='100', `balance`='79900', `time`='1701001020'
——③、对②所做的积分扣减做记录，需要记下变化后的余额

首先来说，在上面的场景中，第②步骤应该使用原本的代码逻辑，不该使用优化 SQL ，因为你已经做了第①步的查询，导致这种优化是无效的。② 这种优化方式，主要就是为了避开查询 SQL 上应用跟数据库之间的网络交互时间，那么你如果要用这种优化，就必须避开 ① 这一步。当你使用 update ... set col = col - num 这种 SQL 的时候，你需要避开任何相关查询 SQL ，通常你更应该用「一句」 SQL 完成整个业务操作。

然后，你之所以要做①，是因为③当中要记录余额。这时候你会发现，使用 「 update ... set col = col - num 」来做优化的性能要求， 记录余额的功能要求，是冲突的。如果你要就地修改，那么就无法同时获取余额值，包括修改前和修改后；如果你要获取修改后的余额值，那么就必须先将当前余额值或者修改后的余额值查询出来，不能单纯的就地修改。

最后就是要做选择的时候了，既然高并发性能要求跟记录余额的功能要求冲突，那就要做 2 选 1 。通常都会选择不记录余额，即余额变更记录，只记录变更事件、变更金额，不记录变更后以及变更前的余额。相比与高并发/快速扣减、不能超扣、事后可查每次的扣减记录这些核心业务，扣减记录上的余额展示，就只能算作边缘业务被抛弃了。这是有现实示例的：信用卡账单基本都这样；对于套餐类型的移动通话，你要去查通话详单，它的详单条目上也只会有通话时间，没有通话后的套餐剩余时间——如果你要精确对比，还得自己算；有些银行的借记卡消费提醒是只提醒消费多少不提醒消费后余额的。

搜狗输入法、QQ 输入法、微信输入法，不过是腾讯内部三个部门之间的 PK 罢了，外人就没必要参与了。

不要让数据库做业务的事，这事 mysql 干不了。



你的业务逻辑本事是有问题的，属于性能优化事故。
既然第一步查出来了，那么后面 UPDATE `api_credits` 跟 INSERT INTO `api_credits_log` 时候的 `balance` ，都要依赖查出来的值，不能一个用查出来的，一个用底层存储实时的——绝大多数事务隔离级别下，这俩不是一个值。