必须用exec.Command.ExtraFiles传递FD，因其是Go标准库唯一跨平台支持的文件描述符继承机制；环境变量仅传整数，子进程无法凭空复用fd，必须真实继承句柄，否则触发bad file descriptor或address already in use。
Go 服务平滑升级中，文件描述符（FD）传递不是“可选优化”，而是零停机的唯一可行路径；不走 FD 传递，就只能接受 address already in use 或连接中断。
为什么必须用 exec.Command.ExtraFiles 而不是环境变量传 fd 数字
环境变量（如 LISTEN_FD=3）只传了个整数，但子进程无法凭空复用该 fd——它必须真实继承该文件描述符句柄。Linux 内核不允许进程直接打开另一个进程的 fd 编号，除非该 fd 已通过 SCM_RIGHTS（Unix 域套接字）或 ExtraFiles 显式继承。
-
ExtraFiles是标准库唯一跨平台支持的 FD 继承机制：在 Unix 系统上底层调用fork+execve并设置fd标志，在 Windows 上模拟等效行为 - 若改用
os.Getenv("LISTEN_FD")+os.OpenFile，会触发权限错误或bad file descriptor，因为 fd 3 在子进程中根本不存在 - fd 编号从 3 开始是约定：0/1/2 固定为 stdin/stdout/stderr，
ExtraFiles[0]对应子进程的 fd=3，ExtraFiles[1]对应 fd=4，以此类推
net.FileListener 恢复监听器时最常踩的三个坑
子进程拿到 fd 后调用 net.FileListener(os.NewFile(3, "")) 看似简单，但实际极易失败：
- 没检查
listener.Addr()：恢复后的 listener 可能绑定到随机端口（比如:0），需显式比对l.Addr().String()和原始地址，不一致则 panic - 忽略
TCPListener类型断言：不是所有net.Listener都有File()方法，net.UnixListener也支持，但http.Server默认的net.Listen("tcp", ...)返回的是*net.TCPListener，必须类型断言后调用 - 忘记关闭父进程的
*os.File：父进程调用l.(*net.TCPListener).File()返回的是新复制的 fd，必须defer file.Close()，否则子进程继承后，父进程退出时内核不会释放 socket
为什么 tableflip 不是银弹，而只是封装了关键路径
tableflip 把 ExtraFiles 传递、Unix socket 控制通道、父子进程握手（Ready()/Exit()）打包成易用 API，但它不解决业务层资源延续问题：
- 它不自动接管数据库连接池、Redis client、gRPC 连接——这些仍需你在
upg.Upgrade()后手动重建或迁移 - 它默认只管理监听器 FD，如果你还开了日志文件、metrics socket、pidfile 等，得自己调用
upg.Fds.Add()注册 - 它依赖
SIGUSR2触发升级，但在容器中若进程被 shell 包裹（如/bin/sh -c "./app"），信号会被拦截，此时tableflip的Upgrade()将永远阻塞
真正容易被忽略的，从来不是怎么把 fd 传过去，而是传过去之后——子进程是否真的用上了它，以及父进程是否在所有活跃请求结束后才彻底释放资源。一个没关干净的 *sql.DB 或残留的 http.Client.Transport 连接池，会让新进程悄悄继承旧状态，直到某次超时或 EOF 才暴露问题。
