显然概率算错了，应该是 1/(16^4)
另外，mac 地址的前 24 位代表厂商，比如 F8DB88 是 Dell 的
所以对用户来说，这个概率实际上只有 0 和 1/256 两种情况，对特定品牌的用户来说应该很常见的

思科好像经常干这种事情，在代码里写死 magic number 拿来测试
比如 https://www.theregister.com/2018/05/18/network_roundup_17_may_2018/

没查到你说的 “很多已知明文攻击”

可以直接看
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
https://en.wikipedia.org/wiki/Advanced_Encryption_Standard

这两个页面都没说有风险，那么，在正确实现的情况下，aes-cfb 当然是安全的。
但是， “正确实现” 不太容易做到，这是个很高的要求。而且 cfb 也属于目前没人用的加密模式了，比如 TLS 1.3 的 AES 只用 aes-gcm 和 aes-ccm 。

我觉得 OpenPGP 这种看起来很靠谱的软件应该没有问题。

@wdold
国内可以直接存，外资银行都有这个业务，给你开高级帐户存钱，还给开海外帐户。
但是需要考虑汇率和利率变动的风险，还有外汇管制带来的风险。

@GeruzoniAnsasu

这个东西不难写，只不过它的写法和 JavaScript 惯用的写法可能不一样。
如果你觉得我发的这个不符合你的要求，你可以先用 Promise 写一版我来翻译成 Go
总体上 Go 不用写 "await" 这几个字母，其它和带异步且多线程的语言完全一样。当然 Go 自带的语言功能少一些，不限于异步并发关系时序这些，所有方面的功能都少。

> 有 promise 的情况下不需要这种可锁对象
多线程环境下的 promise 本身也带锁或者类似的机制。单线程的 JavaScript 是另一回事。

> 我们不能一次性等待一批 worker 全部完成，而是要时刻能分派已完成的 worker 占用的任务槽
这个和 Promise 有关系么？我没觉得用 Promise 可以简化这件事情的实现，拿到一个结果了再开下一个任务，都一样吧。

> spwaner 本身要可以等待或阻塞
没看懂，什么地方可以等待？你是指可以 await spwaner() 么？

@GeruzoniAnsasu

package main

import (
"fmt"
"math/rand"
"time"
)

func worker(ch chan int, x int) {
d := rand.Intn(10)
time.Sleep(time.Millisecond * 10 * time.Duration(d))
ch <- x
}
func main() {
var queue []chan int

for i := 0; i < 10; i++ {
ch := make(chan int)
go worker(ch, i)
queue = append(queue, ch)
}
for _, ch := range queue {
fmt.Println(<-ch)
}

}

thread-local 是指每个线程都有自己的变量。虽然代码里面是同一个变量，但每个线程用的是各自的变量。
所以每个线程里面用的是不同的 connection 。数据库连接和线程数一样多。


> 如果多线程不是同一个连接的话，跟不使用 ThreadLocal ，每个线程新建一个 connection 有什么区别呢

如果每个线程新建一个连接，用完就关下次再重连，那就没有区别。
如果要把连接留着以后再用，就需要一个地方存着这个 connection ，下次再用的时候每个线程每次都能拿到当前线程的 connection 。当然可以自己实现这一套东西，实现好了你就重写了 thread-local

@Lefi

我没有反驳你的观点，我只是指出来你发的链接不能支持你的观点。
这本书从来没有说 “的” 可以混用，只说了这个字的读音 “de” 有这些种不同的用法。

后面这个台湾小学试卷可以证明台湾不区分 “的” 和 “地”。

我最开始也不能容忍这些，比如 “那” 和“哪”这两个字有人经常用错，我就给指出来了，后来这人就在所有问句里都用 “哪”，我才发现他是真不知道该用哪个字。既然没这个能力，也就没理由不容忍了。
口语也是一样的，有一次有人问我“去了哪”，我想了半天告诉他我前几天去了哪，结果他实际想问的是“要去哪”。
需要理解这个事实，能正确使用汉语的人真不多。


在工作中我对这种事情的态度是，把对方写的字当对的理解。

“开枪” 就是“开枪”，直接照着做“开枪”就好。

“判断用户角色使用不用链接” 是说拿用户的角色来判断用不用链接，有的角色不用链接。所以直接回复对方让写清楚具体什么角色不用链接。

@Lefi
首先你发的这个链接《语法修辞讲话》里面，搜不到 “兼职过多，负担过重” 这几个字。

这个书有一章专门讲 “的”，在 51 页
我粘一段：

