Unity WebGL应用更新后如何保留PlayerPrefs本地数据？

Hey there, I’ve run into this exact issue with Unity WebGL builds before—super frustrating when user settings vanish after an update. Let’s break down why this happens and the concrete fixes you can implement right away:

Why Does the Data Disappear? #

Unity’s default WebGL PlayerPrefs uses IndexedDB under the hood, but it ties the database name to a build-specific hash generated during each compile. When you upload a new version, this hash changes, so Unity creates a fresh IndexedDB instance instead of reading the old one. The old data is still in the browser—Unity just can’t find it anymore.

Solutions to Preserve Data #

1. Build a Custom IndexedDB Wrapper (Recommended for Larger Data) #

Ditch Unity’s default PlayerPrefs and roll your own IndexedDB logic using a JavaScript plugin. This lets you use a fixed database name that doesn’t change between builds. Here’s a quick outline:

• Create a .jslib file in your Unity project’s Plugins/WebGL folder with custom IndexedDB functions (open database, save/load key-value pairs).
• Use [DllImport("__Internal")] in your C# code to call these JS functions.
• Example JS snippet for saving data:

  function SavePersistentData(key, value) {
    const dbName = "MyGamePersistentDB"; // Fixed name that never changes
    const request = indexedDB.open(dbName);
    request.onsuccess = function(event) {
      const db = event.target.result;
      const transaction = db.transaction("dataStore", "readwrite");
      const store = transaction.objectStore("dataStore");
      store.put({key: key, value: value});
    };
  }
  

• This ensures your data lives in a consistent database, regardless of build updates.

2. Migrate Old PlayerPrefs Data to a New Store #

If you already have users with existing data, add a migration step on game launch:

• Use JS to scan the browser’s IndexedDB databases for Unity’s default UnityPlayerPrefs_<hash> entries.
• Extract the data from the old database and write it to your custom fixed-named database (or even LocalStorage).
• Once migrated, you can delete the old Unity PlayerPrefs database to clean up unused storage.

3. Use LocalStorage for Small, Simple Data #

For lightweight data like language settings or user preferences, LocalStorage is a simpler alternative. It uses fixed key-value pairs tied to your domain, so updates won’t wipe it:

• Call JS functions from Unity to read/write LocalStorage:

  #if UNITY_WEBGL && !UNITY_EDITOR
  [DllImport("__Internal")]
  private static extern void SetLocalStorage(string key, string value);
  [DllImport("__Internal")]
  private static extern string GetLocalStorage(string key);
  #endif
  
  // Usage example
  public void SaveLanguage(string lang) {
      #if UNITY_WEBGL && !UNITY_EDITOR
      SetLocalStorage("game_language", lang);
      #endif
  }
  

• Note: LocalStorage has a ~5MB size limit, so it’s not ideal for large datasets.

4. Tweak Unity Build Settings #

Check your Unity Player Settings > WebGL > Publishing Settings:

• Disable Cache Busting if you don’t need it—this feature changes asset filenames with a hash, which can indirectly affect the PlayerPrefs database hash.
• While Unity’s default persistent data path is tied to the build hash, double-check that no custom settings are amplifying the issue.

Key Notes #

• Always test migrations thoroughly across different browsers (Chrome, Firefox, Safari) to ensure data transfers correctly.
• For sensitive data, consider encrypting it before storing in IndexedDB/LocalStorage—browser storage is accessible to anyone with access to the user’s device.

内容的提问来源于stack exchange，提问作者Carsten