从 RFC:
这使得 动态生成 要转移的内容...
换句话说。Transfer-Encoding: chunked 是需要当 内容长短不详.
你的内容长度可能大到10Tb... 但也可能小到10字节。这并不重要。卡盘的大小完全取决于你使用的算法。产生 并进行读取。
比方说，你生成了一个不同长度的消息流，每秒一个字符。在这种情况下，你可以决定向客户端发送一个字节的分块。这样客户端就能在数据到达后立即使用它。但是如果你的客户端对部分消息没有使用，那么你可能应该节省带宽，在你完成生成下一个消息的时候发送一个块。同样，消息的大小也不重要。可以是2个字符，也可以是1000个。
转念一想，有一些用例可以用在 Transfer-Encoding: chunked 与已知大小的数据。但是你的问题就变得很宽泛，无法回答。这取决于你的客户端代码，服务器代码，网络条件，数据属性，所需的用户体验等等。
如果你想从网络的角度询问最佳大小，那么只需发送 整 文件 - 这是最好的选择。并支持 Content-Range 在您的服务器上，而不是 Transfer-Encoding: chunked.