JavaScript 时间复杂度衡量执行时间随输入规模的增长趋势，核心是识别最频繁操作并用大O记号表示；单层循环通常O(n)，双重嵌套常O(n²)，但双指针等优化结构仍可保持O(n)。
JavaScript 中的时间复杂度，和其它编程语言一样，是衡量算法执行时间随输入规模增长而变化的趋势，它不关心具体耗时多少毫秒，而是看“当数据量变大时，运行时间大致按什么规律增长”。分析它，核心是找出代码中最频繁执行的那部分操作（尤其是循环、递归、嵌套结构），并用大 O 记号（O(n)、O(n²)、O(log n) 等）简洁表达其增长阶数。
怎么看循环结构——最常见也最容易误判
单层 for 或 while 循环，如果遍历整个数组或执行 n 次，通常是 O(n)；两层嵌套且都依赖 n（比如冒泡排序的双重 for），就是 O(n²)；但要注意“看似嵌套实则线性”的情况：比如外层遍历数组，内层用 while 跳过已处理元素（如双指针滑动窗口），整体仍可能是 O(n)，因为每个元素最多被访问常数次。
- for (let i = 0; i
- for (let i = 0; i
- while (left
递归怎么算——重点看调用次数和子问题大小
递归的时间复杂度由“递归调用次数 × 每次调用的计算量”决定。例如斐波那契朴素递归 f(n) = f(n−1) + f(n−2)，每次调用产生两个新调用，形成指数级调用树，时间复杂度是 O(2ⁿ)；而二分查找每次把问题规模减半，递归深度 log₂n，每层只做常数工作，所以是 O(log n)。
- 线性递归（如求阶乘）：O(n)
- 分治递归（如归并排序）：O(n log n)，因每层 O(n)，共 O(log n) 层
- 未剪枝的暴力递归（如全排列）：O(n!)
内置方法别盲目信任——查文档或源码逻辑更可靠
JS 数组方法如 sort() 在 V8 引擎中用的是 TimSort，平均/最坏都是 O(n log n)；includes()、indexOf() 是线性扫描，O(n)；但 Set.prototype.has() 基于哈希表，平均 O(1)，比数组查找快得多。不能只看写法简洁，得看底层是否真高效。
立即学习“Java免费学习笔记（深入）”；
- 用 Set 替代数组去重 + 查找，可从 O(n) 降到 O(1) 平均
- arr.filter(...).map(...) 是两次遍历 → O(2n) = O(n)，但实际开销翻倍，优化时可合并为一次遍历
- JSON.stringify(obj) 的时间复杂度取决于 obj 的属性总数和嵌套深度，近似 O(m)，m 是序列化后字符数
实际分析小技巧——抓主干、舍常数、看最坏
分析时先忽略低阶项和常数系数（O(3n² + 5n + 7) 就写 O(n²)）；关注最差情况（比如数组末尾才找到目标，就按 O(n) 算）；多个独立语句取最大复杂度（O(n) + O(n²) + O(1) → O(n²)）。调试时可用 console.time() 粗略验证趋势：输入 100、1000、10000 数据，看耗时是否接近线性/平方增长。
- 变量声明、四则运算、访问对象属性 → 都算 O(1)
- 嵌套 if 判断不影响复杂度，除非内部含循环或递归
- 避免在 for 循环里重复计算不变表达式，如把 arr.length 提到循环外
基本上就这些。时间复杂度不是背公式，而是养成“看到一段代码，下意识问：这段最慢会跑多少次？”的习惯。写得快不如想得清，尤其在处理大量数据或高频调用场景时，一两个数量级的差异，真的会卡住整个交互。
