深入解析openapi-ts项目中无限查询的queryKey问题

在openapi-ts项目中，当开发者使用@tanstack/react-query插件处理无限查询(infinite queries)时，会遇到一个隐蔽但影响重大的技术问题。这个问题涉及到查询键(queryKey)在分页请求中的意外修改，导致React Query内部状态管理出现异常。

问题本质

在无限查询场景下，每个分页请求都会基于基础参数(queryKey)加上特定分页参数来执行。然而，当前实现中存在一个关键缺陷：queryKey在分页过程中被意外修改。具体表现为：

1. 生成的代码直接引用queryKey而非创建副本
2. 每次调用createInfiniteParams时，分页参数会被意外添加到原始queryKey中
3. 随着分页进行，queryKey不断被污染

技术影响

这个问题会引发React Query内部的多重异常：

1. 查询哈希不匹配：React Query使用queryKey计算哈希作为缓存键，当queryKey被修改后，哈希与存储数据不再对应
2. 缓存访问失效：无法通过公开API查询、更新或删除已缓存的数据
3. 异常重取行为：React Query会错误地触发数据重新获取，因为它无法识别缓存中已存在的数据
4. 核心功能受损：所有依赖queryKey的后置操作（如设置、获取、更新、无效化、清除等）都会出现异常

解决方案

修复方案相对简单但效果显著：在createInfiniteParams函数中，应该创建queryKey的副本而非直接引用。具体修改如下：

原问题代码：

const params = queryKey[0]

修正后代码：

const params = { ...queryKey[0] }

这一修改确保了：

1. 原始queryKey保持不变
2. 每个分页请求使用独立的参数对象
3. React Query的缓存机制能够正常工作

最佳实践建议

在使用openapi-ts生成无限查询代码时，开发者应当：

1. 确保使用最新版本，该问题已在后续版本中修复
2. 对于自定义无限查询实现，始终注意queryKey的不可变性
3. 在复杂查询场景中，考虑使用序列化技术确保queryKey稳定性
4. 监控查询缓存行为，及时发现潜在的key污染问题

这个案例很好地展示了React Query中queryKey管理的重要性，也提醒我们在处理状态管理库时需要特别注意引用与副本的区别。