或许可以参考现实现实世界的例子：

人类所说的语言和写的文字本身也是一种沟通用的工具，但为什么会有这么多的语言和文字呢？

实际遇到的问题是甲方所有人都读阀值，在偌大一个会议室里开会，只有你一个人读阈值的时候，真的会有些怀疑人生

@curiousjude 看到你最后的一段换，感觉有挺多想说的，但表述出来后又觉得多余。愿你能找到心中的力量，站起来，走下去。

@curiousjude 希望真的不要有太多的后悔。我丈母娘的父亲也是癌症走的，她现在有时会和我们说，或许当时不做那么多的治疗，这样她的父亲就不会承受那么多的痛苦，最后甚至连最好的止疼药都没有用了。癌症到了晚期，以现在医疗水平几乎是没法治愈的。你采取一切措施也无法真的拯救生命，反而可能会延长甚至增加对方的痛苦。真的不要太为难自己。

"作为癌症病人的家属，怎么选择都是错的"，这句话深有感触。有时候最害怕的不是亲人的去世，而是看着对方承受着非人的痛苦。

希望这一年经历能像一场烈火，烧尽污秽，留下纯净的存在。

@dxgfalcongbit 你可以这么理解，把时间线想成一个已经消失的东西：录像带。你可以正着录，反着看。也可以反着录，正着看。你可以说记录的时候是有顺序的，比如先正着录十分钟，然后反着录五分钟，再正着录五分钟。但是对于时间线（最终的录影带）来说，只留下了最终的影像，并保留不了录影顺序这种信息，所以以最终结果来看所谓的先后是没有意义的。
如果想保留这个信息，这需要时间维存在两维的情况下，也就是我们生活在四维时空里，才能实现的事情。

在 PC 上是这样的，但在移动端又是另外一个故事了。如果把苹果的 Mac 当作是移动端的延申产品，似乎就符合逻辑了。

正向和逆向是互为因果，不是一方对一方的模仿。就像镜子里的人像能精准模仿你的动作一样，只不过在时间维度，镜子里的像和你是互相影响的。大家在一个时间线里，动作一摸一样才是正常的，如果不一样就是平行宇宙了。

微信确实让人讨厌，不过这个撤回时间限制感觉没问题。我记得钉钉是可以随时撤回的，遇到过一次有人把老早以前的消息撤回，导致死无对证，这是更麻烦的情况。

这种想法很没有道德，也很危险

看身边的例子，会慢慢就不联系了。。。。不在一起生活，共同话题少，也就没什么好聊的，慢慢就疏远了

@b00tyhunt3r

在使用线程实现并发的语言里，像你问题里提到按照内核设置线程数，目的是期望每个线程都跑在一个独立内核上，减少不停进行上下文切换导致的额外开销。而 goroutine 是 go 的 runtime 自己调度的，并且比线程轻量级，带来两个好处：调度开销小和默认内存小。所以 goroutine 不再有之前线程出于性能考虑而带来的数量限制，所以理论上只要内存和 cpu 够强，开多少都行。

总的来说，启动线程考虑数量和内核的关系，是因为可能存在的性能问题带来的限制。而 goroutine 去掉了这个限制。你的问题像是一个之前被约束的人，有了自由后突然之间无所适从了。

如果你开始用 go 了，可以尝试习惯从业务和系统的总体计算力里来考虑并发数量，不用再把数量带来的上下文交换带来的消耗和内存占用放在考虑范围内了。

go 简单但是有些时候开发起来烦，但我还挺喜欢的。我不喜欢 java 生态里，很多包封装连亲妈都不认识了。比如你引入 readis 的 client，你看 redis 的官网文档是没有什么用处，你的看 client 的文档才会用。永远都蒙着一层纱的感觉，换个 client 可能一切都要重来。

Goroutine 会被分配到若干的线程里运行，线程的数量和运行的核心都是不能控制的。上面的代码确实是没有意义的，Goroutine 是很轻量级的，运行成千上万个都是可以的，没有必要和内核数量关联起来。

有两个小建议：
1. 可不可以提供浏览或者随机查看的功能，不然想看效果都不知道搜什么，可能关心的库大概率不在
2. 现在图片太小看不清，最好能提供查看大图的功能

@zmqiang 第一点搞错了，仔细看是面向所有人的高画质无限存储，不是面向 pixel 的原始图片的无限存储。看了下手机上的 google 相册，100G 两刀一个月，比起苹果也差不多多少的