Postman导入cURL后请求方法变GET，主因是缺失或错位的-X POST；Cookie头与-b参数重复导致401；-F被误识为raw而非form-data；JSON双引号未转义引发解析错误。
Postman导入cURL后请求方法变成GET而不是POST
Postman把本该是 POST 的请求自动识别成 GET，最常见原因是 cURL 命令里 -X POST 缺失、位置错误，或被 Postman 解析器忽略。它不看 --data 或 -d 是否存在，只严格依赖显式声明的 -X 选项。
实操建议：
- 检查原始 cURL 是否含
-X POST，且必须出现在 URL 之前；若只有--data没有-X，Postman 默认用GET - Windows 下从 Chrome 复制的
curl (cmd)常漏掉-X，改用Copy as cURL (bash)更可靠 - 如果用了
--data-raw，Postman 有时会降级为GET，换成-d或显式加-X POST - 导入后手动点开 Postman 请求右上角「Method」下拉框，确认是否真为
POST；别只信请求体区域有数据就以为方法对了
Header里的Cookie和-b参数冲突导致401
Chrome 复制的 cURL 常同时带 -b "key=value" 和 -H "Cookie: key=value"，Postman 导入后会把两者都塞进请求头，造成 Cookie 字段重复，后端校验失败返回 401 Unauthorized。
实操建议：
- 导入前手动删掉 cURL 中的
-b参数，只保留-H "Cookie: ..."（Postman 对后者兼容性更好） - 若必须保留
-b，删掉所有-H "Cookie: ..."行，避免双写 - 导入后在 Postman 的
Headers标签页里检查是否有两个Cookie行——这是最直接的确认方式 - 遇到登录态失效类问题，优先怀疑这个冲突，比查 token 过期还快
导入后Body类型变成raw但实际需要form-data
Chrome 复制的 -F "key=value" 在 Postman 里常被识别为 raw 文本，而非 form-data，导致后端收不到 req.files 或 req.body 为空。
Postman 12.27.7
下载
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
实操建议：
- 不要依赖自动导入识别
-F；导入后手动切到 Postman 的Body→form-data，再逐条填入字段 - 若字段含文件（如
-F "file=@/path/to/a.jpg"），Postman 不会自动读取本地路径，需点击对应字段右侧的File开关并手动选择 -
-F中的filename=xxx和content-type=xxx会被 Postman 忽略，必须在界面上补全 - 调试时可在 Postman 的
Code标签页点「JavaScript - Fetch」，对比生成的代码里FormData.append()是否完整
JSON数据里双引号没转义导致arg.startsWith is not a function
这个报错不是网络层错误，而是 Postman 内部解析 cURL 时 JS 引擎崩溃，根源是 --data-raw 或 -d 后的 JSON 字符串用了未转义的双引号，尤其在 Windows cmd 环境下更易触发。
实操建议：
- 把
-d '{"name":"Alice"}'改成-d "{\"name\":\"Alice\"}"（双引号内嵌双引号需转义） - 或干脆换用单引号包裹整个 JSON：
-d '{"name":"Alice"}'—— 但仅限 Linux/macOS；Windows 下必须用双引号包裹且内部转义 - 更稳妥的做法：删掉整段
-d，导入后在 Postman 的Body→raw→JSON中重新粘贴格式化 JSON，让 Postman 自己处理编码 - 注意：Postman 的「Import → Raw Text」对引号容错极低，一个错位引号就能让整个解析失败，不报具体行号，只能靠肉眼扫
真实场景里，这些点往往叠加出现——比如你修好了请求方法，却因 Cookie 冲突拿不到响应；调通了 form-data，又卡在 JSON 转义上。关键不是一次全改对，而是每次只动一个变量，导入后立刻验证 Method + Headers + Body Type + Body 内容四项是否与预期一致。
