PHP用cURL发multipart/form-data最简写法是设CURLOPT_POSTFIELDS为含CURLFile的关联数组，cURL自动处理boundary和Content-Type；若仅字符串数组则发x-www-form-urlencoded，非multipart。
PHP 用 cURL 发送 multipart/form-data 请求最简写法
直接用 curl_setopt 设置 CURLOPT_POSTFIELDS 为关联数组，cURL 会自动拼成 multipart/form-data 格式并设置正确的 Content-Type（含 boundary）。不用手动构造字符串、不用调用 curl_file_create（除非要传文件）。
常见错误是把数组 JSON 化或 urlencode 后塞进去，结果服务端收不到字段——那发的是 application/json 或 application/x-www-form-urlencoded，不是表单数据。
- 字段值是字符串：直接写
['username' => 'admin'] - 上传文件：用
new CURLFile('/path/to/file.jpg')（PHP 5.5+），或旧版用'@/path/to/file.jpg'（已弃用，不推荐） - 避免显式设置
Content-Type头，否则会覆盖 cURL 自动加的带 boundary 的头
为什么 file_get_contents + stream_context_create 很难正确发 multipart
它不原生支持 multipart 编码，必须手写 boundary、拼接换行、转义二进制内容、计算长度——极易出错。比如少一个 \r\n、boundary 前后多空格、文件内容没按 RFC 2388 base64 或 binary 编码，服务端就解析失败，返回空数组或 400 错误。
实操建议：除非环境彻底禁用 cURL，否则别碰这个方案。真要用，优先选现成封装如 http_build_query（仅限普通字段）+ 手动补全 multipart 结构（极不推荐）。
立即学习“PHP免费学习笔记（深入）”；
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
curl_setopt($ch, CURLOPT_POST, true) 和 POSTFIELDS 的关系
CURLOPT_POST 只是告诉 cURL “走 POST 方法”，它本身不携带任何数据；真正决定请求体内容和编码方式的是 CURLOPT_POSTFIELDS 的值类型。
- 设为字符串 → 发
application/x-www-form-urlencoded - 设为关联数组且不含
CURLFile→ 发application/x-www-form-urlencoded（注意：不是 multipart！） - 设为关联数组且含
CURLFile或字符串值以@开头 → 自动切到multipart/form-data
所以关键不是开不开 CURLOPT_POST，而是 CURLOPT_POSTFIELDS 给什么。
调试时怎么确认发出去的是真正的 multipart/form-data
用 curl_setopt($ch, CURLOPT_VERBOSE, true) + fopen('php://output') 捕获详细日志，重点看两处：
- 请求头里是否有类似
Content-Type: multipart/form-data; boundary=------------------------a1b2c3d4e5f6 - 请求体是否以
--{boundary}开头，字段间有--{boundary}分隔，结尾是--{boundary}--
如果只看到 Content-Type: application/x-www-form-urlencoded，说明数组里没传 CURLFile，或者 PHP 版本太低不识别该对象，得降级用 @ 语法（但务必确认服务端兼容）。
边界符生成和二进制处理是黑盒，别试图自己模拟——cURL 做对了，你改错一点，服务端就收不到字段名。
