不要，小孩子可以放出去自己生存

@ayase252 你是在认真的吗？

一直用 net/http，感觉很爽

一直用白色背景， 深色背景网页一般选择直接关闭。ps：4.5mm 瞳孔，轻度散光

@cominghome 有的，就是用的 hash

@i0error 活动页面在哪里

@aliipay 忽略我的吧，楼上已经有比我更优的答案了

(\d+\S*[a-z])|([a-z]+\S*\d)\S*

@yezhiqiucn 怎么说？

BACKUP_COLUMN 如果能建索引的话，直接用悲观锁，两个事务同时执行时候有一个会触发 deadlock 退出事务，一个会成功写入， 避免其它逻辑导致死锁误判，可以在延时一小段时间后查询再决定是否重新写入数据库

@akira subquery 不支持 limit，可以改成 select id, user_id from xx join ( select id from xx limit 300000,50) yy on xx.id = yy.id

没看太明白，我猜问题原因是 offset 太大

可能是 aws 员工打入到 aliyun 了

@zarte
goroutine dead lock，
mutex dead lock
error type assert
map slice 等空指针
make slice len/cap out of range
integer divide by zero
integer overflow
invalid memory address or nil pointer dereference
channel：
make chan size out of rang
send on closed channel
close of nil channel
close of closed channel
等等
这些都是编译时候判断不出的

第一条就是本贴了

第一天就是本贴了

@frozenshadow
defer 问题确实是个烂坑，目前来看得出结果基本没啥问题， 原理是不太懂，因为不懂汇编。
推荐 advanced-go-programming 这本书，里面有讲到 defer 的问题

@mengzhuo
我对题目的理解是 golang 的 panic 而不是其它任何形式的 crash，后者范围很大，前者只和语言相关。（区分这可能有点转牛角尖，对实际工作用处不大）

函数里调函数本身 这个没能重现出"stack overflow"。go version 1.11.2 linux/amd64。
goroutine stack 是放用的进程 heap 里面，受系统内存影响，所以出现的是"out of memory" 。 这个也算 panic 的话，一直 make 也会出现。。。

@mengzhuo 确实可以海了去了，但是几点问题：
1.1 golang 你能制造出"segment fault、PC address invalid" 吗？ 除了调用其它语言和者使用 unsafe 模块
1.2 OOM 是操作系统行为，不是 panic
1.3 stack overflow 我个人认为也是操作系统触发的
1.4 据我所知没法直接调用 cpu 指令，除非嵌入汇编， 这种错误明显不算在 golang panic
1.5 操作系统的错误都不算，要的是 golang 的 panic


2.1 这个是个问题， 准确的说是并发读写要加锁。 因为以前是写 C++的，默认这个是基本操作，当时没答这点
2.2 嗯。。。
2.3 刚学的时候看到过，不过业务代码重来没有到过
2.4 SSA 确实不了解，不过线上同样没遇到过 delete 性能问题