最明显的一个原因就是上游的生产能力并不固定，当下游的消费能力不够需要扩容到扩容完成期间需要一个缓冲，消息队列正好提供了这个缓冲区。

@happyeveryday 有的，比如在下是 99 元的融合套餐，流量 10G/月，一言不合就超了

Go 里的闭包函数在内存里是 code+data 形式表现的。

以你 Set 函数返回的 f 为例，在编译期就可以分析出它应该包含内部匿名函数的入口点地址和 i 的值,
在 x64 上就是 16 字节空间，也就是 main 栈上的 f 指向一个 16 字节的空间，执行 f=Set(100)的赋值后
第二个 8 字节就赋值为 100 。

执行 f(&ss)时参照 https://golang.org/s/go11func，在 x86_64 下 R0 用的是 DX 寄存器。

MOV …, R0

MOV 0(R0), R1 //R0+0=>R1,即函数入口地址

CALL R1 # called code can access “data” using R0，比如例子里的 100 就是 8(R0)

用户态内存复制到内核缓冲区吧，另外 ram 的存取不命中 cache 的话本来也不快，大概要六七十纳秒起步。

标准库默认的是链接$GOROOT/pkg/$GOOS_$GOARCH 下的目标文件，
比如"import go/ast“的话会链接 /usr/local/go/pkg/linux_amd64/go/ast.a，
目前没看到链接器有提供选项可以改这个。按我的愚见有两种思路：
1. git clone 指定版本的 go 源码到 GOPATH/pkg/mod/github.com/golang 下
比如 git clone --branch go1.13.1 https://github.com/golang/go %GOPATH%/pkg/mod/github.com/golang
这样可以 import "github.com/golang/go/src/go/ast"来使用
2. 在当前项目下用 vendor 管理一个标准库的副本

go env -w GOPROXY=https://goproxy.cn

6 年 ip6，83%

linux 内核文档写的很清楚,RCX 和 R11 会在 x86_64 系统调用时被内核使用。

--------------------------------------arch/x86/entry.S-------------------------------------
* 64-bit SYSCALL saves rip to rcx, clears rflags.RF, then saves rflags to r11,
* then loads new ss, cs, and rip from previously programmed MSRs.
* rflags gets masked by a value from another MSR (so CLD and CLAC
* are not needed). SYSCALL does not save anything on the stack
* and does not change rsp.
*
* Registers on entry:
* rax system call number
* rcx return address
* r11 saved rflags (note: r11 is callee-clobbered register in C ABI)
* rdi arg0
* rsi arg1
* rdx arg2
* r10 arg3 (needs to be moved to rcx to conform to C ABI)
* r8 arg4
* r9 arg5
* (note: r12-r15, rbp, rbx are callee-preserved in C ABI)
------------------------------------------------------------------------------------------------

在你不知道他是怎样进来之前不要轻易动手 /doge

问道于盲

你这是刚跳过去的吗哈哈，之前脉脉上就爆出过这家管理混乱无能。离职证明上写无关信息也说明人事部门也是一群没常识的 five，大胆点去仲裁，同时可以在多个平台曝光给以压力。

run 函数被内联了，可以在编译时加入-gcflags "-l"禁止内联。

➜ /tmp go build -gcflags "-m" panic.go
# command-line-arguments
./panic.go:10:6: can inline run
./panic.go:5:6: can inline main
./panic.go:7:5: inlining call to run
./panic.go:7:5: main ... argument does not escape
./panic.go:7:5: a escapes to heap
./panic.go:10:10: leaking param: a
./panic.go:11:13: run ... argument does not escape
./panic.go:11:13: a escapes to heap

之前尝试过并未出现这样的情况，可以 eventvwr 打开 windows 事件日志找出哪个进程导致的蓝屏

@lsk569937453 用 http 的途径去 git clone，你图中走的是 ssh

@lsk569937453 go get 应该是对 git 的封装，看看 git clone 能不能正常工作

golang 的编译大概分为三步，
#1.进行词法分析和语法分析，构建出语法树 AST
#2.进行类型检测 typecheck 和 AST 优化(var x = 10/4.0 就在这步计算出来)
#3.进行静态单赋值 SSA 优化(ten/4.0 在这步计算得出)和中间代码生成

解析 10/4.0 时，经过一系列 switch case 后会调用[evconst]( https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/const.go#L569)计算出 10/4.0 写到 x 节点上，而 evaconst 会先调用[match 函数]( https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/const.go#L686)
来将两个变量转化为同样类型，这个函数逻辑对应着#7 所记录的 spec 规范。

而碰到 print(ten/4.0)时由于左边为变量已经推导出为 int 型所以会被[defaultlit2 函数]( https://github.com/golang/go/blob/master/src/cmd/compile/internal/gc/const.go#L1126)获取并且按左节点优先原则将右边的 4.0 转化为左边的类型。

可以从 GOSSAFUNC=main go build x.go 获得的 html 里看到 main 函数从 source->AST->SSA 的转换过程。

韭零后阿噗阿噗