门槛低但上限高，同时学习曲线是阶梯型的（有资质的人平缓前进，无资质的人被淘汰，没有捷径）。这个是 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` ，都要依赖查出来的值，不能一个用查出来的，一个用底层存储实时的——绝大多数事务隔离级别下，这俩不是一个值。

定住压力别要娃，15w 你想干啥干啥。你要是准备要娃，这 15w 连零头都不够，哪来的功夫去考虑怎么用。

文档收费的，一律好死不送。就是以前的收费微软，也从来没对 MSDN 文档收费过。

文档是软件的入口，文档收费就等于关闭了软件的宣传口，这从纯商业化的角度上来看是非常蠢的。蠢人做得东西，倒贴钱都不能用。

不要太过高估自己，你写的 wiki 绝大部分人，甚至还包括将来的你自己，都是不会看的。

说了那么一长一篇，结果连 SPL 的基本原理都没说。通篇没提数据库本身，这 SPL 大概率还是要转译成 SQL 才能执行。那么它的竞品就该是 ORM 和 代码，不该是 SQL 。如果你要跟 SQL 搞竞品，那么你的客户应该是各数据库厂商，而不是程序员或数据员。

这种把对面当傻瓜的事，还是去找真傻瓜吧。

@yodhcn #8 换个 h264 视频再试试，你还可以试试去掉硬解用软解。还没看出来，就再弄个 h265 的。如果你买的是品牌机，有些会内置优化硬解，这东西你要在自己组装机器上会体验的很明显。