V8中字符串扁平化是隐式转换，非显式操作；由多次拼接（如s += s循环）生成的字符串初始多为ConsString，访问charCodeAt、[0]等会触发扁平化为SeqString。
字符串在 V8 中是否已完成扁平化，不能靠肉眼判断，而需结合其内部表示形态、触发条件与可观测行为来识别。核心在于：扁平化不是显式调用的操作，而是 V8 在特定访问场景下自动执行的“隐式转换”，目的是将多层拼接结构（ConsString）降为连续内存块（SeqString），以加速后续读取。
看字符串构造方式：是否由多次拼接生成
若字符串来自指数级拼接（如 s += s 循环），极大概率初始为 ConsString（即非扁平）。这类字符串在内存中是树状结构，不占用连续空间，但 charCodeAt、[0]、Number() 等操作会触发扁平化。
- 典型构造：
function makeExpoStr() { let s = "a"; for (let i = 0; i - 此时
makeExpoStr()返回值尚未扁平，s.length可读，但随机字符访问代价高
用运行时工具检测：%HasCachedArrayIndex 与 %FlattenString
V8 提供调试指令（需启用 --allow-natives-syntax）辅助识别：
-
%HasCachedArrayIndex(str)：返回true表示已缓存索引信息，通常是扁平化后的表现之一 -
%FlattenString(str)：强制执行扁平化（仅限调试环境），之后再查%HasCachedArrayIndex通常变为true - 注意：这些指令不可用于生产环境，仅用于验证逻辑或性能调优阶段
观察性能变化：同一字符串重复访问前后的差异
扁平化是一次性开销，后续访问显著变快。可通过微基准对比识别：
- 对一个大拼接字符串，首次执行
str.charCodeAt(0)耗时明显高于第二次 - 执行
Number(str)后，再做str[5000]访问，速度提升可达 2–3 倍（实测案例中达 2.8×） - 该延迟下降现象，就是扁平化完成的间接证据
借助内存快照或 --trace-gc 辅助推断
在 Node.js 启动时添加 --trace-gc --trace-gc-verbose，配合字符串大量生成与访问，可观察 GC 日志中是否出现与字符串拷贝相关的内存分配峰值——ConsString 扁平化会触发一次 SeqString 的堆内存分配，表现为短时小对象激增。
- 扁平化过程本质是「复制内容到新连续缓冲区」，会产生一次 HeapNumber 或 SeqString 类型的新对象分配
- 若某次字符访问后紧跟着 GC 日志中的
Scavenge小分配高峰，且无其他明显触发点，很可能就是扁平化所致
