curl --max-filesize 0 仍下载完整文件

想限制下载量，把命令写成 curl --max-filesize 0 URL，结果仍然接收正文，甚至下载了完整文件。这里的 0 是特殊值：它关闭文件大小限制，不表示“最多下载零字节”。

下面针对 curl 命令行的 HTTP/HTTPS 下载。先分清两个目标：只查看响应头，和下载一个不超过指定大小的文件。它们对应不同的请求及处理方式。

非零大小才是下载上限

先查看实际运行的版本，特别是脚本、容器与交互终端可能使用不同的 curl：

curl --version

需要下载但限制文件大小时，使用业务允许的非零上限。例如，在 Unix 类系统的专用测试目录中：

curl --max-filesize 1048576 --max-time 30 \
  --output ./download.part \
  'https://files.example.com/sample.bin'

URL 和输出路径是占位示例，1048576 表示 1 MiB；download.part 应是新建、允许被写入的位置，不能指向已有业务文件。示例直接写整数，避免单位或小数解析的版本差异。--max-time 30 限制传输时间，不会代替大小限制。

当 curl 预先知道响应文件超过上限时，会拒绝开始下载并返回 63。若已经写入部分正文后才触及限制，输出可能是不完整文件。脚本必须检查退出状态，不能只因文件存在就交给后续解压、安装或导入。

--max-filesize 不等于限制传输速率，也不等于整个网络连接最多使用这些字节。HTTP 头部、协议开销和已经到达的网络数据，不能据此算作严格的带宽预算。

没有 Content-Length 时还要核对版本

curl 8.4.0 之前，如果传输前不知道文件大小，这个选项不能在下载过程中阻止文件超过上限。服务器未提供可用长度、按流发送数据时，设置了非零值也不能据此保证文件受限。

从 8.4.0 起，curl 可以在传输过程中达到大小阈值时中止。因此，需要处理未知长度响应的脚本，应使用具有这项能力的版本，并在异常退出时保留失败状态。不能仅对一个带有准确 Content-Length 的小文件测试成功，就认为未知长度场景也安全。

自动解压还有单独边界：从 8.20.0 起，--compressed 自动解压后的数据达到阈值时也会中止。使用更早版本时，不要把下载大小限制直接当成解压后大小保护。若应用接收不可信压缩包，还需要在解包工具和后续处理层限制资源；传输限制不替代解包安全检查。

这些版本条件不能通过把上限设为 0 绕过。0 在这里仍然表示取消限制。

只看响应头时使用 HEAD

目标接口支持 HEAD，且你只需要检查响应头时，可以写：

curl --head --max-time 15 \
  'https://files.example.com/sample.bin'

这会发送 HEAD，而不是靠一个“零大小文件限制”模拟它。HEAD 响应不包含资源正文，但状态码、认证要求或服务器实现可能与 GET 不同；返回 405 时不能把上限改回 0 当作修复。

若服务拒绝 HEAD，而业务必须发送 GET，应按接口约定设计探测方式，并明确可能接收正文。将正文输出到 /dev/null 只是不保存文件，并不阻止下载；把大小设为 1 也只是设置极小的文件上限，不能保证得到一个正常成功的“仅头部请求”。

不要用是否打印到了终端来推断网络上是否传输了正文。输出去向、请求方法和传输限额是三个不同的设置。

检查失败路径，再把临时文件交给下游

在获准的测试端点分别核对小于上限、已知长度超过上限和未知长度超过上限的响应。前者应得到完整文件；后两者在适用版本下应被限制，并给出非零退出状态。若开启自动解压，再单独核对解压后大小场景。

测试时只使用可丢弃的输出位置，保存 curl 的状态码和错误文字；HTTP 错误、连接失败与大小超限不能合并成“下载成功但文件为空”。进入下游之前，还要按原业务流程验证文件内容或校验值。

修改前保留脚本中的旧参数。回退不能简单设为 0 并声称保护仍在：那会恢复无限制下载。若暂时无法满足大小约束，应停止把这份下载结果用于后续任务，保留原有已验证制品，而不是接受部分文件继续执行。