JSONAPI-Resources 开发模式下的类缓存问题分析与解决方案

问题背景

在 Rails 开发环境中使用 JSONAPI-Resources 时，开发者可能会遇到一个棘手的问题：当修改资源类代码后，服务器需要重启才能生效。这个问题在 JSONAPI-Resources 的 v0-11-dev 分支中尤为明显，特别是在 2668b6b 提交引入类缓存机制后。

问题现象

开发者在开发过程中发现以下行为模式：

1. 启动开发服务器后，资源请求正常响应
2. 修改任何资源类代码（即使是无关字段）
3. 再次请求相同资源时，返回空结果
4. 检查 SQL 查询，发现自动添加了 WHERE (TRUE=FALSE) 条件

深入分析后发现，这个条件实际上来自 CanCanCan 授权库，当没有适用规则时会添加这个默认范围。而根本原因在于 JSONAPI-Resources 的类缓存机制与 Rails 的代码重载机制不兼容。

技术原理

JSONAPI-Resources 在 2668b6b 提交中引入了类缓存优化，通过 resource_klass_for 方法缓存资源类查找结果。然而，这个缓存机制存在两个关键问题：

1. 缓存存储在 JSONAPI::Resource 类中，而该类位于 gem 内部，不受 Rails 自动重载机制影响
2. 当应用代码修改后，Rails 会重载应用中的资源类，但 gem 内部的缓存不会自动清除

这导致以下不一致状态：

• 直接访问 YourModelResource 会得到重载后的新代码
• 通过 JSONAPI::Resource.resource_klass_for 查找会返回缓存中的旧代码

影响范围

这个问题会影响所有在开发模式下使用 JSONAPI-Resources 的项目，特别是：

• 使用 CanCanCan 进行授权的应用
• 频繁修改资源类定义的工作流程
• 依赖 Rails 开发模式即时重载特性的开发者

解决方案

JSONAPI-Resources 团队在 #1448 PR 中修复了这个问题。解决方案的核心思路是：

1. 使类缓存机制感知 Rails 的重载周期
2. 在代码重载时自动清除相关缓存
3. 确保缓存机制在开发和生产环境表现一致

最佳实践

对于使用 JSONAPI-Resources 的开发者，建议：

1. 及时更新到包含修复的版本
2. 在开发环境中验证代码修改是否即时生效
3. 如果遇到类似问题，检查是否是缓存不一致导致
4. 了解项目中使用的授权库（如 CanCanCan）与 JSONAPI-Resources 的交互方式

总结

类缓存是提高性能的有效手段，但在开发环境中需要特别考虑与代码重载机制的兼容性。JSONAPI-Resources 的这个问题展示了框架开发中平衡性能与开发体验的重要性，也提醒我们在引入缓存时要全面考虑各种使用场景。