os.open 在容器中读不到宿主机 /proc/1/cgroup 是因为容器默认处于独立的 pid、mount 和 cgroup 命名空间，/proc/1/cgroup 指向的是容器内 pid 1 的 cgroup 而非宿主机；需挂载宿主机 /proc（如 -v /proc:/host_proc）并读取 /host_proc/1/cgroup 才能获取宿主机信息。
为什么 os.Open 在容器里读不到宿主机的 /proc/1/cgroup
因为 Go 程序运行在容器中时，默认处于独立的 PID、mount、cgroup 命名空间下，/proc/1/cgroup 指向的是容器 init 进程（PID 1）的 cgroup 路径，不是宿主机的。直接读这个路径只会看到容器自身的资源限制信息。
常见错误现象：open /proc/1/cgroup: no such file or directory 或内容为空/与预期不符——其实是路径存在，但内容属于容器命名空间。
- 若需读宿主机 cgroup，必须挂载宿主机
/proc（如docker run -v /proc:/host_proc），再读/host_proc/1/cgroup - 不要依赖
os.Getpid()去拼路径，容器内 PID 1 不等于宿主机 PID 1 - 注意挂载传播（
sharedvsslave），某些容器运行时（如 containerd）默认 mount namespace 是 private，挂载宿主机/proc后可能看不到动态变化的进程信息
用 filepath.Join 拼接命名空间路径时容易忽略的挂载点偏移
Linux 命名空间中的文件路径是相对于该命名空间的 rootfs 和挂载视图的。比如容器中 /sys/fs/cgroup/memory 可能实际映射到宿主机的 /var/lib/docker/overlay2/xxx/merged/sys/fs/cgroup/memory，但更常见的是通过 bind mount 直接暴露宿主机子目录。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 永远优先检查
/proc/self/mountinfo，它比/proc/mounts更准确，能告诉你每个挂载点的源路径和 propagation 标志 - 避免硬编码
/sys/fs/cgroup/xxx，改用os.Readlink("/proc/self/ns/mnt")判断是否在独立 mount namespace 中 - 如果要读容器自身 cgroup v2 统计，路径通常是
/sys/fs/cgroup/<code>cgroup.procs所在目录的子路径，需先解析/proc/self/cgroup获取当前 cgroup 相对路径
ioutil.ReadFile（或 os.ReadFile）在 procfs 上可能阻塞或返回不完整内容
/proc 下多数文件是虚拟文件系统实现的，读取行为不遵循普通文件语义：有些文件只在 open 时生成快照，有些则每次 read 都触发内核计算；部分文件（如 /proc/[pid]/stack）在进程活跃时可能被截断或返回 EAGAIN。
典型问题：
- 读
/proc/1/environ时遇到空字节（\x00）导致字符串解析失败——Go 的ReadFile返回原始字节，不会自动按\x00分割 - 读
/proc/cpuinfo在某些内核版本下返回不完整（尤其在高并发容器中），因 procfs 实现使用 per-CPU 缓冲区 - 没有设置读取超时，遇到卡住的 proc 文件（如某些调试接口）会导致 goroutine 永久阻塞
建议用带 context 的方式读，例如：
ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
defer cancel()
data, err := os.ReadFile("/proc/1/cgroup")
if errors.Is(err, os.ErrDeadlineExceeded) {
// 处理超时
}
容器内读 /proc/[pid]/fd/ 需警惕文件描述符生命周期错位
在容器中调用 os.ReadDir("/proc/1/fd")，看到的 fd 列表反映的是容器 init 进程打开的文件——但这些 fd 可能指向已被删除的文件（deleted 标记）、socket 对端已关闭的连接，或挂载在其他命名空间的文件系统路径。
关键细节：
-
/proc/[pid]/fd/[n]的 symlink 目标路径是相对于该进程的 root（即容器 rootfs），不是宿主机 root；若容器用了--rootfs或 chroot，符号链接可能失效 - 读 fd 符号链接时，内核会做权限检查；若容器未启用
CAP_SYS_ADMIN，部分 fd（如指向/dev/mem）会返回permission denied，即使路径可读 - 不要假设
fd/0一定是 stdin：容器 runtime 可能重定向为管道或/dev/null，需结合/proc/[pid]/status的CapBnd和NSpid字段交叉验证命名空间归属
真正麻烦的是跨命名空间追踪：一个 fd 指向的文件，在宿主机上可能根本不在同一挂载点，甚至路径都不存在——这时候得靠 /proc/[pid]/mountinfo + statfs 系统调用反查设备号和 inode，而不是拼路径。
