getMessage()用于获取异常简短描述，适合用户提示和日志摘要；printStackTrace()输出完整调用栈，专用于开发期定位问题；二者应组合使用：先通过getMessage()快速识别问题类型，再借助printStackTrace()或日志中的完整堆栈精确定位根源。
Java 中的 getMessage() 和 printStackTrace() 是定位异常根源最基础也最关键的两个工具，但它们作用不同、适用场景不同，混用或误用反而会掩盖真实问题。
getMessage()：看“说什么”，适合用户提示和日志摘要
getMessage() 返回异常的简短描述信息，通常是构造异常时传入的字符串。它不包含堆栈路径，也不体现异常发生位置。
- 适合用于向用户展示友好提示（如“文件不存在，请检查路径”）
- 适合写入业务日志作为一行摘要（如
log.warn("上传失败: " + e.getMessage())） - 注意：很多底层异常（如
NullPointerException）默认getMessage()返回null或空字符串，直接打印可能什么也看不到 - 建议搭配
e.getClass().getSimpleName()使用，例如：e.getClass().getSimpleName() + ": " + Optional.ofNullable(e.getMessage()).orElse("no message")
printStackTrace()：看“从哪来”，专用于开发期快速定位
printStackTrace() 把完整的调用链（包括类名、方法名、行号）输出到标准错误流（System.err），是找“谁调了谁、在哪崩了”的第一手线索。
- 只应在本地调试或测试环境使用；生产环境禁止直接调用，避免污染控制台或日志格式混乱
- 若需记录到日志文件，改用
log.error("操作失败", e)（SLF4J / Log4j 等会自动捕获完整堆栈） - 遇到嵌套异常（如
SQLException包着IOException），printStackTrace()默认只显示最外层，可配合e.getCause()层层展开查看根本原因
组合使用：先摘要，再深挖
一个典型的排查流程是：日志里看到 getMessage() 提示（如 “连接超时”），再根据时间戳/请求ID找到对应完整堆栈，顺藤摸瓜定位到具体代码行。
- 不要只记
getMessage()就止步——相同提示可能来自不同模块（比如“解析失败”可能是 JSON 格式错，也可能是字段类型不匹配） - 不要只看
printStackTrace()最顶上一行——关键常在“Caused by”之后，那是真正的源头 - IDE 调试时，在 catch 块里右键选择 “Evaluate Expression”，输入
e.printStackTrace()可即时查看，比加日志更快
更进一步：用 getStackTrace() 做定制化分析
如果需要程序化处理堆栈（比如过滤掉框架无关行、提取特定类的调用位置），可用 e.getStackTrace() 获取 StackTraceElement[] 数组：
- 遍历数组，用
element.getClassName()和element.getLineNumber()定位业务代码行 - 跳过
java.*、sun.*、org.springframework.*等非业务包，聚焦自己的类 - 适合封装成通用异常诊断工具，比如自动标出最近一次你项目中类的调用点
