当 localstorage.getitem('user') 返回字符串"null"而非 null 时，会因类型混淆引发登录误判、渲染异常等连锁错误；根源在于 localstorage 静默将 null/undefined 转为字符串，需在读写环节严格校验类型与值。
当 localStorage.getItem('user') 返回 null，却未做类型防护、直接参与字符串拼接或 JSON 解析，就可能把字面量 "null"（字符串）误当作有效数据，进而引发一连串逻辑错乱——这就是所谓“判定雪崩”：一个看似微小的 null 处理疏漏，导致登录状态误判、用户信息渲染为空、权限校验绕过、甚至接口请求携带非法字段。
一眼识别：'null' 字符串已悄然混入业务流
出现以下任一现象，极可能已掉入该陷阱：
- 控制台打印
localStorage.getItem('user')显示 "null"（带引号），而非 null（无引号）——说明它已被自动转成字符串 - 页面显示用户名为文字
"null"，而不是空白或报错 -
JSON.parse(localStorage.getItem('user'))报错SyntaxError: Unexpected token 'u' in JSON（因为解析的是字符串 "null"，不是 JSONnull） - 条件判断如
if (user.name)不报错但始终为false，因user实际是字符串"null"，没有name属性
根因定位：哪一步把 null 变成了 "null"
常见污染路径有三类：
-
错误存值：调用
localStorage.setItem('user', null)或localStorage.setItem('user', undefined)—— localStorage 会静默转成字符串"null"或"undefined" -
错误读值后二次赋值：先
let u = localStorage.getItem('user')（得null），再localStorage.setItem('user', u)（又存入"null"） -
服务端兜底返回字符串 "null"：API 响应中
data.user === "null"（注意是字符串），前端未清洗就直接存入
防御式写法：从源头掐断 'null' 字符串生成
所有写入和读取环节都需加守门逻辑：
- 写入前强制校验并过滤：
if (userObj && typeof userObj === 'object') localStorage.setItem('user', JSON.stringify(userObj)) - 读取后立即做空值与类型双检：
const raw = localStorage.getItem('user'); const user = raw && raw !== 'null' && raw !== 'undefined' ? JSON.parse(raw) : null; - 关键分支不依赖
if (user)，改用if (user && typeof user === 'object' && 'id' in user) - 开发期加一层调试保护：
console.assert(!['null','undefined'].includes(localStorage.getItem('user')), '⚠️ localStorage user is string "null"!')
快速自检清单（5秒可执行）
打开浏览器控制台，逐行运行：
-
localStorage.getItem('user')→ 看返回值是否带引号 -
typeof localStorage.getItem('user')→ 应为"string"，但内容不能是"null" -
JSON.parse(localStorage.getItem('user'))→ 若报错且错误含"null"或"undefined"，确认污染已发生 - 搜索项目代码中
setItem.*user.*null、setItem.*user.*undefined、setItem.*user.*\+\+?（隐式转换）等可疑模式
这种雪崩不来自复杂架构，而来自对基础类型边界的忽视。守住 null 的进出关口，比补十个 try-catch 更治本。
