内核类型比浏览器名更可靠，Web Storage容量限制由内核+平台共同决定；Blink抛QuotaExceededError，WebKit在iOS私密模式下静默失效，Gecko允许轻微超限；应实测边界、验证读写完整性并依内核行为设计降级策略。
直接看内核类型比看浏览器名字更可靠，但 Web Storage（尤其是 localStorage）的 5MB 限制并不是一个硬性、统一的数值，而是由内核实现 + 平台环境共同决定的。不同内核对“何时报错”“报什么错”“实际能写入多少字节”存在细微差异，识别这些差异的关键不在于查文档数字，而在于实测行为和错误响应模式。
用 try-catch 捕获真实写入边界
各内核在接近容量上限时的处理逻辑不同：Blink（Chrome/Edge）倾向于在写入超限时抛出 QuotaExceededError；WebKit（Safari）在 iOS 私密模式下直接禁用 localStorage，不报错但 setItem 无效；Gecko（Firefox）则可能允许略超（如 5.1MB），之后才拒绝。建议用渐进式填充法测试：
- 从 1MB 开始，每次增加 256KB 字符串写入
- 每次写入后立即读取验证内容完整性（避免压缩或截断未被发现）
- 捕获异常类型与 message，例如：
err.name === 'QuotaExceededError'或err.message.includes('storage') - 记录最后一次成功写入的字节数，而非依赖理论值
注意平台与模式带来的内核行为偏移
同一内核在不同环境下表现可能不一致：
- iOS Safari 使用 WebKit，但私密浏览下
localStorage完全不可用（getItem返回 null，setItem静默失败），需额外检测navigator.webdriver和document.hasStorageAccess - Android WebView 基于 Blink，但旧版本（如 Android 7 系统 WebView）可能将限额压到 2MB 且不抛标准异常，而是返回 undefined 或静默丢弃
- Firefox 在启用
dom.storage.next_gen实验性标志后，会切换为基于 SQLite 的新存储后端，限额更稳定，但默认仍走旧路径
用 Storage API 的响应特征辅助判断内核类型
单纯 UA 不可靠，但结合 Storage 行为可交叉验证内核：
- Blink 内核：多次快速写入小数据（如 1KB × 100）后触发
storage事件延迟明显，且localStorage.length更新滞后 - WebKit 内核：调用
localStorage.clear()后，再次setItem可能短暂返回undefined（尤其在页面刚加载时），这是其同步 I/O 调度特性所致 - Gecko 内核：对超长 key（>1000 字符）容忍度更高，而 Blink/WebKit 在 key 过长时可能提前报错，与底层哈希表实现有关
规避依赖绝对数值，转向弹性策略
与其纠结“到底是 4.8MB 还是 5.2MB”，不如按内核行为设计降级路径：
- 检测到 WebKit 且处于 iOS 环境 → 优先使用
sessionStorage或 IndexedDB（Safari 对后者限额更宽松） - 捕获到
QuotaExceededError且内核为 Blink → 清理过期键后再试，或启用 LRU 缓存淘汰逻辑 - Firefox 中
localStorage写入缓慢 → 改用chrome.storage.local（仅限扩展）或服务端 session 存储
