Java不支持尾递归优化，根本原因是JVM字节码无尾调用指令、HotSpot未实现栈帧复用、javac不做尾递归分析，且受历史兼容性与设计定位制约。
Java 编译器（javac）不原生支持尾递归优化，根本原因不在语法或程序员写法，而在于 JVM 规范和运行时机制的底层限制——它压根没给“复用栈帧”留出技术路径。
JVM 字节码没有尾调用指令
尾递归优化的本质是：当识别到尾调用时，不执行常规的 invokestatic 入栈流程，而是直接更新当前栈帧里的参数，再跳转回方法开头（类似汇编里的 jmp 而非 call）。但 JVM 字节码规范中从未定义任何尾调用专用指令。所有方法调用指令（invokestatic、invokevirtual 等）都强制分配新栈帧。没有指令支撑，javac 就算识别出尾位置也无从下手。
HotSpot 未实现栈帧复用逻辑
即便字节码层面能绕过，JVM 运行时（如 HotSpot）也未内置栈帧复用机制。它默认为每次调用创建独立栈帧，保存局部变量、操作数栈、返回地址等完整上下文。尾递归本应丢弃当前帧、重用内存，但 HotSpot 没有提供清空+重载参数+跳转执行的运行时能力。调试信息、异常堆栈跟踪、安全管理器的栈检查也都依赖完整调用链，强行复用会破坏这些关键功能。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
javac 不做尾位置分析与转换
Scala、Kotlin 编译器会在编译期扫描 AST，识别尾递归结构，并主动将代码重写为 while 循环（例如把 factorial(n, acc) 转成 while (n > 1) { acc *= n; n--; }）。而 javac 完全不进行这类控制流分析，也不生成带跳转语义的字节码。你写的 return f(n-1, x*n) 在 javac 看来只是普通递归调用，最终输出的仍是标准的 invokestatic 指令。
历史兼容性与设计取舍
JVM 诞生早于现代函数式语言对 TCO 的强需求。加入 TCO 需要修改字节码规范、JVM 实现、调试器、安全模型等多个层级，代价远超收益。Oracle 与 OpenJDK 社区长期评估后认为：Java 的核心定位是面向对象与工程稳健性，而非纯函数式性能极致；用迭代替代递归在绝大多数场景下更清晰、可控、易调试。因此至今未纳入 JEP，连预览特性都未进入议程。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
