必须用exec.command.extrafiles传递fd，因其是go标准库唯一跨平台支持的文件描述符继承机制；环境变量仅传整数，子进程无法凭空复用fd，必须真实继承句柄，否则触发bad file descriptor或address already in use。
Go 中文件描述符（FD）传递给子进程，不是靠“复制”或“序列化”，而是靠操作系统内核的 fork/exec 机制天然继承 + Go 标准库的显式封装。只要父进程把 *os.File 放进 Cmd.ExtraFiles，子进程就能在 fd=3 起拿到它 —— 但错一个数字、漏一次校验，net.FileListener 就会返回 invalid argument，监听器直接失效。
为什么 ExtraFiles 必须从 fd=3 开始数
Unix-like 系统中，子进程默认继承父进程的 fd 0（stdin）、1（stdout）、2（stderr）。Cmd.ExtraFiles 里传入的 []*os.File 切片，会在子进程中按顺序绑定为 fd=3、fd=4、fd=5…… 不能跳号，也不能重复。
- 父进程调用
l.File()得到一个新*os.File，它和原net.Listener共享底层 socket，但 fd 号是内核新分配的（比如 12）；这个*os.File必须放进ExtraFiles切片，不能直接传 fd 数字 - 子进程用
os.NewFile(3, "")拿到它 —— 这里的3是继承后的编号，不是原始 fd；若误写成os.NewFile(5, "")，而实际继承的是第 1 个 extra file（即 fd=3），就会失败 - Windows 不支持
ExtraFiles，该方案仅限 Unix/Linux/macOS；跨平台需求需另寻方案（如 unix domain socket 传递）
net.FileListener 失败的三个典型原因
net.FileListener(os.NewFile(3, "")) 成功 ≠ 监听器可用。它只做类型转换，不校验地址、状态或权限。常见挂掉点：
-
invalid argument：传入的 fd 不指向 socket，或不是 listening 状态（比如父进程已Close()了原 listener） - 端口漂移：
listener.Addr()返回的地址和预期不符（如变成:0或127.0.0.1:8080而非:8080），说明 socket 继承异常，必须panic，不能静默继续 - SO_REUSEADDR 未启用：父进程 listener 创建时没设
SO_REUSEADDR，子进程尝试 bind 同一地址会报address already in use—— 但用FileListener重建时不会 bind，所以此 flag 实际影响的是父进程是否能持续 accept，而非子进程启动
监听器重建后必须做的地址比对
子进程拿到 net.Listener 后，第一件事不是 Accept()，而是确认它真正在监听目标地址。这是最容易被跳过的一步，也是线上静默故障主因。
- 原始监听地址应由父进程通过命令行参数或环境变量传入，例如
os.Args[1] == ":8080" - 重建 listener 后立即执行：
if l.Addr().String() != expectedAddr {<br> panic(fmt.Sprintf("listener addr mismatch: got %v, want %s", l.Addr(), expectedAddr))<br>} - 不要依赖
l.Addr().Network()做模糊匹配；tcp和tcp4在某些系统下被视为不同网络类型，会导致误判
FD 传递本身很轻量，真正复杂的是状态一致性：父进程何时关闭原 listener、子进程何时接管 accept、信号如何协调生命周期 —— 这些不在 ExtraFiles 覆盖范围内，得靠上层协议（如 goagain 的 double-exec）或自定义信号约定来兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
