差点以为自己学错了
长连接是指 TCP 连接的复用，http 1.1 提出来的，通过请求头 Connection: keep-alive 控制

接收方是记住了发送方的 域名+端口，所以一次三次握手以后后面都可以继续通信了

刚上手第一阶段建议用 go 写写设计模式，这一阶段熟悉 go 的语法

看别人的源码其实很枯燥的，我个人也不太能看的下去，我是确定了一个小目标，要做一个什么东西，再设计架构图，最后再实现代码。这中间可能很很多不会的，刚好也能自己学习。直接看别人源码 copy 效果真不一定好

挺好

小米用 NFC 刷地铁公交，并且小米钱包能在余额低的时候自动充钱，再也没担心过坐地铁卡上没钱的尴尬了

go 一个协程占用的空间 4kb 并且可以动态扩容。创建一个线程的开销远大于一个协程。协程之间切换不用切换内核空间和用户空间，线程需要。

当然最方便的还是 go func 就能开启新的协程。比 java 高到不知道哪里去了

其实是根本找不到需要手动传输 node_modules 的必要性，不太确定什么场景下是你只传输 package.json，然后在服务器端 npm install 不能解决的。即使像我一样觉得每次不同项目都要拉新的 node_modules，也可以使用 yarn 来安装

你这样备份 node_modules 本身也不合理，因为有些 node 包会是基于当前的系统环境生成的，比如 node-sass 这些，你同步过去以后也不一定能用

服务端的接口统一挂到路由 /api 下面

gin 开启一个静态服务地址，把除了 /api 接口的请求都重定向到这里，静态服务里面就放 vue 打包后的产物。以后前端更新就跑脚本直接替换就行了。
这样做的好处就是没有跨域问题了

按照我对电脑散热风扇里 DC 和 PWM 的理解，DC 不能调到 0，PWM 可以到 0

@lewis89

> Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

我觉得你说的场景都是很高大上，现实中我的服务器程序都是本地 用 windows 编译成 linux 包，然后发布到 linux 服务器上运行。为什么不搞 docker 服务器端构建。懒、麻烦，很多用户也应该是这样用 go 写一些玩具。这种情况下交叉编译很香

go 的目标本来就不是嵌入式，定位就是服务器端开发语言。服务器上的交叉编译 windows mac linux 做的还是很好的。

语法个人觉得挺好的，规则定的很死，也不会出现 1000 个开发 1000 个规范了

go 的开发效率还是很高的，和脚本语言有一拼了

我能用一句话让论坛吵起来

这个看起来就靠谱，比之前的一个杭州 7-12K 就要招大佬的靠谱多了

因为你不能保证你的系统全是 nodejs 服务，实际的情况是生产中 nodejs 只是很小一部分，大部分还是 java 做服务层

然后还需要考虑量级的场景，虽然是异步，但是 qps 一上去，一样能把 nodejs 服务器打垮。这个时候就需要 消息队列来承担这种量级的请求

都是业务优先，MDN 这种明显没产出的，坚持到这么久已经算奇迹了，火狐还是不错的

阿里巴巴前端 job model
已经有一套完整的体系了，不过大部分是和业务能力有关，技术的影响并不像大家想的那么重要

@janxin 交给社区的一般都是自己没有经历维护了的

```typescritp
declaer interface Window {
jsonpcallback: () => data
}
```

vuepress dumi 可以用现成的方案

@looking0truth 低峰期发布更新。前端基本是静态资源推送，发布的机器数没有想的那么多，所以很快就会发布完了。如果非要纠结发布很慢要很长时间，也可以通过灰度控制。