集成第三方 API

我准备把一份接口定义导入到一个低代码平台，它可能是一份 OpenAPI 文档，也可能是一条 cURL 命令。
这个平台的导入器只支持这两种格式各自的一个子集，一旦出现它不支持的写法，导入就会失败，
而且平台不会告诉我具体是哪里出了问题。
 
请你把自己当作这个导入器，先判断我给的是 OpenAPI 文档还是 cURL 命令，
然后只按下面对应的那一节规则，对我的内容完整走查一遍，
判断它能否被导入，如果不能，指出具体是哪一处、以及应该怎么改。
 
我会把 OpenAPI 文件（.json 或 .yaml）作为附件上传，或者把 OpenAPI 内容、cURL 命令
粘贴在这条消息后面。如果我还没有提供，请先向我索要，不要凭空推测。
 
# 第一部分：导入 OpenAPI 文档时适用的规则
 
请只依据这里的描述判断，不要依据 OpenAPI 官方规范判断。
 
这个导入器并不是标准的 OpenAPI 解析器，它只支持规范中的一个子集。
它会依次遍历 paths、每个 operation、参数、requestBody 和 responses，
整个过程中没有任何错误捕获，因此只要有一处出错，整份文档就会导入失败，一个接口都不会进来。
 
## 会导致整份导入失败的情况
 
以下任意一条被命中，所有接口都导不进来。按导入器的实际执行顺序排列，越靠前的越先被触发：
 
- 文件不是合法的 JSON 或 YAML。平台只接受 .json 和 .yaml 两种后缀，.yml 无法上传。
- 文档中出现了 head、options 或 trace 操作，哪怕只有一个。
- in: query、in: path 或 in: header 的参数缺少 schema 节点。常见于用 content: 描述的参数、
  Swagger 2 风格的 "- name: x, in: query, type: string"，以及参数整体引用
  "#/components/parameters/..." 的写法。
- 上述参数的 schema.type 不是 string、integer、number 或 boolean 之一。
  数组型的 query 参数（type: array）是最常见的原因，其次是 type: object，
  以及只写了 $ref、allOf、enum 或 example 而没有写 type 的参数。
- 文档缺少 info，或者 info.title 为空。这一步在最后执行，前面都通过了才会暴露出来。
- 文档实际上是 Swagger 2.0，即包含 swagger: "2.0"、definitions、in: body 或 host/basePath。
  导入器不会提示版本不支持，通常表现为参数缺少 schema 而崩溃，或者导入成功却一个接口都没有。
 
in: cookie 的参数会被安全地忽略，不会导致失败。
 
## 不会报错，但会静默丢失内容的限制
 
- 请求体和响应体的 Content-Type 只支持 application/json、application/x-www-form-urlencoded
  和 multipart/form-data。对于 POST、PUT、PATCH 接口，如果一个受支持的类型都没有，
  这个接口会被完全跳过，而且不会有任何提示。
- 同一个 operation 如果写了多个受支持的 Content-Type，会被拆成多个重复的 API。
- $ref 只支持 "#/components/schemas/XXX" 这一种写法。外部文件引用、"#/definitions/"，
  以及指向 "#/components/responses"、"parameters"、"requestBodies" 的引用都无法解析。
- schema 必须显式写出 type，否则该属性会被丢弃；type: array 还必须提供 items。
- allOf、oneOf、anyOf 只有一个子 schema 时会被正常展开，
  但有两个或更多子 schema 时会整体退化成 JSON 数据，对象结构全部丢失。
- additionalProperties 不会展开；GET 和 DELETE 上的 requestBody 会被忽略；
  path item 级别的公共 parameters 不会被合并，必须写进每个 operation 内部。
- securitySchemes 和 security 完全不处理，enum、nullable、pattern、最大最小值等约束一律忽略。
- API 名称取自 summary，不使用 operationId；summary 为空时会自动拼成 "方法_路径_ContentType"。
- servers[].url 中的变量会用 server variable 的 default 替换，
  如果某个变量没有写 default，url 会原样保留花括号，导入后无法调用。
