如何debug linux应用
当 Linux 应用启动后立即退出、运行一段时间后卡死，或者只是日志异常却没有明显报错时，应该如何快速区分是代码问题、环境问题还是资源问题？
从现象、日志和系统状态三方面切入排查
可以先观察崩溃时机、错误提示和系统资源使用情况。若应用立即退出，优先检查依赖库、配置文件和权限；若运行一段时间后卡死，重点看死锁、阻塞 I/O 和线程状态；若只是不稳定但没有明显报错，则结合日志、core dump、dmesg、top、ps、strace 等工具判断。把问题先归类，再针对性缩小范围，会比直接改代码更高效。
如果手头只有可执行文件，没有完整源码，也缺少调试符号，遇到 Linux 应用异常时还能用哪些办法找到线索？
可以借助系统级工具和运行时信息定位
即使没有源码，也能通过进程行为定位问题。可以使用 strace 观察系统调用是否卡在文件、网络或锁等待上；用 lsof 查看文件句柄和资源占用；用 gdb 附加进程查看线程栈；用 /proc 目录读取进程状态、内存映射和文件描述符；如果有 core dump，还可以结合 addr2line、objdump、readelf 做二进制层面的分析。虽然定位精度会受影响，但通常足以找到异常方向。
同一个 Linux 应用在某些机器上运行正常，在某些机器上却响应变慢、CPU 飙高或内存持续上涨，这种情况该如何区分是代码退化还是环境差异？
对比资源指标和环境差异，确认瓶颈来源
可以从 CPU、内存、磁盘、网络和系统负载五个方向分析。若 CPU 持续高占用，查看热点函数和线程调度；若内存不断上涨，检查泄漏和缓存策略；若磁盘或网络等待明显，关注 I/O 阻塞、连接超时和外部依赖。与此同时，对比内核版本、glibc 版本、容器限制、文件系统和机器规格等环境差异。很多性能问题并非代码本身，而是资源限制或部署环境变化引起的。
当应用偶发崩溃或现场难以复现时，怎样通过日志和 core dump 尽可能还原问题现场，减少反复试错？
让日志可关联、让 core dump 可分析
日志设计要尽量包含时间、线程、请求标识、关键参数和错误码，便于串联事件链路。出现崩溃后，确保系统允许生成 core dump，并记录当时的二进制版本、依赖版本和启动参数。拿到 core 文件后，可以用 gdb 查看崩溃点、线程栈、变量值和内存状态，再结合日志时间线还原出错路径。若日志与 core dump 能对应上，很多偶发问题也能被稳定定位。