可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载localStorage、sessionStorage与document.cookie都是同步且昂贵的浏览器 I/O 操作每次读取都会阻塞 JavaScript 主线程。本指南基于 Phoenix 仓库内.agents/skills/vercel-react-best-practices技能集中的js-cache-storage规则规则原文系统讲解如何在 React/Next.js 应用中用模块级Map为存储读取建立内存缓存覆盖 localStorage、Cookie 两种典型场景以及跨标签页、页面可见性变化等外部变更下的缓存失效策略。读完你将掌握一套可落地、可评测的读缓存、写同步、外部变更即失效的存储访问模式并能在 Phoenix 的js/app前端代码中找到对应的正反实例。为什么存储读取值得缓存同步 I/O 的成本在浏览器中localStorage、sessionStorage和document.cookie的访问是同步的。与普通内存变量不同读取它们涉及字符串解析与序列化Cookie 需要按;切分并解析键值对getItem需要处理内部编码渲染进程与存储后端之间的同步往返在热路径如渲染循环、事件处理器、工具函数中被反复调用时这些开销会被放大成可感知的卡顿。规则原文给出的影响等级为LOW-MEDIUM对应描述为 reduces expensive I/O定位是减少昂贵的 I/O属于 Vercel React Best Practices 技能集中JavaScript Performancejs-前缀这一类别。该类别在 SKILL.md 的优先级表中 排在第 7 位属于低-中影响但成本极低的优化改动小、收益确定、无副作用风险非常适合作为代码审查与重构的固定检查项。关键原则缓存读同步写外部变更即失效。反模式每次调用都读存储最常见的错误是封装一个读取函数但函数体内每次都直接访问存储。规则原文给出了典型反例function getTheme() { return localStorage.getItem(theme) ?? light } // Called 10 times 10 storage reads这个函数看似无害但问题在于调用方无法感知底层成本。在 React 中一个渲染路径上可能有多个组件或工具函数各自调用getTheme()在列表渲染、循环、事件处理等场景下10 次调用就意味着 10 次同步存储读取而这些读取返回的值在短时间内并不会变化。同类问题在 Phoenix 仓库中真实存在。以 js/app/src/contexts/ThemeContext.tsx 的getCurrentTheme()为例export function getCurrentTheme(): ProviderTheme { const themeModeFromLocalStorage localStorage.getItem( LOCAL_STORAGE_THEME_KEY ); // ... }getCurrentTheme与getCurrentThemeMode同一文件 L55-L63都会在每次被调用时直接执行localStorage.getItem(arize-phoenix-theme)。在初始化阶段它们被调用一次尚可接受但如果被放进渲染热路径或高频工具函数中反复调用就会累积不必要的同步 I/O——这正是本规则要消除的模式。正确模式模块级 Map 缓存规则给出的正解是用模块级Map做内存缓存读取时先查缓存未命中才访问存储写入时同步写存储并更新缓存保证缓存与存储始终一致const storageCache new Mapstring, string | null() function getLocalStorage(key: string) { if (!storageCache.has(key)) { storageCache.set(key, localStorage.getItem(key)) } return storageCache.get(key) } function setLocalStorage(key: string, value: string) { localStorage.setItem(key, value) storageCache.set(key, value) // keep cache in sync }要点拆解Map而非普通对象Map支持任意字符串键、天然去重、has/get/delete/clearAPI 完整还避免了对象原型链污染问题规则特别强调Use a Map (not a hook)。为什么不是 HookuseState/useMemo等 Hook 只能在组件顶层调用而缓存读取的需求遍布工具函数utils、事件处理器event handlers、模块初始化等非组件环境。模块级Map是唯一能到处可用的方案。空值也要缓存Mapstring, string | null允许缓存键存在但值为null的结果避免同一个不存在的键被反复穿透到存储层。写入路径的同步更新缓存storageCache.set(key, value)是保证一致性的关键只要所有写操作都经过同一个封装函数缓存就永远不会读到脏数据。这也是该模式与单纯 memoization 的核心区别——它同时管理了读缓存和写同步。Cookie 缓存整包解析 惰性快照Cookie 与 localStorage 不同document.cookie是一个包含全部 Cookie 的字符串读取单个 Cookie 需要先做整包解析。因此规则给出了一次性解析、快照缓存的模式let cookieCache: Recordstring, string | null null function getCookie(name: string) { if (!cookieCache) { cookieCache Object.fromEntries( document.cookie.split(; ).map(c c.split()) ) } return cookieCache[name] }要点惰性初始化cookieCache初始为null只有第一次真正读取时才解析document.cookie之后所有读取都命中内存中的Record快照一次性整包解析把document.cookie.split(; )的解析成本从每次读取摊薄为每次失效后第一次读取单值语义Cookie 通常整体变化所以这里用Recordstring, string | null做整包快照而不是逐键Map——这也呼应了js-cache-function-results规则中单值函数用简单变量缓存的模式见 rules/js-cache-function-results.md。缓存失效外部变更必须能让缓存失效内存缓存最大的风险是一致性localStorage 可以被其他标签页修改Cookie 可以由服务器通过Set-Cookie更新。规则给出了两套失效机制window.addEventListener(storage, (e) { if (e.key) storageCache.delete(e.key) }) document.addEventListener(visibilitychange, () { if (document.visibilityState visible) { storageCache.clear() } })storage事件这是浏览器在其他标签页修改localStorage/sessionStorage时触发的事件当前页自身的写入不会触发。事件对象携带key字段精确删除对应的缓存项即可e.key null表示clear()被调用此时应全量清空缓存。visibilitychange事件页面从后台切回前台document.visibilityState visible时可能错过了后台期间发生的外部变更最稳妥的做法是整体clear()重建缓存。这也同时覆盖了服务器设置的 Cookie在页面重新可见后可能已变化的情况。结合前文一套完整的失效策略可以归纳为三句话自己的写入写入函数内同步更新缓存setLocalStorage的set分支无需额外失效其他标签页的写入监听storage事件按e.key精确删除后台期间的外部变化含 Cookie监听visibilitychange回到前台时全量清空。需要注意权衡visibilitychange全量清空意味着每次从后台切回都会触发一次未命中→重新读取但这正是用极小成本换取确定一致性的合理代价符合规则原意。配套规则版本化与最小化 localStorage 数据缓存解决的是读取次数问题而存储层的数据体积与结构演进则由同技能集中的client-localstorage-schema规则规则原文负责两者搭配才是完整的存储最佳实践。该规则要点键名带版本前缀如userConfig:v2schema 变更时通过迁移函数从旧版本升级避免新旧结构冲突只存 UI 真正需要的字段面对一个 20 字段的服务端对象只把theme、notifications等必要字段写入存储既减小体积也避免把 token、PII、内部标志位意外落盘所有getItem/setItem必须包try-catchSafari/Firefox 的无痕模式、配额超限、存储被禁用等场景下读写会直接抛异常未捕获会拖垮整个功能。Phoenix 前端仓库对异常安全这一点有直接实现见 js/app/src/hooks/usePersistedState.ts。该 Hook 是useState的 localStorage 持久化替代品其try { localStorage.getItem(key) ... } catch { return defaultValue }与try { localStorage.setItem(...) } catch { /* degrade silently */ }的模式正是client-localstorage-schema与js-cache-storage两套规则共同的工程底线存储不可用绝不阻塞应用主流程。此外它按key独立读写、惰性初始化天然适合作为带缓存存储封装的 Hook 化外壳——需要缓存化改造时只需在它内部接入模块级Map即可。与相邻规则的联动完整的缓存心智模型在vercel-react-best-practices技能集的js-类别中本规则不是孤立的js-cache-function-results.md影响 MEDIUM用模块级Map缓存重复计算的函数结果如slugify与本文的存储缓存共享同一套模块级 Map 显式失效模式js-cache-property-access.md在循环中把obj.config.settings.value这样的深属性访问提前提升到循环外减少每次迭代的查找次数client-swr-dedup.md网络层请求去重与本地存储缓存形成远端/本地两条缓存链路。这些规则共同指向一个原则任何稳定不变的读取都值得在离调用点最近的内存层做一次缓存。存储缓存是其中成本最低、最容易落地的一种。落地检查清单将本文规则转化为可执行的审查与重构步骤定位用search找出代码中所有直接调用localStorage.getItem/sessionStorage.getItem/document.cookie的位置评估调用频率渲染热路径、循环、事件处理器内尤其可疑封装为每一类存储访问建立统一的读缓存 写同步封装模块级Map业务代码只允许通过封装函数读写失效按需挂载storage事件跨标签页与visibilitychange事件回到前台的失效逻辑防御读写全部包try-catch存储不可用时静默降级到默认值参照 usePersistedState.ts 的写法验证改造后对比热路径函数的调用次数可在封装函数内临时计数确认存储读取次数从 N 次降为 1 次回归验证多标签页同步、无痕模式、配额满等边界场景。遵循这套模式可以让同步存储 I/O 从每个调用点的隐藏成本收敛为每类存储一次性的缓存未命中成本在 Phoenix 这类承载大量交互面板与图表渲染的数据密集型前端应用中是一项投入产出比极高的性能优化。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐Kondo跨平台部署指南Windows、macOS和Linux完整教程Kondo跨平台部署指南Windows、macOS和Linux完整教程 Kondo是一款高效的跨平台项目清理工具能够帮助开发者轻松删除项目中的依赖文件和构建人工智能AI Agent音视频媒体生成工作流自动化AutoGPT 前端性能规则精讲为什么 localStorage、sessionStorage 与 Cookie 读取必须做内存缓存js-cache-storageAutoGPT 前端性能规则精讲为什么 localStorage、sessionStorage 与 Cookie 读取必须做内存缓存js cache sto人工智能AI Agent自主智能体Agent 工作流工作流自动化后端前端Cal.com 前端性能实践缓存 localStorage / sessionStorage / Cookie 同步读取js-cache-storage 规则详解Cal.com 前端性能实践缓存 localStorage / sessionStorage / Cookie 同步读取js cache storage 规后端前端企业应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Phoenix 前端性能实践：为 localStorage、sessionStorage 与 Cookie 读取建立内存缓存
可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载localStorage、sessionStorage与document.cookie都是同步且昂贵的浏览器 I/O 操作每次读取都会阻塞 JavaScript 主线程。本指南基于 Phoenix 仓库内.agents/skills/vercel-react-best-practices技能集中的js-cache-storage规则规则原文系统讲解如何在 React/Next.js 应用中用模块级Map为存储读取建立内存缓存覆盖 localStorage、Cookie 两种典型场景以及跨标签页、页面可见性变化等外部变更下的缓存失效策略。读完你将掌握一套可落地、可评测的读缓存、写同步、外部变更即失效的存储访问模式并能在 Phoenix 的js/app前端代码中找到对应的正反实例。为什么存储读取值得缓存同步 I/O 的成本在浏览器中localStorage、sessionStorage和document.cookie的访问是同步的。与普通内存变量不同读取它们涉及字符串解析与序列化Cookie 需要按;切分并解析键值对getItem需要处理内部编码渲染进程与存储后端之间的同步往返在热路径如渲染循环、事件处理器、工具函数中被反复调用时这些开销会被放大成可感知的卡顿。规则原文给出的影响等级为LOW-MEDIUM对应描述为 reduces expensive I/O定位是减少昂贵的 I/O属于 Vercel React Best Practices 技能集中JavaScript Performancejs-前缀这一类别。该类别在 SKILL.md 的优先级表中 排在第 7 位属于低-中影响但成本极低的优化改动小、收益确定、无副作用风险非常适合作为代码审查与重构的固定检查项。关键原则缓存读同步写外部变更即失效。反模式每次调用都读存储最常见的错误是封装一个读取函数但函数体内每次都直接访问存储。规则原文给出了典型反例function getTheme() { return localStorage.getItem(theme) ?? light } // Called 10 times 10 storage reads这个函数看似无害但问题在于调用方无法感知底层成本。在 React 中一个渲染路径上可能有多个组件或工具函数各自调用getTheme()在列表渲染、循环、事件处理等场景下10 次调用就意味着 10 次同步存储读取而这些读取返回的值在短时间内并不会变化。同类问题在 Phoenix 仓库中真实存在。以 js/app/src/contexts/ThemeContext.tsx 的getCurrentTheme()为例export function getCurrentTheme(): ProviderTheme { const themeModeFromLocalStorage localStorage.getItem( LOCAL_STORAGE_THEME_KEY ); // ... }getCurrentTheme与getCurrentThemeMode同一文件 L55-L63都会在每次被调用时直接执行localStorage.getItem(arize-phoenix-theme)。在初始化阶段它们被调用一次尚可接受但如果被放进渲染热路径或高频工具函数中反复调用就会累积不必要的同步 I/O——这正是本规则要消除的模式。正确模式模块级 Map 缓存规则给出的正解是用模块级Map做内存缓存读取时先查缓存未命中才访问存储写入时同步写存储并更新缓存保证缓存与存储始终一致const storageCache new Mapstring, string | null() function getLocalStorage(key: string) { if (!storageCache.has(key)) { storageCache.set(key, localStorage.getItem(key)) } return storageCache.get(key) } function setLocalStorage(key: string, value: string) { localStorage.setItem(key, value) storageCache.set(key, value) // keep cache in sync }要点拆解Map而非普通对象Map支持任意字符串键、天然去重、has/get/delete/clearAPI 完整还避免了对象原型链污染问题规则特别强调Use a Map (not a hook)。为什么不是 HookuseState/useMemo等 Hook 只能在组件顶层调用而缓存读取的需求遍布工具函数utils、事件处理器event handlers、模块初始化等非组件环境。模块级Map是唯一能到处可用的方案。空值也要缓存Mapstring, string | null允许缓存键存在但值为null的结果避免同一个不存在的键被反复穿透到存储层。写入路径的同步更新缓存storageCache.set(key, value)是保证一致性的关键只要所有写操作都经过同一个封装函数缓存就永远不会读到脏数据。这也是该模式与单纯 memoization 的核心区别——它同时管理了读缓存和写同步。Cookie 缓存整包解析 惰性快照Cookie 与 localStorage 不同document.cookie是一个包含全部 Cookie 的字符串读取单个 Cookie 需要先做整包解析。因此规则给出了一次性解析、快照缓存的模式let cookieCache: Recordstring, string | null null function getCookie(name: string) { if (!cookieCache) { cookieCache Object.fromEntries( document.cookie.split(; ).map(c c.split()) ) } return cookieCache[name] }要点惰性初始化cookieCache初始为null只有第一次真正读取时才解析document.cookie之后所有读取都命中内存中的Record快照一次性整包解析把document.cookie.split(; )的解析成本从每次读取摊薄为每次失效后第一次读取单值语义Cookie 通常整体变化所以这里用Recordstring, string | null做整包快照而不是逐键Map——这也呼应了js-cache-function-results规则中单值函数用简单变量缓存的模式见 rules/js-cache-function-results.md。缓存失效外部变更必须能让缓存失效内存缓存最大的风险是一致性localStorage 可以被其他标签页修改Cookie 可以由服务器通过Set-Cookie更新。规则给出了两套失效机制window.addEventListener(storage, (e) { if (e.key) storageCache.delete(e.key) }) document.addEventListener(visibilitychange, () { if (document.visibilityState visible) { storageCache.clear() } })storage事件这是浏览器在其他标签页修改localStorage/sessionStorage时触发的事件当前页自身的写入不会触发。事件对象携带key字段精确删除对应的缓存项即可e.key null表示clear()被调用此时应全量清空缓存。visibilitychange事件页面从后台切回前台document.visibilityState visible时可能错过了后台期间发生的外部变更最稳妥的做法是整体clear()重建缓存。这也同时覆盖了服务器设置的 Cookie在页面重新可见后可能已变化的情况。结合前文一套完整的失效策略可以归纳为三句话自己的写入写入函数内同步更新缓存setLocalStorage的set分支无需额外失效其他标签页的写入监听storage事件按e.key精确删除后台期间的外部变化含 Cookie监听visibilitychange回到前台时全量清空。需要注意权衡visibilitychange全量清空意味着每次从后台切回都会触发一次未命中→重新读取但这正是用极小成本换取确定一致性的合理代价符合规则原意。配套规则版本化与最小化 localStorage 数据缓存解决的是读取次数问题而存储层的数据体积与结构演进则由同技能集中的client-localstorage-schema规则规则原文负责两者搭配才是完整的存储最佳实践。该规则要点键名带版本前缀如userConfig:v2schema 变更时通过迁移函数从旧版本升级避免新旧结构冲突只存 UI 真正需要的字段面对一个 20 字段的服务端对象只把theme、notifications等必要字段写入存储既减小体积也避免把 token、PII、内部标志位意外落盘所有getItem/setItem必须包try-catchSafari/Firefox 的无痕模式、配额超限、存储被禁用等场景下读写会直接抛异常未捕获会拖垮整个功能。Phoenix 前端仓库对异常安全这一点有直接实现见 js/app/src/hooks/usePersistedState.ts。该 Hook 是useState的 localStorage 持久化替代品其try { localStorage.getItem(key) ... } catch { return defaultValue }与try { localStorage.setItem(...) } catch { /* degrade silently */ }的模式正是client-localstorage-schema与js-cache-storage两套规则共同的工程底线存储不可用绝不阻塞应用主流程。此外它按key独立读写、惰性初始化天然适合作为带缓存存储封装的 Hook 化外壳——需要缓存化改造时只需在它内部接入模块级Map即可。与相邻规则的联动完整的缓存心智模型在vercel-react-best-practices技能集的js-类别中本规则不是孤立的js-cache-function-results.md影响 MEDIUM用模块级Map缓存重复计算的函数结果如slugify与本文的存储缓存共享同一套模块级 Map 显式失效模式js-cache-property-access.md在循环中把obj.config.settings.value这样的深属性访问提前提升到循环外减少每次迭代的查找次数client-swr-dedup.md网络层请求去重与本地存储缓存形成远端/本地两条缓存链路。这些规则共同指向一个原则任何稳定不变的读取都值得在离调用点最近的内存层做一次缓存。存储缓存是其中成本最低、最容易落地的一种。落地检查清单将本文规则转化为可执行的审查与重构步骤定位用search找出代码中所有直接调用localStorage.getItem/sessionStorage.getItem/document.cookie的位置评估调用频率渲染热路径、循环、事件处理器内尤其可疑封装为每一类存储访问建立统一的读缓存 写同步封装模块级Map业务代码只允许通过封装函数读写失效按需挂载storage事件跨标签页与visibilitychange事件回到前台的失效逻辑防御读写全部包try-catch存储不可用时静默降级到默认值参照 usePersistedState.ts 的写法验证改造后对比热路径函数的调用次数可在封装函数内临时计数确认存储读取次数从 N 次降为 1 次回归验证多标签页同步、无痕模式、配额满等边界场景。遵循这套模式可以让同步存储 I/O 从每个调用点的隐藏成本收敛为每类存储一次性的缓存未命中成本在 Phoenix 这类承载大量交互面板与图表渲染的数据密集型前端应用中是一项投入产出比极高的性能优化。赞分享可观测性AI 评测LLMOpsAI 应用人工智能【免费下载链接】phoenixAI Observability Evaluation项目地址https://gitcode.com/gh_mirrors/phoenix13/phoenix点击查看免费下载相关推荐Kondo跨平台部署指南Windows、macOS和Linux完整教程Kondo跨平台部署指南Windows、macOS和Linux完整教程 Kondo是一款高效的跨平台项目清理工具能够帮助开发者轻松删除项目中的依赖文件和构建人工智能AI Agent音视频媒体生成工作流自动化AutoGPT 前端性能规则精讲为什么 localStorage、sessionStorage 与 Cookie 读取必须做内存缓存js-cache-storageAutoGPT 前端性能规则精讲为什么 localStorage、sessionStorage 与 Cookie 读取必须做内存缓存js cache sto人工智能AI Agent自主智能体Agent 工作流工作流自动化后端前端Cal.com 前端性能实践缓存 localStorage / sessionStorage / Cookie 同步读取js-cache-storage 规则详解Cal.com 前端性能实践缓存 localStorage / sessionStorage / Cookie 同步读取js cache storage 规后端前端企业应用创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考