@torbrowserbridge 你不说，他们怎么知道你有意见？什么都不做，等着他们施舍？

thz

京东自营的东西售后好点，主板、手环、鼠标都直接换新过，没要求包装

runtime.GOMAXPROCS(1)

这一行代码是没有任何意义的，goroutine 可能在任意地方发生调度，不是说你只用一个 P，你的程序就能保证什么。该上锁的还是得上锁，该同步的还是得同步。goroutine 不是协程，不要拿协程的性质来看待它。

不信的话，1.12 的调度器很可能教你做人…

@zzhbbdbbd 编译器的某种行为，如果语言规范没有说，那就是未定义行为，如果你的程序依赖这种行为才能正确工作，那以后编译器改动了，这种行为和之前的不一样了，那你的程序崩了就是你自己的责任，编译器没有责任。语言规范定义了的，编译器实现得不对，那就是编译器实现者的责任。一个例子是，之前并发读写 map 不做同步，是不会报错的，但是某个版本之后，运行时直接就会 panic。规范没有说 map 是线程安全的，那编译器就可以这么做，因为并发读写不做同步，是未定义行为。你在旧版编译器测试很多次都不出错，不代表以后编译器就不会让你的程序出错。goroutine 的执行顺序，就是未定义行为，讨论它是顺序还是倒序，是毫无意义的。

@zzhbbdbbd 不是说测试很多遍它就会一直这样，语言规范没有说必须是这个顺序，那编译器怎么实现都可以，因为都不违反规范。所以你要把它看作是随机的，不能依赖这种未确定的行为，不然很可能新版的编译器就会破坏你依赖的事实。有些项目不敢升级编译器版本，就是因为依赖了特定版本的编译器的行为，一升级就坏了。不是你自己测试很多遍你就能依赖它，编译器、操作系统、硬件等等不同，都有可能出现不同的结果。可以依赖的只有语言规范（ https://golang.org/ref/spec ），编译器实现者是一定会遵守的。

for 循环当作 dead code 优化掉了

不用细究这个问题，一来实际不会出现这种代码，二来 1.12 会修正这个 bug。

答案：
1：goroutine 调度是 M 自己主动跳过去的，死循环了自然跳不过去，就一直占用 P。1.12 会用信号让 M 强制跳到信号处理过程，所以死循环不影响。
2：goroutine 的执行顺序不确定，应该认为它是随机的，不是说写在前面就应该先执行，没有保证的，所以不要依赖这个顺序，想要确定的顺序，就用线程同步机制，chan 或者锁等。

@hadixlin 那个，电池不行了就给 cpu 降频这种操作，确实难以超越

10 寸还是小，想要 22 寸的，显示器又太重

有钱就补仓，没钱就装死，没必要猜，也猜不中

不放心就去超市买呗…… 物流也只能做到这个程度了啊

广告里插问答的 app

好好说话没那么难

chroot.

反正都是要倒闭的，随便