不能靠 performance.mark() 直接量化 localstorage 对 tti 的影响，因为 mark 仅记录 js 执行时间点，无法反映同步 i/o 导致的主线程冻结；大数据量下 getitem + json.parse 可造成 30–100ms 主线程阻塞，使页面无法响应、paint 或执行 idle 任务，从而推迟 tti，但 mark 区间会掩盖这一真实影响。
不能靠 performance.mark() 直接量化 localStorage 对 TTI 的影响，因为 mark 只是打点，不反映主线程阻塞；真正拖慢 TTI 的是 同步读取+JSON.parse 大数据时的主线程卡顿，必须结合长任务检测与交互验证才能定位。
为什么 mark('ls-start') 到 mark('ls-end') 的差值会严重失真
localStorage 读写是同步磁盘 I/O，一旦数据量超 1MB，getItem + JSON.parse 可能持续 30–100ms 甚至更久——这期间主线程完全冻结，无法响应任何事件、无法触发 paint、也无法执行 requestIdleCallback。但如果你只在前后打两个 mark：
- 测出的「耗时」只是 JS 层面的执行窗口，掩盖了它对整个页面可交互状态的破坏性打断
- 若该操作发生在 React 组件挂载后、事件监听器绑定前，TTI 实际被推迟，但 mark 无法体现这个因果链
- Chrome Performance 面板中会显示为一条红色长任务（>50ms），而你的 mark 区间可能横跨多个长任务，或只覆盖其中一段
真实影响 TTI 的关键路径要这样抓
localStorage 不是独立瓶颈，它常嵌套在业务初始化链路里。比如：「首屏组件 mount → 读取本地缓存配置 → 解析 JSON → 合并到全局状态 → 触发 re-render → 绑定 click handler」。其中只有最后一步才关乎 TTI。建议在以下节点精准打点并联动监控：
-
performance.mark('ls-read-start')：调用localStorage.getItem前一刻 -
performance.mark('ls-parse-end')：JSON.parse(result)完成后立即打点 -
performance.mark('tti-ready-check')：所有关键事件监听器（如搜索框 input、按钮 click）绑定完毕后打点 - 同时用
PerformanceObserver监听longtask类型，记录该区间内是否出现 ≥50ms 的任务，及其起止时间戳
如何用 mark 辅助构建可归因的 TTI 影响分析
把 localStorage 操作当作一个「可疑扰动源」，而非直接测量对象。推荐组合策略：
- 对每个 localStorage 读取操作，生成唯一 traceId（如
ls-config-v2-20260518），并在所有相关 mark 名称中带上该 ID - 上报时，不仅传 measure 数据，还附带：
longtask.count、longtask.maxDuration、tti-ready-check时间戳、以及从 navigationStart 到该 mark 的偏移量 - 在大盘中交叉分析：当
ls-parse-end距离tti-ready-check＜ 500ms，且该区间内存在 ≥1 次长任务，则标记为「localStorage 关联 TTI 延迟样本」 - 对比实验：灰度关闭某项大缓存读取，观察对应用户群的 TTI 中位数下降幅度（通常可降 300–800ms）
规避方案比测量更重要
一旦确认 localStorage 是 TTI 瓶颈，优先改造而非加强监控：
- 将大数据缓存迁移至 IndexedDB，用异步读取替代同步阻塞
- 若必须用 localStorage，拆分存储：高频小字段（如 theme、lang）保留在 localStorage；低频大结构（如用户历史、离线数据）走 IndexedDB 或内存缓存
- 首次启动时，用
requestIdleCallback延迟非关键缓存加载，确保 TTI 不被阻塞 - 对 JSON.parse 加防抖：若解析耗时 >20ms，记录 warn 并上报，作为后续重构依据