- 默认值只保留标量类型。multipart/form-data 中的文件字段需要同时满足 type: string 和
  format: binary，并在 encoding 的 contentType 中声明 image/* 或 video/*，
  才会被识别为图片或视频。
 
# 第二部分：导入 cURL 命令时适用的规则
 
请只依据这里的描述判断，不要依据 curl 的实际行为判断。
 
导入器不会真的执行这条命令，它只是把命令拆成参数，从中取出请求地址、方法、请求头和请求体，
生成一个 API 配置。整个过程同样没有错误捕获，只要有一处不支持，整条命令就导不进来。
 
## 只有这些选项会被读取
 
- -X 和 --request 决定请求方法。没有写时，带请求体的命令按 POST 处理，否则按 GET 处理。
- -H 和 --header 是请求头，可以重复出现，每个都会变成一个请求头参数。
- -d、--data、--data-raw、--data-binary 和 --data-ascii 是请求体。
- --data-urlencode 是表单请求体，可以重复出现，多个值会用 & 连接起来，
  并且会强制把请求当作 application/x-www-form-urlencoded 处理。
- -F 和 --form 是 multipart 表单字段，可以重复出现。
- --url 用来指定请求地址，适用于命令里没有直接写出地址的情况。
 
-F 和 --data-urlencode 会把紧随其后的参数当成自己的取值，所以请求地址不能紧跟在它们
后面，否则地址会被吞掉，导入报 "url cannot be null" 失败。判断时看的是地址前面紧挨着
的那个选项，而不是地址在不在命令末尾：curl -F 'a=1' https://x -F 'b=2' 同样会失败。
把地址写在这些选项之前，或者用 --url 显式指定，都不会有这个问题。
其余选项写在地址前后都可以。
 
上面没列到的选项一律被静默丢弃，不影响导入，例如 -u、--user、-b、--cookie、-L、
--location、--compressed、-k、-o、--max-time、--retry。取值本身是地址的选项会连同
取值一起丢弃，不会被误当成请求地址，例如 -x、--proxy、--referer、--resolve、
--connect-to、-T、--upload-file。所以命令里的基本认证和 Cookie 都不会变成 API 配置。
 
## 会导致导入失败的情况
 
- 命令里完全没有可以当作请求地址的参数，导入报 "url cannot be null"。
  最常见的原因是地址被写在它前面的 -F 或 --data-urlencode 吞掉了。
  注意：地址写成 ftp://、ws:// 或省略协议的 api.example.com 并不会失败，
  它们会导入成一个不可用的地址，属于第三类问题。
- 请求方法是 HEAD 或 OPTIONS。
- -X 的值不是 GET、POST、PUT、PATCH、DELETE 之一，例如写成某个自定义动词。
  大小写不影响，写成小写的 post 可以正常导入。
- 命令用 -d 带请求体，但 content-type 请求头声明的类型不是 application/json、
  application/x-www-form-urlencoded、multipart/form-data 三者之一。
  命令里有 -F 时这个请求头不参与判断，写成 text/plain 也不会失败。
- 按 application/json 处理时，-d 的内容不是合法的 JSON。
  没有写 content-type 请求头时就是按 application/json 处理，所以
  -d 'grant_type=client_credentials' 这种表单写法会在这里失败，
  需要补上 -H 'content-type: application/x-www-form-urlencoded'。
  -d @payload.json 这种从文件读取请求体的写法也会失败，因为文件名会被当作请求体本身。
- 表单请求体（URL 编码或 --data-urlencode）里出现孤立的百分号。
  每个键和值都会做一次 URL 解码，-d 'discount=50%' 会报
  "Incomplete trailing escape (%) pattern"，需要写成 discount=50%25。
 
## 不会报错，但会静默丢失内容的限制
 
- 同时写了多个请求体选项时，按 -d、--data-raw、--data-binary、--data-ascii 的顺序
  取第一个出现的，与书写顺序无关；都用 -d 时取第一个。
- -d 和 --data-urlencode 同时出现时，--data-urlencode 会整体覆盖 -d 的请求体。
- 只要命令里有 -F，-d 的请求体就会被完全丢弃。
- 地址写成 ftp://、ws:// 或省略协议的形式不会报错，但会导入成不可用的地址：
  ftp://a.com/f 变成 ftp://a.com，api.example.com 变成字符串 null://null。
- URL 中的路径会被固定在地址里，不会变成可绑定的 Path 参数。
- 同名的 Query 参数只保留最后一个，Query 参数的顺序也可能发生变化。
- GET 和 DELETE 不携带请求体，这两种方法上的 -d 会被丢弃。
- 同名的 -F 字段只保留最后一个，而 URL 编码请求体中的同名字段会各自保留。
- URL 解码会把表单请求体里的 + 变成空格，要保留加号必须写成 %2B。
- -F 的值只能是文本或文件，即使写的是一段 JSON，也只会作为字符串保留，不会展开成对象。
- Query、请求头和文本表单字段一律生成为可选的字符串类型，命令里的取值成为它们的默认值。
- -F 中写成 name=@文件路径 的字段是例外，它会按文件扩展名识别为图片、视频或通用文件，
  并且是必填且未绑定的，导入后必须手工绑定取值。
- cURL 命令里没有响应信息，导入只会生成请求配置，响应结构需要导入后测试一次才能得到。
 
# 输出要求
 
能用表格表达的内容一律用表格，不要写成大段文字，不要寒暄，也不要在结尾加总结段。全文控制在 25 行以内。
 
一、结论：先说明我给的是 OpenAPI 文档还是 cURL 命令，
再用一句话说清楚是「会导入失败，原因是……」还是「可以导入，但会丢失……」。
 
二、必须修改的问题：把命中对应那一节「会导致导入失败」的地方全部列出来。
只列第一个是不够的，我改完之后还会再次失败。
表格包含五列：位置、行号、违反的限制、具体问题、修改方法。
位置一列，OpenAPI 文档写成 paths./users.get.parameters[1] 这样的路径，
cURL 命令写成「-X 后面的取值」这样的描述，行号一列在 cURL 只有一行时填「-」。
 
如果一条都没有命中，请写明「未发现会导致失败的问题」。
对于 OpenAPI 文档，再按文件后缀不对、上传中断、文档是 Swagger 2.0、
存在上述规则未覆盖的写法这个顺序推测原因，用表格呈现，包含可疑点、判断理由和验证方法三列。
 
三、建议修改的问题：从对应那一节「不会报错但会丢失内容」的限制中挑出真正影响可用性的，
最多五行，琐碎的不必提。表格包含五列：位置、违反的限制、会丢失什么、修改方法、是否必须改。
 
四、安全提醒：如果内容里带有 Authorization、Cookie、api-key 之类的真实凭证，
请单独提醒我这些取值会被原样写进配置，并建议改用平台的 Secret 绑定。
如果没有，这一节不要输出。
 
# 注意事项
 
- 只依据上面描述的导入器行为判断。一份完全符合 OpenAPI 3.0 规范的文档、
  一条在终端里能跑通的 curl 命令，同样可能失败，
  例如文档只是多带了一个 head 操作，或者命令的表单请求体里有一个孤立的百分号。
- 不要在输出中用编号或代号指代限制条目，比如「规则 A4」「第三条」这类写法。
  「违反的限制」一列要用一句我能直接看懂的话说明该限制本身是什么。
- 语言要流畅、清晰，像一位同事在向我解释问题，而不是罗列关键词。
  每个单元格都要是完整、通顺的句子，避免使用箭头、省略号和缩写。
- 「修改方法」一列要写成我可以直接照做的一句话，写明具体的字段名或选项名和目标值。
- 如果命令里有 $'...' 片段，请说明它有多长，并提醒我这种写法本身就不可靠，
  建议无论长短都改成普通单引号。不要给出一个精确的字符数阈值，它并不存在。
- 如果某种写法在这个导入器里根本无法表达（例如数组型的 query 参数），
  就直接说明需要导入后在平台里手工添加，不要编造会改变接口语义的替代写法。
- 用中文回答。