问题
I'm writing a packaged app for Chrome. Is there an advantage to using the background page - instead of the app's main HTML page - to read/write the localStorage values?
Currently users seem to be losing data in ways I cannot duplicate. Right now the app reads and writes localStorage in the main HTML page's JavaScript. Would changing the app to use the background page's JavaScript fix this?
回答1:
LocalStorage is limited to 5 megabytes, regardless of set permissions.
When users checks the "Delete cookies and other website and plugin data" on chrome://settings/clearBrowserData then I believe both site specific and extension localstorage files are deleted. Maybe this is how your users are "losing" data.
Using the background page to read/write to localstorage prevents corruption of your data from other extensions, which can happen for site domain localstorage files as only your background page can access the file.
While other extensions indeed can call your background page, they still have to use your save/load functions to access your extension localstorage file.
回答2:
The problem might be with the context of the localStorage container. When run from the background script you are saving the the localStorage of your extension. When run from a content script you are saving to a localStorage are for that specific website. localStorage.setItem( 'xx', 'yyy' ) that is written by a content script on a google.com page can't be read by localStore.getItem( 'xx' ) call from a content script on yahoo.com
来源：https://stackoverflow.com/questions/10194969/accessing-writing-to-chrome-app-localstorage