文件与媒体输入、输出及生命周期

小白：四种输入方式

URL 适合已在对象存储中的文件；Base64 或 data URL 适合小型一次性输入；multipart 适合音频转写和图像编辑等文件表单；厂商原生 Files API 适合上游明确支持的复用上传。本站 /v1/files 当前返回未实现，因此不能先上传再假定所有模型都能引用文件 ID。

Copycurl "$BASE_URL/v1/audio/transcriptions"   -H "Authorization: Bearer $API_KEY"   -F "model=<MODEL_ID>"   -F "file=@sample.mp3"

请求前在模型广场核对音频端点，并以实际协议要求的字段、MIME 和格式为准。

支持矩阵应由端点决定

聊天视觉可能接受远程 URL 或 data URL，图像编辑通常需要 multipart 或参考图字段，音频转写使用 multipart，视频生成可能接受图片 URL 或厂商资产 ID。不要把一种端点成功的 file_id、URL 或字段复制到另一种协议。Base64 会增加体积，也会扩大日志和内存风险。

URL 输入的安全边界

服务端抓取 URL 前应只允许 HTTPS，解析 DNS 后阻止环回、私网、链路本地和云元数据地址，并在每次重定向后重新校验。限制重定向次数、连接/读取超时、响应大小和 Content-Type；MIME 头不能代替魔数检查。不要把带凭证的内网 URL 直接交给第三方模型厂商。

上传与内存

网关和客户端应流式读取 multipart，设置总请求体与单文件上限，并尽早拒绝不支持的格式。不要一次载入大视频；临时文件要使用不可猜名称、最小权限和确定清理。日志只记录大小、摘要、MIME 和对象 ID，不记录完整 Base64 或签名 URL。

结果与生命周期

同步结果可能是 Base64 或短期 URL；异步任务还可能返回二进制结果信封。先验证状态、类型、长度与摘要，再流式写入自有对象存储。保存业务副本后再认为交付完成；对 expired 或 410 不应无限重试原下载地址。

专家治理

建立输入数据分级、允许格式、病毒扫描、图像解码炸弹防护、租户目录隔离和删除传播。记录上游厂商、区域、保留政策、任务 ID 和结果删除时间。容量规划同时考虑网络带宽、临时磁盘、对象存储、并发连接与 Base64 膨胀，而不仅是请求数量。