作者：奔跑的企鹅
链接：https://www.zhihu.com/question/61826619/answer/207115235
只说linux 下C++相关的
程序异常一定是有原因的，只要肯挖掘，一定能找到原因。
不要怀疑编译器或操作系统有bug。评论区这一点争论较多，其实我的意思是：相对于久经考验的操作系统和编译器，bug 出在我们自己程序上的可能性占99.999%以上，这里的操作系统和编译器指linux 和gcc，其他平台我是小白，不敢妄言。
定位。有core文件最方便，没有core 文件用二分注释法、cout 大法和log 大法
如果每次core 在不同的地方，可能是写内存越界了。
程序莫名的挂了，没发现任何异常，看/var/log/message 是不是有内存泄漏或同一机器的其他服务有内存泄漏被操作系统oom kill 了。
程序没错啊。那就看是不是达到了系统限制，比如是否定义了一个大数组把栈空间耗尽了，或者打开文件数量超过了系统限制。ulimit -a
用pstack 查死锁。
gdb 是神器，编译时加 -g -O2 会很有帮助。
最开始进行开发时就要在关键的位置加log，不需要每次请求都打log，抽样即可。这样有利于恢复现场。凡事预则立。
硬件也会出故障的，本人曾遇到过硬盘偶尔无法写入，cpu 执行某条指令异常。/var/log/message 和dmesg 命令会很有帮助
stackoverflow 是个好网站，大部分问题都能找到答案。
网络问题先 ping 再netstat，高手可以用tcpdump 或其他牛叉命令。
奇葩问题比如两个头文件中有同名类，曾花费了我一整天的时间（按码农平均一天工作14个小时来算）查bug，自己挖的坑跪着也要填上。这时 gdb 和gcc -E 能帮上忙。
加深对工具的了解，你会用多少工具决定了你能花多少时间查出bug。这些工具包括 GCC 工具集，gdb，各种网络命令和linux 奇葩命令。linux 的命令比你我所了解的要多的多。
补充一条最重要的：做记录，做记录，做记录。我有一个文档叫 “xx BUG 录.md”，里面记录了各种之前遇到的bug、解决方法、总结收获等。随着记录的方法越来越多，遇到新bug无从入手时，查一下这个文档，经常能发现解决办法，屡试不爽。
论历史经验的重要性，做记录能让bug 快速成为收获。不止bug，技术积累同样可以通过多做记录多写文章完成，保证遇到相同问题时能快速解决。不在同一个地方跪倒两次，码农的时间还是很宝贵的。我发现硬盘已经在很大程度上替代了我的脑子，好记性不如烂笔头嘛，毕竟，硬盘除了存种子和片，还是可以拿出千分之一的空间存技术资料的。