时间复杂度取决于各层循环的迭代次数表达式，而非嵌套层数；例如三层循环可能为O(n×m)，关键看每层是否依赖同一变量n。
嵌套循环层数不等于时间复杂度层数
Java 里写三层 for 循环，不代表就是 O(n³)。关键看每层的迭代范围是否都依赖同一个变量 n。比如外层遍历数组长度，中层固定跑 10 次，内层遍历另一个长度为 m 的列表——那实际是 O(n × m)，和层数无关。
常见错误现象：O(n²) 被当成“两层 for 就一定如此”，结果线上数据量一上来，接口超时却查不出原因。
- 判断依据永远是「每个循环的执行次数表达式」，不是缩进或大括号数量
- 如果某层是
for (int i = 0; i ，它贡献的是常数因子，不改变阶数 - 注意隐式循环：调用
list.contains()（底层是线性扫描）、stream().filter().findFirst()都可能悄悄引入额外 O(n) 层
如何快速估算嵌套循环的真实复杂度
别从代码结构出发，从输入规模和操作频次反推。拿一个典型例子：遍历二维数组 matrix 并对每个元素做一次加法。
for (int i = 0; i <p>这里外层是行数 R，内层平均列数 C，总操作数 ≈ R × C，即 O(R × C)。若矩阵是方阵（R == C == n），才退化为 O(n²)。</p>
- 把每个循环的上限单独拎出来，写成数学表达式，再相乘
- 遇到
while或递归嵌套，先等价转成 for 结构再分析 - 警惕 break/continue 提前退出：如果大概率在第一次就
break，均摊下来可能是 O(n)，不是最坏 O(n²)
编译器和 JIT 不会帮你优化嵌套复杂度
Java 编译器（javac）只做语法检查，JIT 编译器可能内联方法、消除空循环，但绝不会重写你的嵌套逻辑来降阶。O(n³) 就是 O(n³)，哪怕你写的只是个玩具 demo。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
使用场景中容易忽略的一点：本地测试用 100 条数据看不出问题，但生产环境用户上传的 Excel 有 5 万行 × 200 列，三层嵌套直接卡死。
- JIT 可能优化掉未使用的变量或重复计算，但不会合并循环、提取公共子表达式
-
-XX:+PrintCompilation可以看哪些方法被 JIT 了，但看不出复杂度变化 - 真正有效的优化是算法替换（比如用哈希表替代内层遍历），不是指望 JVM“聪明”
用 JMH 测嵌套性能比纸上谈兵靠谱
光看 Big O 容易误判。比如 O(n²) 的朴素字符串匹配，在短文本下可能比 O(n) 的 KMP 还快；而两层嵌套里做了大量对象创建，GC 压力可能比复杂度本身更早拖垮系统。
实操建议：用 JMH 写基准测试，控制变量测不同输入规模下的耗时增长趋势。
- 至少测 3 组输入：小（100）、中（1000）、大（10000），观察耗时是否接近平方增长
- 加上
@Fork(jvmArgsAppend = "-Xmx2g")避免 GC 干扰 - 别信单次
System.nanoTime()——JMH 能屏蔽预热、JIT 预热、统计抖动
嵌套层数只是代码形态，复杂度藏在数据规模和每层的实际迭代次数里。最容易被忽略的是：你以为的“内层循环只跑几次”，其实取决于用户输入，而那个输入根本不受你控制。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
