Observable框架中FileAttachment.lastModified属性在文件变更后失效问题解析

问题背景

在Observable框架的预览服务器模式下，开发者使用FileAttachment加载本地静态JSON文件时发现一个异常现象：当被引用的文件内容发生变更后，虽然数据能够正确重新加载且文档会自动更新，但FileAttachment实例的lastModified属性却意外丢失。该属性原本用于标识文件的最后修改时间戳，对于实现缓存策略和版本控制具有重要意义。

技术原理分析

通过深入源码分析，我们发现该问题源于框架的预览服务器工作机制：

1. 实时更新机制：预览服务器通过WebSocket实时监听文件系统变更，当检测到被引用文件修改时，会立即通知客户端重新获取最新文件内容。
2. 属性同步缺陷：在文件变更的差异对比(diff)处理过程中，框架未能正确地将lastModified属性从旧实例传递到新创建的FileAttachment实例中。

解决方案演进

核心开发者提出了两种可能的解决路径：

1. 阻塞式加载方案：

   • 等待数据加载器(data loader)完全执行完毕后再向客户端报告变更
   • 缺点：会导致页面渲染阻塞，开发者体验下降，且需要重构现有的懒加载机制

2. 智能时间戳方案：

   • 在预览模式下，当检测到数据加载器源文件变更时，使用源文件的修改时间而非缓存输出文件的修改时间
   • 优点：保持非阻塞特性，开发者无感知，实现成本较低

最终采用第二种方案，因为：

• 保持现有实时预览的流畅体验
• 对开发者透明，无需处理lastModified缺失的特殊情况
• 实现成本低且风险可控

问题影响范围

进一步测试发现该问题不仅限于数据加载器生成的文件，而是影响所有通过FileAttachment引用的文件类型。这表明问题出在通用的文件变更处理逻辑层，而非特定于数据加载器的实现。

最佳实践建议

对于开发者而言，在框架修复版本发布前可以采取以下临时方案：

1. 对于不需要精确修改时间的场景，可以忽略该属性
2. 如需严格依赖修改时间，可暂时通过定期刷新页面获取准确值
3. 考虑在应用层实现自定义的缓存失效逻辑作为补充

该问题的修复将包含在后续的框架版本更新中，届时开发者只需升级到最新版本即可自动获得修复。