读 /proc/1/cgroup 是最轻量可靠的方式，因其直接反映内核cgroup路径：宿主机通常为 / 或 /init.scope，而Docker容器含 /docker/、Kubernetes含 /kubepods/、LXC含 /lxc/ 等标识。
直接看 /proc/1/cgroup —— 这是最轻量、最可靠、不依赖外部命令的判断方式。
为什么读 /proc/1/cgroup 就能判断
容器进程 1（通常是 init 或 sh）的 cgroup 路径里必然包含容器标识符。宿主机上 /proc/1/cgroup 通常以 / 或 /system.slice 开头；而 Docker 容器中，它几乎总是含 /docker/、/kubepods/ 或 /lxc/ 等字样（取决于运行时）。这是内核暴露的底层事实，无需调用 docker 命令或查环境变量，也不受 LD_PRELOAD 干扰。
怎么在 C++ 里安全读取并判断
用标准 C 文件 API 打开 /proc/1/cgroup，逐行扫描是否匹配容器路径特征：
-
std::ifstream或fopen()都可以，但注意：文件可能不存在（极少见）、权限不足（罕见，但容器若以--read-only启动且挂载了/proc的子集，可能受限） - 只需检查任意一行是否含
"docker"、"kubepods"、"lxc"、"crio"或"podman"（大小写敏感，建议转小写后比对） - 不必解析完整层级，避免误判
/sys/fs/cgroup/docker/xxx这类伪路径（实际只存在于旧版 systemd + cgroup v1 组合） - 示例关键逻辑片段：
std::ifstream cgroup("/proc/1/cgroup");
std::string line;
bool in_container = false;
while (std::getline(cgroup, line)) {
std::string lower = line;
std::transform(lower.begin(), lower.end(), lower.begin(), ::tolower);
if (lower.find("docker") != std::string::npos ||
lower.find("kubepods") != std::string::npos ||
lower.find("lxc") != std::string::npos) {
in_container = true;
break;
}
}
其他方法为什么容易出错
这些常见替代方案在真实场景中常失效：
立即学习“C++免费学习笔记（深入）”；
-
getenv("container")：Docker 默认设该变量，但 Podman 不设，Kubernetes 可能被覆盖或清空，且容器启动时加--env container=就能伪造 -
stat("/.dockerenv", &st)：Docker 20.10+ 已弃用该文件，Alpine 镜像默认不生成，部分安全加固镜像会主动删除 - 执行
docker info或systemctl is-system-running：需要容器内装对应二进制、有权限、网络/套接字可达——CI 构建镜像里根本没装dockerCLI - 查
/proc/1/cmdline：宿主机 init 进程可能是systemd，容器里也可能是sh或bash，无区分度
边界情况必须留意
真正上线前要验证这三类场景：
- 使用 cgroup v2 的系统（如较新 Ubuntu/CentOS Stream）：
/proc/1/cgroup格式不同，但仍有0::/docker/...这类字段，正则匹配"/docker/"仍有效 - Rootless Docker/Podman：cgroup 路径会带
/user.slice/前缀，但后面仍保留/docker/xxx，不影响判断 - 嵌套容器（如 CI 中跑 Docker-in-Docker）：外层是宿主机，内层仍是容器，
/proc/1/cgroup显示的是当前容器的层级，结果依然准确
真正难处理的是那些刻意抹除 cgroup 特征的场景（比如某些 eBPF 安全沙箱），但那种环境已不属于标准 Docker 生态，常规检测本就不适用。