“的、底、地” 常常有人问起这三个字的分别。回答这个问题应该就口语和文字两方面
分开来说。口语里只有一个字,大多数地方说 de,有些地方说 di 。这个字担负的任务非常繁
重,所以在文字上写成两个或三个不同的形式是有相当的方便的,尤其是翻译外国文章的时
候。


所以原文说 “de” 是通用的，你在这里回帖说 “的” 是通用的。这完全不是一个意思。

@ecnelises
这个说的明显不对，嘛 就是 什么
吃嘛嘛香，吃什么什么香

干嘛 -> 干什么
干吗 -> 干不干

哪个接口吗

确实是病句


分别对应什么吗

这应该是个特殊的用法，同时问了两个问题。
1. 它们之间有没有对应关系?
2. 如果有，对应关系是什么?
说这句话的人是不是要表达这个意思，我当然就不知道了

@CRVV 日期写错了，是 2022.01.01 - 2022.12.05

@sublimeyue

> 截至 2022 年 12 月 2 日，全球已累计报告逾 6.43 亿例确诊病例，其中逾 663.7 万人死亡[9]，病死率约为 2.09%
世界各国对该病病死率的估计值差异甚大，多数国家该病的观测病死率在 0.5%-5.0%之间

你无意或有意地忽略了病毒有多个变种且多个变种的致死率不同这个事实，用全部的确诊病例数和全部的死亡数来算死亡率。这样显然高估了当前的实际死亡率。

> 那么做个大概估算, 如果现在向美国一样, 中国也 90%多的人都感染新冠, 那么会死多少人? 我觉得并不会少.
所以我有夸大吗? 我觉得没有.

你没说估计出来到底会死多少人，你连说都没说，当然没有夸大。
如果你想暗示中国的死亡数字会是 14 亿 * 0.5%-5.0% = 700 万 - 7000 万，那么你有夸大，理由前文已述。


我换一个更准确的方法来估算死亡率。
因为中国一直在积极的防控这一传染病，一直都防得不错，所以只有传染性大增的 O 变种真的对中国造成了实质性的影响。之前的所有变种对中国的影响，和其它国家相比几乎都可以忽略。
还有第二个原因，中国做核酸检测的次数非常多，应该说远比其它任何一个国家都多，这样能得到全世界最准确的病例数据。每一个确诊病例死亡病例肯定都做了核酸检测，而其它国家的就不一定了。
O 变种出现 2022 年，所以我们直接看 2022 年中国的数据。
2022.01.01 - 2022.12.15
总病例数是 1648293 ，总死亡数是 345 ，死亡率是 0.02%，或者说万分之二。远比你说的 0.5-5.0% 低。

1. 「公司付 X%，个人付 Y%」是以什么为基准计算的，扣完五险一金之后个人所得税又怎么计算？

比如谈的每月工资 10000 ，个人和公司的 x% 都用这个 10000 来算


2. 既有年终奖又有月基本工资的时候又该怎么算

年终奖不用交五险一金，税好像有不同的算法吧我不太确定。


3. 我看到个人所得税速算扣除数就觉得头晕，完全不知道怎么拿来算，而且现在个税制度一直在改革，好像每月的个税比例都不一样，就更难算了；

个人所得税的算法是这样的
五险一金部分不用交所得税，先减掉，比如月薪 50000 ，假设扣完五险一金还有 40000 。
每个月有 5000 的免税额，就是说这里面有 5000 不用交税，这样还剩 35000 。
然后有那些租房养娃什么的免税额，比如有 3 个娃 1 个老人，这样又有 5000 不用交税，这样还剩 30000 要交税的收入。
这样，每个月的 30000 ，叫做应纳税所得额。

一月，当年的应纳税所得额是 30000 ，税率 3%，交税 900
二月，当年的应纳税所得额是 60000 ，其中 36000 以下的部分是 6000 税率 3% 就是 180 ，36000 以上的部分是 24000 税率 10% 就是 2400 ，这个月要交税 180+2400=2580
三月，当年的应纳税所得额是 90000 ，这个月的收入都是 36000 以上的部分，税率 10% 交 3000 的税
四月，当年的应纳税所得额是 120000 ，这个月的收入都是 36000 以上的部分，税率 10% 交 3000 的税
五月，当年的应纳税所得额是 150000 ，这个月的收入在 144000 以下的部分是 24000 税率 10% 交 2400 的税，还有 6000 在 144000 以上税率 20% 交 1200 的税，这样一共交 3600 的税
后面都是这样算下去的。

