一个进程退出后，另一个进程监听了这个进程所有的端口，这是为什么-Go服务器开发

这是一个非常经典且重要的系统行为，背后涉及操作系统内核处理网络资源的机制。简单来说，这不是一个“错误”或“意外”，而是设计如此。

核心原因在于：TCP/UDP 套接字是独立于进程的系统级资源。

下面我将分点详细解释为什么会出现这种情况，以及其背后的机制。

进程与套接字的分离
- 当一个进程创建一个套接字并绑定（bind）到一个端口后，这个套接字就不再完全属于该进程了。
- 它更准确的身份是一个由操作系统内核管理、并被该进程引用的资源。进程通过一个文件描述符 (File Descriptor) 来引用这个内核中的套接字对象。
进程退出时发生了什么？
- 当进程退出（无论是正常退出还是被杀死）时，它的所有文件描述符都会被内核自动关闭。
- 但是，“关闭文件描述符”并不总是等同于“立即释放端口”。
- 对于 TCP 套接字，如果它有过连接（即处于 ESTABLISHED 状态），它会进入一个叫做 TIME_WAIT 的状态。在这个状态下，这个（IP地址+端口）的组合会被保留一段时间（通常是 2*MSL，默认约 60秒），以防止旧的重复数据包干扰新的连接。这是 TCP 协议为了保证可靠性所规定的。
- 更重要的是，如果套接字在创建时设置了 SO_REUSEADDR 选项，那么规则就完全不同了。

这是导致你观察到的现象的最常见、最直接的原因。

作用：允许多个套接字绑定到同一个 IP地址:端口号组合，只要之前绑定的套接字已经承诺会这样做（通过设置 SO_REUSEADDR）。
工作原理：
1. 第一个进程（服务器）启动，在创建套接字后、绑定（bind）端口前，调用了 setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, ...)。
2. 该进程成功绑定端口并开始监听。
3. 该进程退出后，由于 SO_REUSEADDR 的存在，内核会允许另一个新的套接字（来自第二个进程）立即重新绑定到同一个端口上，即使之前的连接还处于 TIME_WAIT 状态也会被强行覆盖。
为什么需要它？ 这对于服务器程序至关重要。如果没有这个选项，服务器崩溃或重启后，可能需要等待几分钟（TIME_WAIT超时）才能重新启动并监听同一个端口，这显然是无法接受的。设置了 SO_REUSEADDR 后，服务器几乎可以立即重启。

所以，你的第二个进程很可能也设置了 SO_REUSEADDR 选项，从而能够立刻接管第一个进程的端口。

虽然 SO_REUSEADDR 是最常见的，但还有其他几种可能性：

父子进程继承 (Fork/Exec)
- 如果第二个进程是第一个进程通过 fork() + exec() 方式产生的子进程，那么子进程可能会继承父进程中已经打开的文件描述符列表，包括那个已经监听的套接字。父进程退出后，子进程中继承的套接字依然有效并在监听。
文件描述符传递 (SCM_RIGHTS)
- 这是一种更高级的 IPC（进程间通信）机制。一个进程可以将一个打开的文件描述符（包括网络套接字）通过 Unix Domain Socket 发送给另一个完全不相关的进程。之后，即使原始进程退出，接收方进程也完全拥有这个套接字的所有权。
守护管理器或 Systemd Socket Activation
- 在一些现代系统中（如使用 systemd），端口的监听是由系统管理器（如 systemd)本身完成的。当有连接到来时，systemd 才会启动真正的服务进程并将已连接的套接字传递给它们。
- 在这种情况下，“监听端口”的始终是 systemd，你的服务进程只是处理具体连接。因此你的服务进程无论重启多少次，“监听端口”的这个行为看起来都没有变化。

你可以使用以下命令来查看端口的真实所有者：

# 查看监听端口的进程PID和名称
sudo ss -tulnp | grep :<你的端口号>

# 或者使用 lsof
sudo lsof -i :<你的端口号>

输出结果会明确显示当前是哪个 PID 的哪个进程在监听该端口。你会发现第二个进程的 PID 已经替代了第一个。