golang 里对 channel 的 range 要等到该 channel 被关闭才会终止。
考虑到 channel 的收发特性一般由 sender 端关闭。

而且我看了下 main 函数里 fileChan 容量只有 5，在工资表 xlsx 文件多于 5 个时
下面的 fileChan <- filePathName 操作像是会一直阻塞。

而且昨天开始 100%被墙阻断 https，最近 v2 也没干什么大事，难道传说中的白名单模式快来了→_→

strace -t ./prog

我搜了下 title 的 tooltip 延迟好像是浏览器设定并且还不能更改。
https://stackoverflow.com/questions/9150796/change-how-fast-title-attributes-tooltip-appears

在我的 Chrome 86 这里要 1 秒左右延迟，感觉可以接受。如果要自定义 tooltip 的话得引入第三方组件
或者用 JS+CSS 实现一个简单的 tooltip(比如官方的 hover::after 示例)。
https://developer.mozilla.org/en-US/docs/Web/CSS/::after

@Livid 站长辛苦了。另外帖子里只举例了主题的确切时间显示，我在 append 里加上了关于同样显示回复时间的建议，站长有空可以参考下，谢谢。

干的漂亮

可以参考 下 golang 的协程上下文：
struct runtime.gobuf {
uintptr sp;
uintptr pc;
runtime.guintptr g;
void *ctxt; // 闭包函数首地址,x86_64 下存在 DX 寄存器
runtime/internal/sys.Uintreg ret; // 系统调用返回值
uintptr lr; // ARM 下的 link register
uintptr bp;
}
以 X64 为例，切换上下文的时候大概这样执行：
MOV gobuf_sp RSP;
MOV gobuf_bp RBP;
MOV gobuf_ctxt RDX;
MOV gobuf_ret RAX;
MOV gobuf_pc RBX;
JMP *RBX;

谷歌搜索下 online code collaboration 的第一个答案 codeshare 看着还不错

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

@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