printStackTrace()危害严重：掩盖问题、丢失上下文、拖垮系统；导致日志错乱、定位困难、监控失效；纵容故障蔓延、引发雪崩；存在性能与安全风险；违背异常处理原则，放弃补救机会。
因为这既掩盖了问题，又丢掉了上下文，还可能拖垮系统——不是小题大做，而是真实风险。
日志完全不可用，排查直接抓瞎
printStackTrace() 默认输出到 System.err，和业务日志不在同一管道，导致：
- 异常堆栈和正常日志时间错乱、顺序混杂，查问题时得手动翻几十页日志对时间戳
- 没有时间戳、线程名、类名、方法名等关键上下文，连“谁在什么时候哪一行出的问题”都定位不了
- 日志系统（如ELK、SLS）根本收不到这条记录，监控告警全失效
掩盖业务逻辑缺陷，让故障静默蔓延
只打堆栈不处理，等于告诉程序：“出了错，但咱假装没看见”。后果很实际：
- 用户看到空白页、按钮无响应、数据没保存——但后台没报警，没人知道已出问题
- 下游服务因上游未返回结果而超时，引发雪崩式连锁失败
- 同一个异常反复发生，却因无明确错误码/状态反馈，无法触发重试、降级或熔断
存在性能与安全双重隐患
printStackTrace() 看似简单，实则暗藏雷区：
- 大量异常频繁调用时，会生成巨量字符串，挤占字符串常量池内存，严重时导致 Full GC 甚至请求卡死
- 堆栈里常含敏感路径、数据库连接串片段、参数值，直接输出到控制台或文件，极易被攻击者利用
- 没有日志级别控制（比如该记 ERROR 却打了 INFO），干扰运维判断，掩盖真正高危问题
违背分层处理原则，放弃修复机会
catch 的本质不是“终结异常”，而是“介入时机”。只 print 不处理，等于主动放弃所有补救可能：
- IO 失败时本可切换备用文件源；数据库超时本可走缓存兜底；网络异常本可自动重试
- 用户侧本可弹友好提示：“正在重试，请稍候”，而不是突然中断流程
- 系统侧本可记录指标、触发告警、标记异常订单——这些动作全因一句 printStackTrace() 被跳过
