小米的用了 6 年没问题，就是滤芯成本高

git add -f 是可以强制添加被忽略的文件的

@LiFExxl 个人卖家在哪找呢？感觉闲鱼水更深。

@NewMoorj 再问一下转转上 99 新的靠谱么？感觉验机报告也挺全的

@NewMoorj 是这个吧，看了下评论里的照片，应该是官翻机 https://v2ex.com/t/1001114
主要是直接买二手，价格也很高，而且还没那么新；大佬你的 14 寸也都卖完了。

@icecream 百亿补贴也不保新啊

@K120 是买未激活未过保的

sync.Map 适合读多写少的，一旦要写就会重新复制整个 map ，开销挺大的。

真正的高并发写需要避免多个 CPU 核同时访问一个 cacheline 地址。最简单的方式是先对 key 进行 hash ，然后分成多个 map ，这样并发访问不同的 key 大概率不会同时对一个 map 加锁。

@chenchengbin 字符串是浅拷贝 StringHeader

之前看过这篇，性能上大部分情况下是返回 struct 更快：
https://cloud.tencent.com/developer/article/1861199

不过如果要和 nil 区分，或者最终要放到堆里，那就继续用指针。

然后如果是参数的话，记得是超过 32 字节传指针更快，而且每个字段是单独用一个 MOV 指令来复制的，不是一整块复制的。

@a132811 我的意思是反射可以获取到原函数的每个参数的类型，你可以保存下来，调用时检查参数是不是对应的类型。

但是 Go 不是很动态的语言，反射和泛型也没法结合使用，导致泛型实现的接口没法返回正确的类型（只能是 interface{}），因此没法实现 demo 的 fibCached(x-1) + fibCached(x-2)。不过 demo 里对 fib() 的实现也是有侵入的。

比较类似的例子你可以参考这篇，最后为了优化实现得有点复杂，看看原理就好：
https://keakon.uk/2023/03/24/%E6%8A%8A%E4%BB%BB%E5%8A%A1%E9%98%9F%E5%88%97delayed%E7%A7%BB%E6%A4%8D%E5%88%B0Go%E4%BA%86

@a132811 反射不会损失类型检查，可以动态获取参数类型并构造一个 struct ，但是做不到静态检查。实现自然是会复杂很多，但是对调用者而言是更简单的。不过既然你是做缓存，肯定是在意性能的，我就不推荐用反射了。

看上去不够优雅，但是如果要适配任意数目的参数和返回值，只能用反射来做。

@shaoyie @Nazz 当队列满的时候，Go() 会阻塞调用线程，而不是加到任务队列里立刻返回，后面空闲了再由 worker 线程去执行。

socket.SOCK_RAW 需要 root 权限，你加个 sudo 试试

没有优雅的实现。
其他语言可以给拿数据的连接设置 read timeout ，或者用子进程来处理。
但是 Go 把连接给封装了，大部分数据库的接口是同步的，你没法同时监听 fd 可读和定时器超时。
子进程要传数据需要用 pipe ，但是它的 Read()/Write() 是同步的，需要再起个协程去读写，才能和监听子进程退出和超时一起 select 。而且 Go 的 runtime 和第三方库可能都跑了一些子线程，fork 时并不会复制这些子线程，导致有时候会崩溃。

如果类型兼容，用 unsafe.Pointer 转，但是 []any 不行

a := []int{1, 2, 3}
b := *(*[]uint)(unsafe.Pointer(&a))
fmt.Println(b)
c := *(*[]float32)(unsafe.Pointer(&a))
fmt.Println(c)
d := *(*[]float64)(unsafe.Pointer(&a))
fmt.Println(d)
e := *(*[]any)(unsafe.Pointer(&a))
fmt.Println(e)

如果是做接口的话，不建议用 []any ，直接用 any ，然后做类型检查，文档中注明比较好。

InnoDB 的一页默认是 16KB ，其中有 100 多字节是头部等不用于存储数据的，这里先忽略。
索引页的每行要存储一个主键（假设是 int ，4 字节）和一个页号（ 4 字节），共计 8 字节。即一页最多存储 2K 条。
以一个 3 层的 B+ 树来计算，前两层是索引页，最多索引 2K * 2K = 4M 个节点。
假设表的每行占用的空间是 1KB ，那么一个数据页（叶子节点）最多存储 16 条数据，所有节点共可以存储 64M 条数据（ 64GB 大小）。
超过这个量时，要用 4 层的 B+ 树，那么 IO 次数就至少多出 1/3 ，索引也很难全放在内存中，肯定会大幅影响性能。

但是题目中提到的 500M 行和 2GB 并不是一个固定值，如果主键和每行占用的空间较小，就能存放更多的页。甚至你还能修改 innodb_page_size ，配置成更大的页，以在一页中存储更多行（但是可能造成 IO 的浪费，因为每次至少读一页）。

你自己加个锁不就行了吗？ sync.Map 单独实现出来是因为可以分片加锁，这样不同的 cpu 访问不同的分片时可以不用加锁，而其他数据结构没有这样的优化方法。

因为换安卓了