这样算需要一个月一个月地累加，有人觉得麻烦，就搞了个速算扣除数。比如第二个月的总数是 60000 ，36000-144000 之间的速算扣除数是 2520 ，60000*10% - 2520 = 3480 就得到了总的税额，再减掉一月的 900 ，得到二月的税是 2580 。
如果要算一年的税额，直接 30000*12 = 360000 ，税率是 25%，36000*25% = 90000 ，再减掉速算扣除数 31920 ，得到全年的个人所得税是 58080 。这样比一个月一个月加上来要少按几下计算器，如果用 Excel 来算我觉得这东西完全没必要。

因为工资是按月发的就每个月都这么算，但如果在 10 月 31 日离职了，后面两个月没有工资，但免税的额度还在，全年的应纳税所得额就变成了 30000*10 - (5000+5000)*2 = 280000 ，但是在 10 月已经交了 300000 对应的税，这样第二年就可以申报把多交的 20000*20% = 4000 的税钱退回来。这个情况我的理解是这样，但我也没操作过，不保证正确。


4. 每个城市的算法还不太一样！

五险一金不一样，差别不会很大，税是一样的

@raysonlu

“不让 mysql 高负荷运行复杂查询”

这应该是一个对关系型数据库的误解，来自于 MySQL 的 planner 太弱。

要得到一个查询的结果，不论查询是不是分步的，总的工作量一定有下限。在 planner 足够好的情况下，一定是分步查询的工作量大，一条大 SQL 的工作量小（因为不需要把可能很大的中间结果传回来），所以写一条大 SQL 才是节约数据库的做法。

在 MySQL 上，“planner 足够好” 通常不成立，这事就反过来了，分步查才是工作小的做法，所以才有分开写简单 SQL 的习惯。换成 PostgreSQL 就不是那么回事了。

至于其它的很多都是需求问题，很多时候产品经理的需求就要分页要搜索，总不能直接说这东西做不了吧。

@raysonlu

如果能分步处理当然分步处理是很多人首选的方案，因为代码比较好懂，会写复杂 SQL 的人没那么多。

但就这个题来说，如果商品有 1 亿个，销量表是分小时的，要查所有商品，按近一个月的销量倒序排列，要能搜索能翻页，还是那种能直接跳到第 10000 页的设计。这样的不太可能分步来处理吧，每一个中间步骤的结果都很大。实际的需求通常都比这个复杂。

写一个大 SQL 可能直接就把数据库弄死了，当然也不行。
所以我上面说 BigQuery ，这东西就是干这个事用的，应该算是解决这种问题的方案之一。

@DinnyXu
这种 SQL 在很多地方都用得到，而且这个题其实不难。
如果每个表都有几亿行，用 BigQuery 写一句 SQL 就能实现，速度也不慢。如果不写 SQL 你打算怎么做？

首先把销量的类型改成数字， `sales_volume` INT

最后都需要套一层子查询来重新排序，就不写了。
这三种写法都是用 ORDER BY volume DESC LIMIT 3 来选出前 3 ，还可以用 rank <= 3 来选前 3 的，如果有重复的会得到不同结果
都可以在最新的 MySQL 上执行

SELECT goods.name,
goods_sales_record.sales_volume,
goods_group.name AS group_name,
t.group_volume
FROM goods
INNER JOIN goods_sales_record ON goods.id = goods_sales_record.goods_id
INNER JOIN goods_group ON goods.group_id = goods_group.id
INNER JOIN (SELECT goods_group.id, sum(goods_sales_record.sales_volume) AS group_volume
FROM goods_group
INNER JOIN goods ON goods.group_id = goods_group.id
INNER JOIN goods_sales_record on goods.id = goods_sales_record.goods_id
GROUP BY goods_group.id) AS t ON t.id = goods_group.id
ORDER BY 2 DESC limit 3;

SELECT goods.name,
goods_sales_record.sales_volume,
goods_group.name AS group_name,
t.group_volume
FROM goods
INNER JOIN goods_sales_record ON goods.id = goods_sales_record.goods_id
INNER JOIN goods_group ON goods.group_id = goods_group.id
CROSS JOIN LATERAL (SELECT sum(goods_sales_record.sales_volume) AS group_volume
FROM goods INNER JOIN goods_sales_record on goods.id = goods_sales_record.goods_id
WHERE group_id = goods_group.id) AS t
ORDER BY 2 DESC limit 3;

SELECT goods.name,
goods_sales_record.sales_volume,
goods_group.name AS group_name,
sum(sales_volume) OVER (PARTITION BY goods_group.id) AS group_volume
FROM goods
INNER JOIN goods_sales_record ON goods.id = goods_sales_record.goods_id
INNER JOIN goods_group ON goods.group_id = goods_group.id
ORDER BY 2 DESC
LIMIT 3;