正确做法是用 user.Current() 获取当前用户，而非 user.Lookup；user.Current() 在 Windows 不支持，user.LookupId 查 UID 失败常因 /etc/passwd 缺失或 UID 不存在，Uid/Gid 是字符串需安全转换，HomeDir 在容器中常为空应 fallback 到 $HOME 或外置配置。
Go 里用 user.Lookup 查当前用户经常返回空或 panic
因为 user.Lookup 默认查的是用户名（比如 "root"），不是当前进程用户；传空字符串或 "" 会直接 panic，传 os.Getenv("USER") 在容器或 systemd 服务里又常为空。
正确做法是先用 user.Current() 拿当前运行用户：
u, err := user.Current()
if err != nil {
log.Fatal(err)
}
fmt.Println("UID:", u.Uid)
fmt.Println("GID:", u.Gid)
fmt.Println("HomeDir:", u.HomeDir)
注意：user.Current() 依赖底层 getpwuid(getuid()) 调用，Linux/macOS 都行，但 Windows 不支持（会返回 user: Current not implemented on windows 错误）。
user.LookupId 查任意 UID/GID 时为什么总报 “user: unknown userid”
常见原因是目标 UID 在 /etc/passwd 里不存在——比如容器里只保留了 root，或用了 user namespace 映射后的 UID（宿主机上查不到）。
立即学习“go语言免费学习笔记（深入）”；
排查和处理建议：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 先确认 UID 确实存在：
getent passwd <uid></uid>（Linux）或dscl . -read /Users/<username> UniqueID</username>（macOS） -
user.LookupId只查本地/etc/passwd，不查 LDAP/NIS；如需集成目录服务，得自己调系统命令或用 cgo 封装 - 某些精简镜像（如
scratch、distroless）压根没/etc/passwd，此时user.LookupId必然失败，只能靠环境变量或启动参数传入必要信息
UID/GID 字符串转数字：别直接 strconv.Atoi(u.Uid)
user.User.Uid 和 Gid 是字符串类型，不是整数。虽然多数情况内容是数字，但标准 POSIX 允许它们是符号名（如 "nobody"），glibc 也支持这种写法。
所以安全转换方式是：
- 用
strconv.ParseUint(u.Uid, 10, 32)或64，并检查 error - 不要假设它一定是数字——尤其在跨平台或对接旧系统时，
Uid字段可能为"65534"（nobody）或"nogroup" - 如果只是日志或调试输出，直接用
u.Uid字符串即可，没必要强转
HomeDir 在容器或 rootless 环境里经常为空或错乱
user.HomeDir 来自 /etc/passwd 的第六字段，而很多容器镜像要么删了 /etc/passwd，要么只留 root 行（home 是 "/root"），导致非 root 用户查不到 home。
典型表现：u, _ := user.Current(); fmt.Println(u.HomeDir) 打印空字符串。
应对方式：
- 启动容器时显式挂载完整
/etc/passwd，或用--user指定 UID 同时确保对应条目存在 - fallback 到环境变量：
os.Getenv("HOME")在大多数 shell 启动场景下更可靠（但 rootless podman/docker 可能未设置） - 极端情况（如 init 容器、无 shell 环境），干脆不依赖 HomeDir，把路径逻辑外置配置
真正麻烦的不是拿不到值，而是不同来源（/etc/passwd、$HOME、NSS 模块）返回不一致——同一 UID 在宿主机和容器里可能指向完全不同路径。
