URLConnection.getLastModified()返回服务器响应头中的Last-Modified时间戳（毫秒级GMT值），非内容真实更新时间；若服务器未返回该头则返回0；需配合setIfModifiedSince()和304状态码校验是否更新，建议与ETag结合使用以提高准确性。
URLConnection.getLastModified() 本身不能直接“判断是否更新”，它只返回服务器在响应头中提供的 Last-Modified 时间戳（毫秒级 Unix 时间）。是否更新，需要你主动拿这个值和本地已知的上次时间做比对。
理解 getLastModified 的含义和限制
该方法读取 HTTP 响应头中的 Last-Modified 字段，返回一个 long 类型数值，代表资源最后一次被服务器认为“修改过”的时间（GMT 时间戳）。但要注意：
- 它不是网页内容的实际变更时间，而是服务器设置或生成该响应时填写的值
- 对动态页面（如 PHP、JSP、Node.js 渲染页），这个时间常常是“当前响应时刻”，而非内容真正更新的时间
- 如果服务器没返回该 Header，方法返回 0，不代表没更新，只是信息缺失
配合 If-Modified-Since 实现服务端校验
更可靠的做法不是自己比时间，而是让服务器判断。流程是：
- 首次请求后，记录下
connection.getLastModified()的值（记为lastTime） - 后续请求前，设置请求头：
connection.setIfModifiedSince(lastTime) - 发起请求，检查响应码：
✓ 返回304 Not Modified→ 内容未更新
✗ 返回200 OK→ 内容已更新，响应体包含新内容
建议搭配 ETag 使用提升准确性
单独依赖 Last-Modified 容易误判，尤其当资源修改时间粒度粗（如只精确到秒）或服务器随意填充时。Etag 是更精准的内容指纹：
- 首次请求获取
response.getHeaderField("ETag") - 后续请求添加请求头：
request.setHeader("If-None-Match", etagValue) - Etag 优先于 Last-Modified：两个条件同时满足才返回 304；任一不满足即返回 200
实际编码注意点
使用时需确保连接配置正确：
- 调用
getLastModified()前必须先执行connect()或触发响应（如getInputStream()） - 若启用了缓存（
setUseCaches(true)），可能拿到本地缓存结果，导致时间不准；调试阶段可临时设为 false - Android 上注意线程限制：网络操作不能在主线程执行，否则抛
NetworkOnMainThreadException
