printStackTrace() 是还原异常发生时的完整调用链，输出到 System.err，提供精准位置信息；开发阶段可快速调试，生产环境须改用日志框架记录。
printStackTrace() 是干什么的？不是“打印错误”，而是“还原现场”
它不输出业务含义，只忠实地把 JVM 在异常发生那一刻记下的调用链完整吐出来——包括哪一行代码抛了什么异常、这个方法是谁调的、谁又调了它，一直追到 main 或线程启动点。这相当于给崩溃瞬间拍了一张“调用快照”，是定位根因最直接的线索。
- 它默认输出到
System.err（不是System.out），所以不会和正常日志混在一起，但控制台里可能被滚动刷走 - 返回值是
void，不能链式调用，也不能直接赋值给变量 - 如果类编译时没带调试信息（比如用了
-g:none），行号会显示为Unknown Source，排查难度陡增
什么时候该用 printStackTrace()，什么时候不该用？
它只适合开发阶段快速看一眼；上线后绝不能裸用，否则日志里全是堆栈，既难过滤又易泄露敏感路径或变量名。
- ✅ 本地调试时，在
catch块末尾加e.printStackTrace()，比打断点更快确认是否真进了异常分支 - ❌ 生产环境写法：
e.printStackTrace()必须替换成日志框架调用，例如log.error("DB query failed", e) - ⚠️ 注意：它本身不阻塞线程，但大量异常+频繁调用会显著拖慢吞吐，尤其在高并发循环里误用，可能引发性能抖动
三个重载版本的区别和实操选择
printStackTrace() 看似简单，其实有三个签名，选错会导致日志落空或文件权限失败。
-
printStackTrace()：输出到System.err，最常用，但不可控、难归档 -
printStackTrace(PrintStream s)：可写入文件，例如new PrintStream("app.log")，但要注意PrintStream不抛IOException，失败会静默丢弃 -
printStackTrace(PrintWriter s)：推荐用于自定义日志落地，因为PrintWriter支持检查checkError()，能感知写失败
示例（安全写文件）：
try (PrintWriter pw = new PrintWriter(new FileWriter("error.log", true))) {
e.printStackTrace(pw);
if (pw.checkError()) {
System.err.println("Failed to write stack trace to file");
}
}
和 getMessage()、toString() 混用时的常见陷阱
很多人以为 e.getMessage() 就够了，结果线上报 “null”，根本没法查——因为很多异常（如 NullPointerException）构造时不传消息，getMessage() 返回 null，而 printStackTrace() 依然能打出完整堆栈。
-
e.toString()=e.getClass().getName()+ ": " +e.getMessage()，比getMessage()多个类型前缀，但依然可能为null -
e.printStackTrace()是唯一能稳定提供「位置信息」的方法，哪怕getMessage()是空的 - 别在日志里拼接使用：
log.info(e.toString() + "\n" + e.printStackTrace())—— 这语法错误，printStackTrace()不返回字符串
真实项目里最容易被忽略的一点：异常堆栈不是“越长越好”，而是“从哪开始读”。JVM 记录的堆栈是从内向外展开的，第一行才是真凶，后面全是帮凶。盯错行，就等于查错人。
