Kong/Insomnia中查询字符串环境变量解析异常问题分析

在Kong/Insomnia项目的最新版本11.0.0中，用户报告了一个关于查询字符串参数解析的异常现象。当请求中包含预请求脚本时，环境变量的解析会出现不符合预期的编码行为。

问题现象

当用户通过图形界面设置查询参数时，如果该参数引用了环境变量，且请求中同时存在预请求脚本（即使脚本内容为空），系统会将查询参数中的变量标记进行URL编码转换。例如：

正常期望的请求格式应为：

POST /api?test1=test1Value HTTP/1.1

但实际获得的请求格式变为：

POST /api?test1=%7B%7B%2B_.test1%2B%7D%7D HTTP/1.1

技术背景

查询字符串是URL中问号(?)后面的部分，用于向服务器传递参数。在HTTP客户端工具中，通常会提供两种方式来设置查询参数：

1. 通过专门的查询参数输入界面
2. 直接在URL后附加查询字符串

环境变量是开发过程中常用的配置方式，允许开发者将变量值集中管理。在Insomnia中，可以通过{{variable}}的语法引用环境变量。

问题原因

经过分析，这个问题出现在Insomnia的请求构建流程中。当存在预请求脚本时，系统会对所有参数进行预处理，包括查询字符串中的环境变量引用。在这个过程中，变量引用标记被错误地当作普通字符串进行了URL编码，而不是先解析变量值再进行编码。

临时解决方案

目前推荐的临时解决方案是：

• 直接在URL中附加查询参数，使用http://example.com/api?test1={{test1}}的格式
• 避免在查询参数中使用{{_.variable}}的复杂引用方式

影响范围

该问题影响以下场景：

• Windows 11操作系统环境
• Insomnia 11.0.0版本
• 同时使用查询参数界面和环境变量的情况
• 任何HTTP方法（GET/POST等）

值得注意的是，这个问题不会影响请求体(body)中的参数处理，仅限于查询字符串部分。

开发者建议

对于使用Insomnia进行API开发和测试的用户，建议：

1. 暂时采用URL直接附加查询参数的方式工作
2. 关注后续版本更新，该问题已被标记为与另一个已知问题相关
3. 在测试环境变量是否生效时，可以先不使用预请求脚本进行验证

这个问题展示了开发工具中参数处理流程的重要性，特别是在涉及多阶段预处理（环境变量替换、URL编码、脚本执行等）时，各阶段的处理顺序和条件判断需要格外注意。对于工具开发者而言，这也提醒我们需要对边界条件（如空脚本）进行更全面的测试。