# 解决GWT应用中的nocache.js浏览器缓存问题

## 作者：吉祥法师

## 核心概念

GWT（Google Web Toolkit）是一款允许开发者使用Java语言编写Web应用程序前端逻辑的开发框架。在GWT应用的生产模式下，`nocache.js`文件扮演着至关重要的角色——它是应用程序的启动入口文件，负责根据用户浏览器的特性（如User-Agent、语言设置等）动态加载对应的已编译缓存文件（通常以`.cache.html`或`.cache.js`为后缀）。然而，该文件也可能成为开发与运维过程中的痛点。许多开发者会遇到如下典型问题：当重新编译GWT项目后，虽然Web服务器成功发送了新的`nocache.js`文件（状态码为200 OK），但浏览器依然顽固地使用其旧缓存版本，导致应用加载失败的、不存在的缓存文件（如`6E89D5C912DD8F3F806083C8AA626B83.cache.html`），最终页面呈现为空白。

这一问题的核心在于**浏览器缓存的判定机制**与**Web服务器的缓存控制策略**之间存在不匹配。浏览器并非简单地根据文件是否更新就决定缓存是否有效，它还会根据HTTP响应头中的失效时间、是否包含`max-age`指令等参数来做出判断。当这些缓存控制参数缺失或配置不当，浏览器可能依据启发式算法误判文件仍未过期，从而拒绝向服务器请求新版本。

## 逻辑结构

首先分析问题的根源，识别出浏览器缓存策略与服务器更新之间的冲突。接着探讨几种解决方案，从调整HTTP缓存响应头、改进服务器配置，到修改宿主页面以绕过缓存机制，最后提及一些临时但有效的方法。总体结构分为问题诊断、解决方案详述和预防措施三大部分。

## 主要论点与论据

### 问题诊断：浏览器缓存为何失效

在理解了核心概念后，我们需要精确诊断问题的成因。案例中，用户通过Chrome开发者工具观察到浏览器确实发出了请求，服务器也返回了200 OK，但最终浏览器加载的内容仍是旧版本。这看似矛盾的现象实际上揭示了缓存机制的复杂性。

#### 服务器返回的确认与新文件的忽略

根据用户提供的HTTP请求/响应头信息，客户端发送的请求中包含了一个关键的HTTP条件请求头：`If-Modified-Since: Thu, 25 Oct 2012 17:55:26 GMT`。服务器收到该请求后，比较了文件的最后修改时间。若文件未发生变化，则返回304 Not Modified响应，指示浏览器继续使用本地缓存。但问题发生时，用户确认是新编译的文件，时间戳已更新。然而，服务器却依然返回了304状态码。这表明，浏览器或中间缓存层中存储的“最后修改时间”与实际服务器时间不一致，或者浏览器在某种条件下跳过了完整的条件请求流程，直接从缓存中读取了旧版本文件。

另一个可能性是浏览器在较早之前已经对该资源进行了标记，认为它永远不需要重新验证。根据HTTP RFC 2616第13.2.4节中的规定，如果响应中既未包含`Expires`头，也未设置`Cache-Control: max-age`或`s-maxage`等明确控制缓存的指令，缓存可以根据启发式方法自行计算一个“新鲜度生命周期”。Chrome等浏览器可能基于文件大小为内容分配了一个较长的缓存有效期，这导致了尽管文件内容已变，但浏览器仍在有效期之前强行使用了缓存内容。

此外，Chrome开发者工具的“网络”面板有时在缓存行为上并非100%透明。开发者可能看到状态码为200，但实际显示的内容却是从内存或磁盘缓存中直接加载的，而非真正的网络请求。开发者应该结合“已传输大小”和“资源大小”列来区分是从缓存加载还是从网络下载。如果“已传输大小”为0，说明数据来自缓存。

### 解决方案详述

#### 方案一：配置正确的HTTP缓存响应头（推荐方法）

最根本的解决方案是分别在Web服务器端为不同类型的GWT资源文件配置正确的缓存策略。这需要明确区分两类文件：`.nocache.js`和`.cache.*`文件。

-   **`.nocache.js`文件**：这是一个非强缓存文件。它应当被设置成**立即失效**，以实现每次访问都从服务器获取最新版本。必须通过`Cache-Control`头文件明确的`no-cache`（允许缓存但必须每次验证）或`max-age=0`配合`must-revalidate`来指示浏览器每次都要向服务器校验资源是否更新。
-   **`.cache.*`文件**（如`.cache.html`、`.cache.js`、`.cache.png`等）：这是GWT编译后生成的具有唯一哈希值的强缓存文件。一旦文件名不变，意味着其内容不变，因此可以设置**长期缓存**（例如一年），以充分利用浏览器缓存能力，提升页面加载速度。

对于Apache HTTP服务器，可参考以下配置：

```apache

    # 立即过期，每次请求都进行验证
    Header set Cache-Control "public, max-age=0, must-revalidate"
    Header set Expires "now"



    # 长期缓存，一年后过期
    Header set Cache-Control "public, max-age=31536000"
    Header set Expires "access plus 1 year"

```

对于lighttpd服务器（如案例中），需确保加载相关模块后配置如下：

```lighttpd
server.modules += ("mod_expire", "mod_setenv")

$HTTP["url"] =~ "\.nocache\." {
    setenv.add-response-header = ( "Cache-Control" => "public, max-age=0, must-revalidate" )
    expire.url = ( "" => "access plus 0 days" )
}

$HTTP["url"] =~ "\.cache\." {
    expire.url = ( "" => "access plus 1 years" )
}
```

这一方案能从根本上消除因启发式缓存策略导致的误判，是解决此问题的最优实践。

#### 方案二：修改宿主页面，添加动态参数以绕过缓存

如果像快速绕过缓存问题而不修改Web服务器配置——特别是对于开发和测试环境，或者在无法更改服务器配置的场景下——可以通过修改宿主HTML页面，为`nocache.js`的引用添加一个动态变化的请求参数来实现。

**方法2.1：将宿主页面改为JSP文件**

将原本的`MyProject.html`后缀重命名为`MyProject.jsp`，然后在引用`.nocache.js`的`
```

这种方法简单有效，但需要JDK（Java Development Kit）支持JSP，且改动了一个文件的类型，可能需要调整其他相关的链接或配置。

**方法2.2：使用客户端JavaScript动态插入脚本**

如果不希望改动文件类型或依赖服务器端技术，可以在HTML页面中编写一段JavaScript代码，在页面加载后才动态创建一个用于请求`nocache.js`的`