一次由于开启 Safari 无痕浏览引发的艰难“捉虫”事件

事件回顾

做了一个移动端的页面，测试的时候出现了一个诡异的 bug。别的浏览器都好好的，就 ios 的 Safari 浏览器页面停止了渲染，似乎是有一段 js 文件没有载入。但是奇怪的是，同一型号的 iphone 的 Safari 浏览器，有些可以，有些不行，一度让我以为不可能是代码的问题（如果是代码的问题，应该都挂才科学啊），而是个别机器的原因。但是最后的最后，定位出来的原因是 Safari 开启了 无痕浏览模式！

就是这样：

DEBUG

当然，除了 Safari 开启了无痕浏览外，另一个重要的原因就是程序里使用了 localStorage。localStorage 作为 H5 新兴的 API，在移动端表现良好，深受程序员青睐。但是也并不是所有移动设备都支持，所以我们一般会写成这个样子：

// 如果支持 localStorage
if (window.localStorage) {
  // ...
} else {
  // ...
}

但是当 Safari 开启无痕模式的时候，很显然浏览器本身是支持 localStorage 的，所以 !!window.localStorage 会返回 true，但是去使用 localStorage 的 api 的时候，就会报错（QuotaExceededError: Dom exception 22）！有没有很坑爹！明明告诉你了我特么有这个功能，召唤你来用吧来用吧，真要用了却跪舔了！所以不得不说，浏览器能力检测，1% 的情况下，也会跪啊...

再回头来看看无痕模式，顾名思义就是不记录用户浏览的数据，当 Safari 遭遇 Storage 的时候程序跪了，那么 Storage 的好兄弟 cookie 呢？用 cookie 写了一段类似的存储代码，却没有问题， nice！

既然知道了原因，那么解决方式就呼之欲出了。我们可以用 try..catch 来处理要用到 localStorage 的代码：

try {
  localStorage.setItem('a', 'hello world');
  console.log(localStorage.getItem('a'));
} catch(e) {
  // 当 Safari 开启无痕模式时的补救措施
  console.log(e.message, e.name, e.stack);  // 输出错误信息

  // ...
}

总结

经此一役，思考良久总结几点：

浏览器的功能测试并不是万能的
在移动端开发用到 localStorage 的时候，如果要做到完美，请考虑下用户在 Safari 下开启无痕浏览模式的情况
以前没觉得 try..catch 有什么用，既然知道某个代码块可能出错，为什么还要这么写呢？现在...

PS：事后发现 stackoverflow 早已有精彩解答 Iphone localStorage “QUOTA_EXCEEDED_ERR” issue

2015-12-02 更：

如果一定要适配 Safari 下的无痕浏览模式，可以在 HTML 文件最开始判断下是否处于 Safari 的无痕浏览模式中：

try {
    localStorage.setItem('isPrivateMode', '1');
    localStorage.removeItem('isPrivateMode');
    window.isPrivateMode = false;
} catch(e) {
    window.isPrivateMode = true;
}

然后再在每次调用 localStorage 的 API 的时候进行判断：

if (!window.isPrivateMode && window.localStorage) { // 不是 Safari 无痕模式并且能用 localStorage
  // ...
}

2015-12-02 更：

Safari 下的无痕浏览模式似乎是忽略 localStorage 的 getItem() 和 romoveItem()，而在 setItem() 的时候报错？详见移动端浏览器隐私模式/无痕模式使用本地存储localStorage/sessionStorage的问题。可以直接在 PC 端的 Safari 浏览器的“秘密浏览”模式下模拟（控制台输入）。