荒野之息
王国之泪

反正我以后肯定给儿子安排（

64 位架构上不是 64 位更快么？

moonlander
有没有跟我一样的

键盘鼠标音箱都是 2.0 就可以了，分一个出来问题不大。

网络问题最好还是解决无线问题，信号不好挂个小 WiFi 路由器中继试试？不确定 USB 转这么多层（电脑-显示器-转接头-网口）还能有多少速度……

channel 里读 N 条出来直接处理掉，不要用切片缓存 /交互数据，就没这个问题了。

这个切片设计的根本没什么道理。

提示出来一眼看过去跟自己预想的是不是差不多。差不多的话就用它然后修修。
差的多或者看不懂的话就直接忽略。

差不多的意思不止包括代码功能差不多，代码结构差不多也行…反正帮助少敲键盘也是一种帮助。

为什么每天想早点下班的原因是老婆孩子热炕头。

什么公司，哪里的，能给多少

显然是不懂的人翻译的垃圾书……

这不是色盲悖论，这特么是语言悖论。

你生下来就知道绿色叫绿色？蓝色叫蓝色？

没变少啊……

@JavenXiao
听起来是个靠谱的办法。必须在 react 之外写。

@ZoeeoZ
抽不动，下面太多直接引用了，如果开始渲染时还没有准备好，页面就直接炸了。

本来找到个办法，在 react.render 之前 fetch 一下。
但是结果各种组件的 import 里就有很多直接执行的代码依赖……

最后的解决办法：
在最开始执行下 fetch ，然后放到 localstorage 里，然后刷新下页面。
如果一开始 localstorage 就有，那就不 fetch 。

@vace 谢谢你，现在有了一个新问题，怎么做 server rendering

@billccn 去翻翻 ICMP 协议吧

op 可以把收到的 ICMP 放出来看看，ICMP 报文的 data 是触发这个 ICMP 的原数据包的 IP header 部分。

这种设想不科学也不经济。
要判断 IP 是否 IDC 的，有更简单实用的办法。

ICMP type 4 source quench 根本没有 code 。

我怀疑你看反了，是
type 3：
Destination unreachable

code 4：
Fragmentation is needed and Don't Fragment was set

这是个正常的 ICMP 通告因为你的 MTU 太大了中间设备或者目的服务无法处理。

家宽 MTU 升级出现这个现象是有可能的。
但是服务提供方不可能根据这个做风控，这个都不一定是服务端发回来的，可能是任意一个中间设备。
而且客户端（家宽）收到这个报文也不会产生什么回复。
客户端实现了 PMTU 的话，会调小 MTU 重新建链尝试。

多看书。