控制HTTP分块传输需手动按RFC7230构造Transfer-Encoding: chunked流：响应头仅设Transfer-Encoding: chunked且禁用Content-Length；每块为“十六进制长度+CRLF+数据+CRLF”；终结块必须为0\r\n\r\n。
要控制 HTTP 分块传输行为，关键在于正确构造 Transfer-Encoding: chunked 响应流的结构与节奏，而非“配置”某个开关。C 语言中没有现成的 chunked 封装库，必须手动按 RFC7230 规范拼接每一块数据。
明确响应头启用分块模式
发送响应前，必须设置且仅设置 Transfer-Encoding: chunked，同时**不能出现 Content-Length 字段**。二者互斥，违反会导致客户端解析失败。
- 正确示例：
HTTP/1.1 200 OK\r\nTransfer-Encoding: chunked\r\nContent-Type: text/event-stream\r\n\r\n - 错误做法：在 chunked 响应中写入
Content-Length: 123，多数客户端会忽略 chunked 或直接断连
按规范格式逐块构造并发送
每个块由三部分严格组成：十六进制长度行 + CRLF + 数据内容 + CRLF。长度值为纯十六进制（无前缀、无空格），表示后续字节数，不包含换行符本身。
- 发送 "Hi" → 长度为 2 → 写入
2\r\nHi\r\n - 发送空数据块（如心跳）→ 长度为 0 → 写入
0\r\n\r\n（注意是两个\r\n） - 避免常见错误：用十进制写长度、漏掉任一
\r\n、在数据中混入额外换行
控制分块节奏与大小以适配场景
分块大小没有强制限制，但实际行为由你决定：
- 日志流或 SSE：每条消息单独成块（如一行 JSON），保证低延迟可见性
- 大文件传输：可固定为 8KB 或 64KB 块，平衡系统调用开销与内存占用
- 动态生成内容：边生成边发送，块大小随处理单元变化（如一个数据库记录一个块）
结束传输必须显式发送终结块
客户端依赖 0\r\n\r\n 判断流结束。不发送或发送错误（如只发 0\r\n）会导致连接挂起、超时或解析卡死。
- 终结块必须独立发送，不可合并到上一块末尾
- 若需追加 trailer（报尾头字段），应在
0\r\n\r\n后发送，格式为Trailer: X-Hash\r\nX-Hash: abc123\r\n\r\n，但大多数客户端不支持或忽略
