最可靠的方式是检查 /proc/1/cgroup 和 /proc/1/environ：前者匹配 docker/lxc/crio/kubepods 等关键词，后者解析 \0 分隔的 container= 字段；二者均失败时可 fallback 至 /proc/mounts 检查 overlay 等文件系统，需容忍权限限制或缺失。
直接检测程序是否运行在 Docker 容器中，最可靠的方式是检查 /proc/1/cgroup 和 /proc/1/environ 的内容，而不是依赖环境变量（如 container）——后者容易被伪造或缺失。
读取 /proc/1/cgroup 判断容器环境
宿主机的 PID 1 是 systemd 或 init，而容器内 PID 1 通常是你的应用进程或 sh，其 cgroup 路径会暴露容器特征。Docker 容器中该文件通常包含 docker-、lxc、kubepods 或 crio- 等关键词。
实操建议：
- 用 C++ 打开并读取
/proc/1/cgroup文件（注意：必须以只读方式打开，且需处理文件不存在或权限拒绝的情况） - 逐行扫描是否匹配正则
.*(?:docker|lxc|crio|kubepods).*；简单场景可用std::string::find()查找子串"docker" - 若文件不可读（如某些 Alpine 镜像或 rootless 容器），不要直接报错退出，应 fallback 到下一检查项
- 注意：Linux 5.16+ 引入了
unifiedcgroup v2 模式，此时路径可能为/proc/1/cgroup中第一行为0::/，需额外检查/proc/1/mountinfo中是否挂载了overlay或overlay2
检查 /proc/1/environ 是否含 container 标识
Docker 启动时默认会在 PID 1 进程的环境块中注入 container=lxc 或 container=docker（取决于底层 runtime）。但该字段不是强制写入，部分镜像（如 distroless 或自定义构建）会缺失。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 读取
/proc/1/environ时需按\0分隔解析，不能当普通文本用std::getline() - 推荐用
std::vector<char></char>一次性读入全部内容，再遍历每个\0分隔的字符串，查找是否以"container="开头 - 若读取失败（常见于非特权容器或 seccomp 限制），跳过此项，不作为唯一依据
- 该方法在 Podman、LXC 等环境中也可能返回
lxc，不能单凭此区分 Docker 和其他容器引擎
验证 /proc/sys/kernel/osrelease 或 /etc/os-release 不够可靠
有些文章建议查 /etc/os-release 中的 PRETTY_NAME 是否含 “Docker”，但这只是镜像作者写的描述，完全可被修改；/proc/sys/kernel/osrelease 返回的是内核版本，与是否容器无关。
为什么不用它们：
-
/etc/os-release在 scratch 镜像中根本不存在 - Alpine、Ubuntu、CentOS 镜像都可能用于裸机或容器，无法反推运行时环境
- 内核版本号（如
6.8.0-xx-generic）在宿主机和容器中完全一致，无区分度 - 依赖这些会误判——比如在 WSL2 中运行 Docker，
/etc/os-release显示的是 WSL 的发行版，而非容器本身
综合判断逻辑要容忍降级和缺失
没有单一文件能 100% 确定 Docker 环境，尤其是面对 distroless、rootless、gVisor、Kata 等特殊运行时。正确做法是组合多个信号，并允许部分失效。
推荐 C++ 检测顺序：
- 先尝试读
/proc/1/cgroup，命中关键词即返回true - 再读
/proc/1/environ，找到container=docker或类似值，也返回true - 若两者均失败，检查
/proc/mounts中是否存在overlay、overlay2、zfs等容器常用 fs 类型（需逐行解析） - 最后 fallback 到检查
/proc/1/cmdline是否为常见容器 init（如sh、bash、sleep），仅作辅助提示，不作为判定依据
真正容易被忽略的是：容器内程序可能被 exec -it 进入后手动修改 /proc 下文件权限，或运行在 seccomp profile 严格限制的环境里——此时所有 /proc 读取都会失败。这种情况下，检测本身已无意义，应由上层调度系统（如 Kubernetes）通过 downward API 注入标识。
