这个问题其实挺典型的，我当初刚接触epoll的时候也踩过类似的坑，咱们一步步说清楚～

首先，当客户端调用socket.close()时，会给服务器发送一个FIN包，告诉服务器“我这边不再发数据了”。这时候服务器端的socket会进入半关闭状态，而epoll同时触发EPOLLIN和EPOLLHUP两个事件，本质是因为这两个事件的触发逻辑是从不同维度设计的：

• EPOLLIN的触发条件是“socket读操作就绪”，而当socket读端收到EOF（也就是客户端发了FIN）时，调用read()会直接返回0，不会阻塞，这完全符合“读就绪”的定义，所以epoll会触发EPOLLIN；
• EPOLLHUP则是专门用来通知“连接已经挂断/终止”的状态变化，当客户端主动关闭连接时，这个状态变化自然会触发该事件。

你觉得它们“看起来意思一样”，其实是因为在客户端正常关闭的场景下，这两个状态刚好同时出现，但它们的本质是不同的：EPOLLIN是告诉你“现在可以去读了”，而EPOLLHUP是告诉你“连接本身出了状况”。

接下来聊聊你关心的事件处理逻辑问题——确实，直接按顺序写if判断可能会踩坑，但完全不用纠结“覆盖所有组合”，更不用用==去匹配固定的事件组合（这种方式太脆弱，因为epoll还可能同时触发其他事件）。正确的做法是理解每个事件的含义，针对性处理：

比如可以这样写：

import select

def handle_epoll_event(conn, event):
    if event & select.EPOLLIN:
        data = conn.recv(1024)
        if not data:
            # 读到空字节，说明客户端已经断开连接
            print("客户端断开连接")
            conn.close()
            return  # 直接返回，避免重复处理后续事件
        # 正常处理收到的数据
        print(f"收到数据：{data.decode()}")
    if event & select.EPOLLHUP:
        # 这里也可以处理连接挂断，但上面已经处理过的话，这里可以做兜底
        print("连接挂断")
        if not conn._closed:
            conn.close()
    if event & select.EPOLLOUT:
        # 处理写就绪逻辑，比如发送缓存的数据
        pass

核心思路是：当EPOLLIN触发时，先去读数据，如果读到空字节，就明确是客户端断开了，直接关闭连接并返回，后续的EPOLLHUP处理就不会重复执行；如果没读到空字节，就正常处理业务数据。而EPOLLHUP可以作为兜底，处理一些异常断开的场景（比如客户端没发FIN就直接断网了）。

总之，epoll同时触发这两个事件是设计逻辑导致的，不是bug。只要你理解每个事件的触发原因，用位与（&）来判断事件是否存在，再结合读操作的返回值来判断连接状态，就能写出健壮的处理逻辑。

备注：内容来源于stack exchange，提问作者user28464084