e.printstacktrace()输出首行为异常类型与消息，首个at行定位抛出点，caused by后首at行为根本原因；无行号因编译未加-g参数；应转字符串处理或用logger.error("msg", e)替代，禁用于生产环境。
直接用 e.printStackTrace() 能快速看到异常从哪来，但要真正靠它排查问题，得看懂输出、避开常见陷阱、并知道什么时候不该用。
看懂 printStackTrace 的三行关键信息
它的输出不是乱序堆砌，而是有明确结构：
- 第一行是异常类型 + 消息（比如
java.lang.NullPointerException），消息可能为空，别指望它说明白原因 - 第二行起是
at 类名.方法名(文件名:行号)—— 最上面那个 at 行，就是异常真正抛出的位置，也就是你要修的代码行 - 如果看到
Caused by:，说明这是被包装过的异常，真正根源在它下面第一个 at 行，而不是最顶上那一行
为什么有时只显示类名没行号？
这不是代码问题，是编译或打包时没保留调试信息：
- 编译 Java 文件时加
-g参数（javac -g MyClass.java） - Maven 项目检查
maven-compiler-plugin是否配置了<debug>true</debug> - IDE 里一般默认开启，但导出 jar 后出问题，要确认构建过程没 strip 掉行号表
怎么把堆栈转成字符串自己处理？
printStackTrace() 默认打到控制台，没法存、没法传、没法格式化。需要字符串就得手动捕获：
- 用
StringWriter和PrintWriter搭配：StringWriter sw = new StringWriter();<br> PrintWriter pw = new PrintWriter(sw);<br> e.printStackTrace(pw);<br> pw.close();<br> String stack = sw.toString();
- 别用
e.toString()或e.getMessage()替代——它们不含调用链，等于只说“病了”，不说哪疼 - 别漏掉
pw.close()，否则内容可能没刷出，字符串为空
哪些地方绝对不能写 printStackTrace()？
它不是日志语句，是调试快照，上线后会带来实际风险：
- Spring Boot Controller、Service 方法里 catch 之后直接
e.printStackTrace()—— 全局异常处理器可能已拦截，这行根本不会执行 - 生产环境部署后，
System.err常被重定向或丢弃，你本地能看到，线上就没了 - 多线程场景下，多个异常输出混在一起，分不清谁是谁的
- 正确做法：用
logger.error("业务动作失败", e)，第二个参数必须是 Throwable 实例，不是字符串拼接
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
