我之前对接外部接口时也碰到过几乎一模一样的坑——命令行curl跑起来顺风顺水，一转到代码里就掉链子，对方能收到请求但死活拿不到内容。咱们从几个常见的排查方向入手：

1. 先搞清楚命令行curl的真实请求格式 #

首先给你的命令行curl加个-v参数，扒一扒它实际发送的请求细节：

curl -v -d @yourfile.txt https://external-source.com/api

重点盯两个核心点：

• Content-Type：-d默认是application/x-www-form-urlencoded，但如果用-F传文件就是multipart/form-data
• 数据编码逻辑：-d会自动把换行符转成%0A，但--data-binary会原样发送原始内容

代码里的请求必须和这个格式完全对齐，否则对方接口的解析逻辑直接就懵了。

2. 检查文件内容的读取是否靠谱 #

如果你的文件里有特殊字符（换行、引号、&、=这类），直接把读取到的字符串传给-d时，很可能因为编码或转义问题导致内容被截断、篡改：

• 文本文件要确保用正确编码（比如UTF-8）读取，别漏掉换行符这类细节
• 二进制文件一定要用二进制模式读取，避免文本模式下的编码转换把内容搞坏

举个Python反例（错误示范）：

# 错误：文本模式读二进制文件，没处理特殊字符
with open('data.bin', 'r') as f:
    content = f.read()
requests.post(url, data={'content': content})

正确写法参考：

# 二进制模式读取文件
with open('data.bin', 'rb') as f:
    content = f.read()
# 按接口期望设置Content-Type，比如原始二进制就设application/octet-stream
requests.post(url, data=content, headers={'Content-Type': 'application/octet-stream'})

3. 别搞混「传内容」和「传文件」的参数逻辑 #

很多时候我们会把“传递文件内容”和“上传文件对象”搞混：

• 命令行里-d @filename是把文件内容作为表单数据发送
• 而-F "file=@filename"是把文件作为multipart格式上传

如果对方接口是接收文件上传（而非纯文本内容），代码里就得用files参数而非data：

# 模拟curl -F "file=@yourfile.txt"的效果
requests.post(url, files={'file': open('yourfile.txt', 'rb')})

4. 试试用--data-binary替代-d #

-d参数会自动对内容做URL编码，有时候这会破坏原始内容的格式。如果命令行换成--data-binary @filename能正常工作，那代码里也得模拟这个行为——直接发送原始字节流，不做额外编码。

比如shell命令行的有效写法：

curl --data-binary @yourfile.txt https://external-source.com/api

对应Python的写法：

with open('yourfile.txt', 'rb') as f:
    requests.post(url, data=f)

终极排查：抓包对比请求差异 #

如果还是不行，用抓包工具（Wireshark、Charles都行）把命令行和代码发送的请求抓下来对比，重点看：

• 请求头的Content-Type是否完全一致
• 请求体的内容有没有额外转义、截断或格式差异

内容的提问来源于stack exchange，提问作者jamesp