Rust HTTP服务器读取TCPStream时如何避免线程阻塞？

先拆解你遇到的几个核心问题根源：

• 去掉take_while后线程挂起：BufReader::lines()会一直等待换行符才返回结果，但HTTP请求体不一定以换行结尾，再加上客户端可能开启Keep-Alive，发完请求体后不会立刻关闭TCP连接，导致代码一直阻塞在读取操作上。
• unwrap触发错误：Firefox刷新页面时可能会中断之前的连接，此时读取流会返回IO错误，unwrap遇到错误直接panic，必须显式处理这些错误，不能无脑用unwrap。

要正确读取带请求体的HTTP请求，得遵循HTTP规范来实现——从请求头里获取请求体长度，精准读取对应字节数，不用读取整个流。下面是具体思路和代码示例：

步骤1：读取请求头并解析Content-Length #

保留请求头读取逻辑，但替换unwrap为错误处理：

use std::io::{BufRead, BufReader, Read, TcpStream};
use std::str::FromStr;

fn handle_connection(mut stream: TcpStream) {
    let mut buf_reader = BufReader::new(&mut stream);
    let mut headers = Vec::new();
    let mut content_length = 0;

    // 循环读取请求头，直到遇到空行
    loop {
        let mut line = String::new();
        match buf_reader.read_line(&mut line) {
            Ok(0) => break, // 连接已关闭
            Ok(_) => {
                let trimmed_line = line.trim_end(); // 移除换行符
                if trimmed_line.is_empty() {
                    break; // 请求头结束
                }
                headers.push(trimmed_line.to_string());
                // 提取Content-Length字段值
                if let Some(len_str) = trimmed_line.strip_prefix("Content-Length: ") {
                    if let Ok(len) = usize::from_str(len_str) {
                        content_length = len;
                    }
                }
            }
            Err(e) => {
                eprintln!("读取请求头失败: {}", e);
                return;
            }
        }
    }

    // 步骤2：读取指定长度的请求体
    let mut body = vec![0; content_length];
    if content_length > 0 {
        match buf_reader.read_exact(&mut body) {
            Ok(_) => {
                // 按需处理请求体，比如转成字符串
                let body_str = String::from_utf8_lossy(&body);
                println!("请求体内容: {}", body_str);
            }
            Err(e) => {
                eprintln!("读取请求体失败: {}", e);
                return;
            }
        }
    }

    // 后续可添加请求处理、响应返回逻辑...
}

额外注意事项 #

• 分块编码支持：如果请求头里是Transfer-Encoding: chunked，上述Content-Length方法不适用，需要按分块规则读取（每个块开头是十六进制长度，后跟内容，最后以0长度块结束）。学习阶段可以先只支持Content-Length场景，后续再扩展分块逻辑。
• 错误处理优先：所有IO操作都可能失败（客户端断开、网络异常等），必须用match或if let处理错误，避免程序panic。
• 非阻塞模式的复杂度：非阻塞模式确实能避免挂起，但需要处理WouldBlock错误，配合epoll或select监听流的可读事件，逻辑复杂度较高。对于新手来说，先掌握基于Content-Length的阻塞读取更贴合HTTP基本流程，更容易理解。

内容的提问来源于stack exchange，提问作者CodeCraft