Piku项目中NGINX缓存机制对查询参数的处理优化

在Piku项目的NGINX缓存配置中，默认的缓存键设计存在一个潜在问题：它忽略了URL中的查询参数。这一设计源于特定的使用场景（Mastodon图片缓存），但在大多数现代Web应用中，查询参数往往是API请求的重要组成部分。

问题背景

Piku的NGINX缓存配置使用$host$uri作为缓存键，其中$uri变量不包含查询字符串。这意味着以下两个请求会被视为相同并返回相同的缓存响应：

/api/data?id=123
/api/data?id=456

对于依赖查询参数的API服务（如RESTful接口），这种缓存行为会导致错误的结果返回，因为不同的查询参数本应产生不同的响应内容。

技术解决方案

更合理的做法是使用$host$request_uri作为缓存键，该变量包含完整的原始请求URI，包括查询参数。修改后的配置将确保：

1. 每个独特的URL（含查询参数）都有独立的缓存条目
2. API能够根据查询参数返回正确的响应
3. 缓存命中率更准确反映实际使用情况

实现影响

这一改动对现有系统的影响包括：

• 缓存存储需求可能增加，因为相同路径但不同参数的请求会创建多个缓存条目
• 对于确实不需要区分参数的特定路径，可以通过单独的location块进行特殊处理
• 提高了API服务的正确性和可靠性

最佳实践建议

在实际部署中，开发者应考虑：

1. 根据应用特性选择合适的缓存键策略
2. 对于高并发API，合理设置缓存过期时间
3. 监控缓存命中率以优化配置
4. 对于大型参数可能导致的缓存键过长问题，可以考虑参数哈希

这一优化已被合并到Piku项目的主干代码中，为开发者提供了更灵活的缓存配置选项。