Java NIO不直接支持HTTP协议，需手动解析报文、管理连接、构建响应；核心是用Selector驱动非阻塞读写，通过状态机处理请求边界（如空行、Content-Length），并分阶段处理OP_READ/OP_WRITE，避免阻塞和粘包。
Java NIO 本身不直接提供 HTTP 协议支持，它只负责底层的非阻塞 I/O（如 Channel、Buffer、Selector），所以用 NIO 实现 HTTP 服务器，本质是「自己解析 HTTP 报文 + 管理连接生命周期 + 构建响应」。这不是调用一个库就能跑起来的服务，而是需要手动处理请求行、请求头、消息体、状态码、Content-Length 或 Transfer-Encoding 等细节。
核心思路：用 Selector 驱动非阻塞读写
HTTP 是基于 TCP 的应用层协议，NIO 实现 HTTP 服务器的关键在于：
- 创建 ServerSocketChannel 并配置为非阻塞，注册到 Selector 上监听 OP_ACCEPT
- 接受连接后，将新建立的 SocketChannel 也设为非阻塞，并注册 OP_READ（后续可能还要注册 OP_WRITE）
- 在事件循环中轮询就绪通道：对可读通道，读取字节 → 缓存 → 尝试解析完整 HTTP 请求；对可写通道，发送响应后取消 OP_WRITE 注册
- 每个连接需维护自己的读缓冲区（如 ByteBuffer 或 byte[]），因为一次 read() 可能只读到部分请求（比如大 POST 分多次到达）
关键难点：HTTP 请求解析不能假定“一次读完”
NIO 是流式读取，而 HTTP 请求有明确边界（空行分隔 headers 和 body，Content-Length 或 chunked 编码决定 body 长度）。你必须自己做状态机解析：
- 先识别起始行（GET /path HTTP/1.1），再逐行读 header，直到遇到 "\r\n\r\n"
- 根据 Content-Length 或 Transfer-Encoding: chunked 判断是否还有 body，以及何时收齐
- 建议用 ByteBuffer.flip()/compact() 管理读缓冲区，或用更易操作的 ArrayList<Byte> 临时累积（小流量场景可接受）
- 不要用 String.split("\r\n") 直接切——可能跨 read() 边界，导致解析失败
响应构建与写回要避免阻塞和粘包
写响应时不能直接 channel.write(buffer)，因为 write() 可能未写完（返回值小于 buffer.remaining()），需注册 OP_WRITE 并等待下次就绪：
立即学习“Java免费学习笔记（深入）”；
- 构造标准响应：状态行（HTTP/1.1 200 OK）、必要 header（Date, Server, Content-Type, Content-Length）、空行、响应体
- 把整个响应序列化为 ByteBuffer（注意编码，如 UTF-8），注册 OP_WRITE 后在 selector 循环中 write()
- write() 返回值为实际写出字节数，若未写完，保持 buffer position/limit 不变，继续监听 OP_WRITE；写完后取消该兴趣集，关闭连接或等待下个请求（支持 keep-alive 时需检查 Connection: keep-alive）
- 别忘了设置 SocketChannel 的 SO_LINGER（可选）或及时 close() 释放资源
实用建议：从最小可行版开始迭代
别一上来就支持 HTTPS、chunked、multipart、长连接复用。先跑通最简 GET：
- 只处理 GET 请求，忽略所有 header（除了 Host，用于虚拟主机）
- 响应固定字符串（如 "HTTP/1.1 200 OK\r\nContent-Length: 12\r\n\r\nHello World!"）
- 每个连接只处理一个请求，响应后立即 close()（简化状态管理）
- 加日志打印 client IP、请求路径、响应耗时，验证 selector 是否真并发处理多个连接
- 之后逐步加：静态文件服务、URL 路由、POST body 解析、keep-alive 支持
不复杂但容易忽略：NIO 写 HTTP 服务器不是为了替代 Tomcat，而是理解网络编程本质。真要上线，推荐用 Netty 或 Undertow —— 它们已把 NIO + HTTP + 编解码 + 线程模型封装得足够健壮。自己手撸适合学习，不适合生产。
