os.getpid()返回当前进程pid，os.getppid()返回父进程pid；前者在所有平台准确可靠，后者在unix-like系统返回真实ppid，在windows上恒为0，不可用于跨平台父子关系判断。
os.Getpid 和 os.Getppid 返回什么值
os.Getpid() 返回当前进程的 PID（整数），os.Getppid() 返回其父进程的 PID。两者都定义在 os 包中，无需额外导入，调用开销极低，且在所有主流操作系统（Linux/macOS/Windows）上行为一致。
注意：os.Getppid() 在 Windows 上实际返回 0 —— 这不是 bug，而是 Go 运行时的限制：Windows API 不提供标准方式获取父 PID，Go 选择返回 0 而非 panic 或错误。如果你在 Windows 上依赖父 PID 做逻辑判断，必须提前处理这个边界值。
基本用法与常见误用
直接调用即可，不需要参数，也不涉及 error：
package main
import (
"fmt"
"os"
)
func main() {
fmt.Printf("PID: %d\n", os.Getpid())
fmt.Printf("PPID: %d\n", os.Getppid())
}
容易踩的坑：
- 误以为
os.Getppid()在所有平台都可靠 —— 实际上它在 Windows 上恒为0，不能用于跨平台父子进程关系校验 - 在 fork 后未及时调用 —— 比如用
syscall.ForkExec创建子进程后，子进程里调用os.Getppid()得到的是原父进程 PID（只要没被 init 接管），但若父进程已退出，该值可能不可靠 - 把返回值当字符串或指针用 —— 它们是
int类型，直接参与数值比较或日志输出即可，无需转换
结合 exec.Command 的真实场景验证
想确认子进程是否真的继承了预期的父 PID？可以启动一个 shell 子进程并读取 /proc/$PID/status（Linux）或 ps 输出（macOS）：
例如，在 Linux 下验证：
cmd := exec.Command("sh", "-c", "echo $$; echo $PPID")
out, _ := cmd.Output()
// 输出形如：12345\n67890\n → 第一行是子 shell 的 PID，第二行是它的 PPID
此时你自己的程序 PID 应与第二行一致（除非被 init 接管）。但注意：exec.Command 默认不设置 SysProcAttr.Setpgid，所以子进程和父进程通常同属一个进程组，PPID 关系可观察。
关键点：
-
os.Getpid()总是准确反映当前 Go 进程 ID -
os.Getppid()只在 Unix-like 系统上有意义；Windows 用户应改用其他机制（如环境变量传参、命名管道或文件锁）来显式传递父进程上下文 - 不要在信号 handler（如
os.Signal）中假设os.Getppid()仍有效 —— 如果父进程已退出，内核可能已将其重置为 1（init）或 0（Windows）
为什么不能用它们做进程存活判断
有人试图用 os.Getppid() 是否等于 1 来判断“父进程是否已挂”——这不可靠。原因包括：
- 在容器环境中，init 进程不一定是 PID 1（如使用
tini或docker-init） - Linux 的
prctl(PR_SET_CHILD_SUBREAPER, 1)可让非 PID 1 进程接管孤儿进程，此时 PPID 不会变成 1 - 即使 PPID == 1，也不能反推父进程刚死 —— 它可能本来就是由 init 直接拉起的
真正需要检测父进程状态时，推荐用 kill(0) 向 PPID 发送空信号（需捕获 syscall.ESRCH 错误），或者更稳妥地：由父进程主动创建并维护一个 socket 或文件锁，子进程定期检查其有效性。
PPID 是瞬时快照，不是通信信道。拿它当控制依据，往往比想象中脆弱得多。
