Loading... 最近在 Nuxt 4 项目中踩到了一个非常有意思的小坑。 github issues：https://github.com/nuxt/nuxt/issues/34006 某天晚上，一个用户反馈： > “我的 API Key 在页面上显示异常，接口也调不通。” 第一反应当然是怀疑后端。 但当我打开前端控制台，看到这一行输出时，我愣了一下： ``` userAccessKey: Infinity ``` ？？？ 我们的 API Key 是字符串。 它怎么会变成 `Infinity`？ --- ## 一、事故现象：只有一个用户出问题 后端日志显示： ``` Set-Cookie: userAccessKey=4e71375682906041; Path=/ ``` 非常正常。 没有 JSON，没有特殊字符，就是一串 key。 前端读取代码也非常简单： ``` const userAccessKey = useCookie('userAccessKey') console.log(userAccessKey.value) ``` 但输出却是： ``` Infinity ``` 更离谱的是： - 全平台只有这一个用户出问题 - 其他所有用户完全正常 - 我自己的账号也完全正常 这就非常诡异了。 --- ## 二、关键线索：那串“看起来普通”的 key 问题用户的 key 是： ``` 4e71375682906041 ``` 乍一看没什么问题。 但如果你对 JavaScript 数值敏感一点，就会意识到： ``` 4e71375682906041 ``` 在 JS 里会被理解为： ``` 4 × 10^71375682906041 ``` 也就是说： ``` Number("4e71375682906041") ``` 而 JavaScript 的最大数值是： ``` Number.MAX_VALUE ≈ 1.79e+308 ``` 但这里的指数是： ``` 71375682906041 ``` 远远超出 JS 能表示的范围。 所以： ``` Number("4e71375682906041") === Infinity ``` 问题来了。 --- ## 三、但我们明明存的是字符串啊？ 没错。 Cookie 本质就是字符串。 后端也确实发的是字符串。 问题出在前端的这一行： ``` useCookie('userAccessKey') ``` Nuxt 的 `useCookie()` 默认会做类型推断。 它会尝试： - `"true"` → boolean - `"123"` → number - `"{}"` → object - `"[]"` → array - `"4e10"` → number 也就是说，只要字符串“长得像数字”，它就会尝试转成 Number。 于是整个链路变成： ``` Cookie 字符串 → useCookie 自动类型推断 → Number("4e71375682906041") → Infinity → 原始字符串丢失 ``` 这不是后端的问题。 是前端自动解析的问题。 --- ## 四、为什么只有一个用户中招？ 因为这是一个“概率型事故”。 我们的 API Key 是随机生成的。 要刚好生成： ``` 纯数字 + e + 纯数字 ``` 概率本身就不高。 更罕见的是： 指数还必须足够大，才能溢出成 `Infinity`。 所以： - 上万用户 - 只有一个用户 - 随机撞上了科学计数法形态 这就是典型的： > 低概率 × 大样本 = 必然发生 它不会高频出现。 但它一定会再出现。 --- ## 五、前端为什么会“显示异常”？ 因为前端拿到的值已经不是原始字符串了。 页面展示 key 时： ``` {{ userAccessKey }} ``` 实际渲染的是： ``` Infinity ``` 而当它参与接口请求时： ``` headers: { Authorization: userAccessKey.value } ``` 实际发送的是： ``` Authorization: Infinity ``` 鉴权自然失败。 用户看起来像是： - key 错了 - 权限失效 - 数据异常 但真实原因只是： > 前端把字符串解析坏了。 --- ## 六、如何修复？ 最简单直接的方式： ``` const userAccessKey = useCookie<string>('userAccessKey', { decode: (v) => v }) ``` 明确告诉 Nuxt： > 不要帮我做类型推断。 或者在后端写 Cookie 时，把它 JSON 字符串化： ``` Set-Cookie: userAccessKey="4e71375682906041"; Path=/ ``` 核心原则只有一句话： > Token / Key / ID 永远当字符串处理。 --- ## 七、这个问题的本质 这不是 Nuxt 的 bug。 这是“自动类型推断”的副作用。 框架为了“方便”： - 自动帮你解析类型 - 减少手写 JSON.parse - 让 API 更优雅 但代价是： - 隐式行为 - 不可预测的边界问题 - 数据语义被破坏 这触碰到了一个经典设计原则： > 显式优于隐式。 Cookie 是协议层数据，本质就是字符串。 如果框架默认进行类型猜测，就一定会遇到边界问题。 只是时间问题。 --- ## 八、这次事故给我的一个提醒 线上系统中： - 概率不会站在你这边 - 用户的数据分布不可控 - 任何“看起来不太可能”的组合都会出现 这次是科学计数法。 下次可能是： - JSON 结构误解析 - 布尔值误判 - 数字精度丢失 真正安全的做法是： > 永远不要对外部数据做隐式语义猜测。 --- ## 九、最后总结一句 当你的 access key 长得像科学计数法时： 它真的会被当成科学计数法。 然后，变成 Infinity。 猜你想看 每日一学：PHP 中的 `array_uintersect` 函数详解 Vue3使用Pinia 给网站更换HarmonySanc字体 Vue生命周期 ants2.0 SCDN策略介绍及配置 Vue学习小案例 nuxt3使用element-plus webpack的基本使用 JS离开窗口改变title PHP发送TCP和UDP请求 最后修改：2026 年 02 月 21 日 © 允许规范转载 赞 0 如果觉得我的文章对你有用，请随意赞赏
