@dafsic 我看你这个“普遍写法”是要爆大锅，你以为是 0，实际输入如果超出 64 位整数能表示的范围，那它返回的是最大可以表示的整数，如果这个返回值用在循环里，你的程序就要跑很久很久了。所以错误最好不要忽略，也不要认为返回错误时，其他返回值就是零值。很简单的例子，io.Reader.Read，返回 io.EOF 时，另一个返回值也可能非零。

@dafsic 错，你看看 strconv.ParseInt 的文档就知道了。或者跑下这个程序，看看返回是不是 0 ？ https://play.golang.org/p/0dLcyPJFt32

raid5 差不多等于无 raid，就是恢复时非常可能受到连击

但是用 + 有个很大问题是，你可能会忘记 + 前面的内容，这样你想找回密码时，可能都想不起地址去填。另外有些古董系统是不让你填 + 的。

用 icbc+myname@protonmail, nmb+myname@protonmail 就可以了啊

https://protonmail.com/support/knowledge-base/addresses-and-aliases/

这个特性最早是 gmail 实现的，后来很多服务商都学去了，+ 和它前面的都会忽略，都发到同一个地址，但你可以根据 + 附加的内容来做过滤或者区分是哪里用到的

对于每个分数，统计该分数线以上的人数，然后找出第一个人数等于或者超过 10 的分数线，再根据分数线筛选即可

精要是统计“分数线以上”的人数，而不是单一分数的人数

with
-- 所有分数
all_grades as (
select distinct grade from grades
)
-- 每个分数及以上的人数
, nums as (
select grade, (select count(*) from grades g2 where g2.grade >= grade) as num
from all_grades
)
-- 第一个人数等于或者超过 10 的分数线
, i as (
select * from nums
where num >= 10
order by grade desc
limit 1
)
-- 分数线以上的所有人
select * from grades
where grade >= (select grade from i)

@vone 问题他不是想要 rank 少于 10，而是 count(*) 等于或者刚好超过 10 。应该要用递归 CTE 来做

要对 ip 做查询做索引时你就知错

应该另外建表，存成多行

sync.Map 就是为这种场景定制的


The Map type is specialized. Most code should use a plain Go map instead,
with separate locking or coordination, for better type safety and to make it
easier to maintain other invariants along with the map content.

The Map type is optimized for two common use cases: (1) when the entry for a
given key is only ever written once but read many times, as in caches that
only grow, or (2) when multiple goroutines read, write, and overwrite
entries for disjoint sets of keys. In these two cases, use of a Map may
significantly reduce lock contention compared to a Go map paired with a
separate Mutex or RWMutex.

不靠谱，你继续打工可能还能做到三四十岁，成本一万赚十几二十万的生意，极有可能一两年就消失，这么高回报的路子，一定会吸引很多人进去，你们的红利就没了。
并不是做网店不行，什么时候都有做生意赚钱的人，但按照你朋友这个说法，这不是门好生意，做不长久的。