以前写的有问题，编辑下。
研究了半天，原来 Chrome 扩展不支持文件存储，只能使用 chrome.storage 保存持久化数据。
提供两种形式，一种可以在浏览器间自动同步，适用登录用户保存设置，比如微博的“眼不见心不烦”，chrome.storage.sync，提供一个 key 8K，最大512个 key，总数据量100K（即不可能512个 key 都装满）的存储。这个方式对读写频率也有限制，想想也好理解，比精要往 Google 的云同步嘛。
另外一种则更接近平时用的 localStorage，叫 chrome.storage.local。它的限制很少，只要总量不大于5M即可（可以通过设置 unlimitedStorage: true 来取消上限）。
使用的时候，需要在 manifest.json 里声明权限
{
"permissions": [
"storage"
]
}
这样的话就比较符合我的预期了，用户可以任意保存字幕到本地，太多了自己删掉就是，如果希望云同步就付费或者看广告。
开发 Chrome 插件时，如果使用 popup.html，调试时反复审查元素很麻烦。此时可以用
chrome-extension://插件id/popup.html
在新标签页打开，就简单多了。
最近尝试开发Chrome插件，自然使用JQ来当基础。结果遇到一个问题：
我使用“程序注入（Programmatic injection）”的方式执行代码，试图实现自动填写表单的功能。因为目标网页的表单比较智能，前面的选项会影响后面选项的内容，所以必须在val(value)之后广播change事件来触发后面表单内容的填充。
结果失败了。直接在浏览器里使用控制台运行代码，没有问题，所以代码本身应该正确；确认需要的JS文件已经一一加载。于是我开始了漫长而挫折的调试之路。多次失败之后，我打开《英雄无敌三》换换心情……玩了一会儿游戏意外退出了，而我灵机一动，会不会是JQ广播事件的问题？在控制台调试没有问题，但是在content script里就不行，很可能是chrome把两段代码放在彼此隔离的环境中运行导致的。于是我放弃直接$(selector).change()，改用原生的dispatchEvent，结果，运行成功！
于是我猜，应该是JQ和Chrome的插件机制稍有冲突。可能以后做插件的话，还是Closure Library好些吧。
PS：写插件的好处是不用考虑兼容性，朝着Chrome写就行了。