os.getenv读不到环境变量主因是启动方式导致环境未继承：终端直接执行可读export变量，nohup/systemd需显式配置，ide需勾选继承选项。
os.Getenv 读不到环境变量？检查 shell 启动方式和作用域
Go 程序里调用 os.Getenv 返回空字符串，大概率不是 Go 的问题，而是环境变量根本没传进来。Linux/macOS 下，shell 启动方式直接影响子进程能否继承变量：
- 终端直接执行
./myapp：能读到当前 shell 中export过的变量 - 用
nohup ./myapp &或 systemd 启动：默认不继承用户 shell 的环境，得显式设置（比如 systemd 的Environment=KEY=VAL） - IDE（如 Goland）运行：看 IDE 的「Run Configuration」里是否勾选了「Include system environment variables」
调试时别只查 Go 代码——先在终端跑 env | grep KEY，确认变量真存在且拼写大小写一致（PATH 和 path 是两个变量）。
os.StartProcess 启动失败常见报错与绕过方案
os.StartProcess 比 exec.Command 更底层，也更容易踩坑。最常遇到的是 exec: "xxx": executable file not found in $PATH，但这往往不是 PATH 问题：
- 传入的
argv[0]必须是完整可执行路径，不能只写命令名（os.StartProcess("/bin/ls", []string{"ls", "-l"}, ...)会失败；得写[]string{"/bin/ls", "-l"}） - 如果目标程序依赖动态库，而 Go 进程没加载对应
LD_LIBRARY_PATH，子进程也会静默崩溃（用strace -f ./myapp可捕获execve调用失败细节） - Windows 上注意路径分隔符：必须用
，且需转义或使用 raw string（`C:\Program Files\xxx\app.exe`）
除非需要精细控制文件描述符继承或 setpgid，否则优先用 exec.Command——它自动处理 PATH 查找和参数封装。
立即学习“go语言免费学习笔记（深入）”；
os.Chmod 改不了 Linux 文件权限？关注 umask 和父目录 sticky bit
os.Chmod 返回 nil 不代表权限真改成功了。常见失效场景：
- 调用者不是文件所有者，且没有 root 权限：普通用户无法给他人文件加
SUID或改属组为非自己所属组 - 父目录设置了 sticky bit（
drwxrwxrwt）且你不是文件所有者：即使有写权限，也不能改其他人的文件权限（典型于/tmp） - 挂载选项含
noexec或nosuid：某些 FUSE 或容器卷会忽略 chmod 请求（stat -c "%a %n" file可验证实际结果）
注意：os.Chmod 的 mode 参数是权限位掩码（如 0644），不是八进制字面量——Go 里写 644 是十进制六百四十四，得写 0644（开头 0 表示八进制）。
os.Getpid / os.FindProcess 在容器里返回值异常的原因
容器中 os.Getpid() 总是返回 1？os.FindProcess(1).Signal(syscall.Signal(0)) 却报 process already finished？这是 PID namespace 隔离导致的：
- 容器内 PID 1 是你的主进程，但宿主机上它可能是个普通数字（如 12345）。
os.Getpid返回的是 namespace 内视角的 PID -
os.FindProcess创建的是对「当前 namespace 中 PID」的引用，若跨 namespace 查找（比如在宿主机查容器内 PID 1），必然失败 - 想获取宿主机真实 PID？得读
/proc/self/status解析NSpid:行，或通过 cgroup 路径反查（如/proc/12345/cgroup）
别依赖 PID 数值做逻辑判断——尤其在 k8s 环境下，PID 是临时的、不可预测的，用进程名或健康检查端口更可靠。
