@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 性能问题

@netnr 有相同的日期也不一定和是最大

每日计算前一天加和最大值的定时任务
---------------------
是所有 ab 用户组合都事先算好？

个人认为，乐观锁适用于写少读多且写冲突后代价比较小的地方

@AddictX 自己 post 数据，服务器没校验结果

可以用 redis client 或者 telnet 连接看是否要很久

这个和视频处理什么关系？ 你这就读写文件，比较下两个文件是否一致就好了。
很有可能是没有 close 文件导致没完全写入磁盘。