缓存高频访问的数值变量是见效最快的基础优化手段，需识别适合缓存的全局常量、计算中间值和稳定配置，并在函数作用域或模块级合理缓存，同时警惕上下文依赖、动态来源及多实例失效风险。
直接缓存高频访问的数值变量，能绕过重复计算、减少作用域查找、避免序列化开销，是见效最快的基础优化手段。关键不在于用多复杂的工具，而在于识别哪些值值得缓存、在哪一级做缓存、如何保证一致性。
识别适合缓存的数值变量
不是所有变量都适合缓存。重点关注三类：全局常量（如 Math.PI、HTTP 状态码）、重复调用的计算中间值（如循环中反复使用的 array.length）、稳定不变的配置数值（如超时毫秒数、分页大小）。这些值一旦确定就几乎不变化，且被高频读取——缓存它们收益明确、风险极低。
在函数作用域内做局部缓存
对单个函数内多次使用的数值，优先提取为局部常量：
- 避免在循环中反复访问 obj.items.length，改写为 const len = obj.items.length; 再循环
- 不推荐每次调用都执行 parseInt(config.timeout) || 5000，可提前解析并赋值给常量
- 若数值来自外部但生命周期覆盖整个函数，用 let cachedValue + 条件赋值模式，首次计算后复用
跨函数共享时用模块级静态变量
当多个函数需共用同一组数值（如地区编码映射表中的 ID 偏移量、状态码阈值），可用模块顶层变量封装：
- 新建 utils/number-cache.js，导出带懒加载逻辑的对象，例如：export const StatusThresholds = { get active() { return this._active ?? (this._active = parseInt(process.env.ACTIVE_THRESHOLD) || 100); } };
- 避免使用全局 window 或 globalThis 直接挂载，防止污染和测试干扰
- 不手动清理，也不设过期——只用于真正静态的数值，变更靠重启或热重载
警惕缓存失效与误用场景
数值缓存最怕“以为它不变，其实它会变”。以下情况应禁用或加防护：
- 涉及用户权限、租户上下文的数值（如当前用户的配额余额）——必须绑定上下文，不能无差别缓存
- 从 DOM 属性或 URL 参数动态读取的数值（如 input.valueAsNumber）——每次都要重新获取
- 依赖系统时间或随机数生成的值（如 Date.now() % 100）——缓存即错误
- 多线程/多实例环境下的共享数值缓存（如 Node.js cluster 模式）——需改用 Redis 或进程间通信同步
