os.getenv读不到环境变量通常因shell启动方式和作用域导致；os.startprocess需绝对路径、正确argv[0]及执行权限；容器中os.getpid返回命名空间内pid；os.chdir影响整个进程而非goroutine。
os.Getenv 读不到环境变量？检查 shell 启动方式和作用域
Go 程序里调用 os.Getenv("PATH") 返回空字符串，大概率不是代码写错了，而是环境变量根本没传进来。比如你在 IDE 里直接点运行，或用 go run main.go 启动，进程继承的是 IDE 或终端启动时的环境快照——而你刚在终端里 export FOO=bar，那个变量只对当前 shell 及其子 shell 有效，IDE 进程通常不感知。
- 验证方法：在程序开头加
fmt.Println(os.Environ())，看输出里有没有你要的变量 - 开发时临时生效：用
Foo=bar go run main.go（Linux/macOS）或set FOO=bar && go run main.go（Windows cmd） - 注意
os.Setenv只影响当前进程及后续 fork 出的子进程，不会反向写回父 shell - 如果依赖系统级环境（如 systemd 服务），得在 service 文件里显式配置
Environment=或EnvironmentFile=
os.StartProcess 启动子进程失败：权限、路径、参数三连坑
os.StartProcess 是底层接口，比 exec.Command 更“裸”，出错时错误信息往往很模糊，比如 fork/exec /bin/ls: no such file or directory —— 实际可能是路径不存在、缺少执行权限，甚至 argv[0] 写错了。
- 必须传绝对路径：
/bin/ls可以，ls不行（它不查$PATH） -
argv第一个元素（argv[0]）建议和可执行文件路径一致，否则某些程序（如 Python 解释器）会误判脚本位置 - 确保目标文件有执行权限（
chmod +x），尤其在容器或 NFS 挂载卷里容易被 strip 掉 x 权限 - 如果要捕获 stdout/stderr，记得在
syscall.SysProcAttr里设置Setpgid: true和重定向 fd，否则默认继承父进程的 stdio
os.Getpid / os.Getppid 在容器里返回的不是你想象的“进程号”
在 Docker 或 Kubernetes 里跑 Go 程序，os.Getpid() 返回的是容器命名空间内的 PID（通常是 1 或小数字），不是宿主机上的真实 PID；os.Getppid() 同理，它返回的是容器内 init 进程（如 tini 或 sh）的 PID，不是宿主机上 dockerd 的 PID。
- 想查宿主机 PID？得进容器的
/proc/1/status看NSpid字段，或者从宿主机执行docker inspect -f '{{.State.Pid}}' <container></container> - 别用
os.Getpid()做唯一标识符：容器重启后 PID 重置，且不同容器可能拿到相同 PID - 信号发送（
syscall.Kill）也受命名空间限制：只能发给同 namespace 内的进程，跨容器 kill 会报permission denied
os.Chdir 影响整个进程，不是 goroutine 局部的
os.Chdir 修改的是进程级别的当前工作目录（cwd），所有 goroutine 共享同一个 cwd。这不是线程安全问题，而是设计如此——Go 没有为每个 goroutine 维护独立的工作目录。
立即学习“go语言免费学习笔记（深入）”；
- 常见误用：在 HTTP handler 里
os.Chdir("/tmp")，以为只影响当前请求，结果其他并发请求也跟着切到了/tmp - 替代方案：用绝对路径拼接，比如
filepath.Join("/data", filename)；或者用os.OpenFile时传入完整路径，避免依赖 cwd - 如果真要临时切换（比如跑某个外部命令要求特定 cwd），务必用
defer os.Chdir(oldwd)回滚，且注意 panic 场景下是否能执行到 defer
环境变量和进程管理看似基础，但一旦混入容器、IDE、systemd、信号处理这些上下文，行为就很容易偏离直觉。最常被忽略的是：Go 的 os 包不做任何抽象封装，它就是 syscall 的薄包装，你看到的每一个函数，背后都直连操作系统语义。
