参数被环境变量或脚本动态覆盖，需检查双大括号变量引用及Pre-request Script中pm.request.url.query等操作；参数类型选错（如误设为File）须切回Text；History/Examples中请求为只读快照，应新建或导入到Collection编辑。
参数被环境变量或脚本动态覆盖，改了也白改
你手动在 Params 里改完值，一按 Send 就变回原样——大概率是参数绑定了环境变量（如 {{user_id}}）或被 Pre-request Script 覆盖了。
检查方法很直接：
- 看参数值是否带双大括号
{{xxx}}，有就说明是变量引用，得去Environment或Globals里改对应变量值 - 点开
Pre-request Script标签页，搜pm.request.url.query、pm.request.url.update、pm.environment.set这类调用，尤其是带.addQueryParams或.set的行 - 临时注释掉整段脚本再试一次，如果能改了，就确认是脚本干扰
别指望“先改参数再发请求”能绕过脚本逻辑——Postman 是先执行脚本、再拼 URL 的。
参数类型选错，根本点不进输入框
在 Params 选项卡里，某个参数右侧下拉菜单显示的是 File 或 Binary，那它就不是文本字段，没法直接输内容。这是常见误操作：把一个本该是 Text 的查询参数，不小心点成了文件上传类型。
解决办法只有一步：把那个参数右侧的下拉菜单切回 Text（或 x-www-form-urlencoded，取决于你用的参数位置）。
特别注意：
-
Query Params只能是Text类型，选File会直接禁用编辑 - 如果参数出现在
Body → form-data里，却想输纯文本，得确保该行的类型不是File，而是留空或选Text - URL 编码问题也会导致“看似可编辑但输不进”：比如值里含空格、中文、
&、=，Postman 会自动拦截，此时应手动 URL 编码（右键→Encode URI Component）或改用脚本处理
想批量改多个参数？别一个个点，用脚本一次到位
手动改 10 个参数太慢，且容易漏；用 Pre-request Script 批量操作更稳。核心是操作 pm.request.url.query 对象。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
常用写法：
- 删掉所有已有查询参数：
pm.request.url.query.clear() - 加一组新参数：
pm.request.url.addQueryParams([{key:"page",value:"1"},{key:"size",value:"20"}]) - 只更新某一个参数，不管它原来存不存在：
pm.request.url.query.upsert({key:"token",value:pm.environment.get("auth_token")}) - 条件性修改（比如只在测试环境加调试参数）：
if (pm.environment.name === "test") { pm.request.url.query.add("debug=true"); }
注意：addQueryParams 不会去重，重复调用会导致同一 key 出现多次；要用 upsert 或先 remove 再 add。
从 History 或 Example 加载的请求，参数是只读快照
你在 History 里双击一个旧请求，或者从 Examples 里加载示例，这时看到的参数其实是当时请求发出时的“快照”，不是活的编辑态。你改了没反应，是因为它压根没绑定到当前环境或变量，也不响应脚本。
正确做法只有两个：
- 新建请求（点
+），然后手动复制 URL 和参数，这样所有字段都是可编辑的 - 或者右键历史记录 →
Copy to Collection，把它真正导入到你的集合里，再编辑
别试图在 History 里硬改——那不是工作区，只是日志。
最常被忽略的一点：Postman 的参数编辑行为高度依赖上下文。同一个参数，在 Params 里改、在 Pre-request Script 里改、在 Environment 里改，生效时机和优先级完全不同。不厘清这三层关系，改十次也不对。
