浏览器能否通过校验标识复用不同来源缓存的JS库？

Yes, you absolutely can implement this in your offline network scenario, and the best approach relies on Service Worker-powered custom caching logic combined with Subresource Integrity (SRI) to verify resource consistency. Here's a step-by-step breakdown tailored to your use case:

Core Idea #

Browsers default to caching resources by their full request URL, which means identical files from different device origins are treated as separate resources. To bypass this, we need to create a cache key based on the file's cryptographic hash (not the URL) and use a Service Worker to intercept requests and serve matching cached resources regardless of the origin.

Implementation Steps #

1. Add SRI Attributes to Script Tags #

First, ensure every SPA on your devices includes the integrity attribute on the <script> tag for the shared library. This lets both the browser and your Service Worker verify the file's authenticity and match it to cached versions:

<script 
  src="liblarge.js" 
  integrity="sha256-B4...X" 
  crossorigin="anonymous"
></script>

• The crossorigin="anonymous" attribute is required here because we're dealing with cross-origin resources (different devices count as separate origins). Your devices' web servers must return a valid Access-Control-Allow-Origin header (e.g., * for your trusted offline network) to enable this.

2. Deploy a Shared Service Worker #

Create a Service Worker script that's included in every SPA on your devices. This worker will handle caching logic based on the library's hash:

Key Logic in the Service Worker:

const LIBRARY_HASH = 'sha256-B4...X'; // The fixed hash of your shared library
const CACHE_NAME = 'shared-library-cache';

// Intercept fetch requests
self.addEventListener('fetch', (event) => {
  const request = event.request;
  // Check if the request is for your large library
  if (request.url.endsWith('liblarge.js')) {
    event.respondWith(
      caches.open(CACHE_NAME)
        .then(cache => {
          // First, check if we have a cached resource matching the target hash
          return cache.match(LIBRARY_HASH)
            .then(cachedResponse => {
              if (cachedResponse) {
                // Return the cached library immediately
                return cachedResponse;
              }
              // If no cache exists, fetch from the current device's server
              return fetch(request)
                .then(networkResponse => {
                  // Cache the response using the hash as the key for future reuse
                  cache.put(LIBRARY_HASH, networkResponse.clone());
                  return networkResponse;
                });
            });
        })
    );
  }
});

• This script checks for requests to liblarge.js, looks for a cached version stored under the fixed hash key, and serves it if available. If not, it fetches from the current device, caches it with the hash key, and serves the network response.
• For dynamic hash detection (if you might update the library later), you can parse the page's script tags to extract the integrity value instead of hardcoding it, but hardcoding works for your static shared library scenario.

3. Ensure Consistent Library Hashes #

Critical to this setup: all devices must host the exact same version of liblarge.js so the SHA-256 hash remains identical. Any modification to the library will break the cache matching, so you'll need to enforce version consistency across your offline devices.

Additional Considerations #

• CORS Configuration: Each device's web server must send the Access-Control-Allow-Origin header (e.g., *) to allow cross-origin resource verification and caching.
• Service Worker Scope: Make sure the Service Worker is registered at the root of each SPA's origin to cover all requests for the library.
• Browser Support: All modern browsers support Service Workers and SRI, which should be sufficient for most enterprise offline device setups. If you have older browsers, you may need a fallback (but this is rare in managed environments).

Why This Beats Other Options #

• Avoids the overhead of scanning for fast devices: The Service Worker uses the browser's local cache directly, no need to detect or connect to fast devices dynamically.
• Works within offline network constraints: No CDN required—all caching is handled locally in the administrator's browser.

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