最可靠的方式是读取/proc/1/cgroup并逐行匹配:/docker/、:/kubepods/等标识，因其由内核生成不可伪造，覆盖Docker/K8s/containerd等主流运行时；而/.dockerenv等方法仅可辅助验证，无法单独依赖。
最可靠的方式是读取 /proc/1/cgroup 并匹配关键词，其他方法（如检查 /.dockerenv 或环境变量）只能辅助，不能单独依赖。
为什么优先读 /proc/1/cgroup
容器中 PID 1 进程的 cgroup 路径直接由内核生成，无法伪造，且 Docker、Kubernetes（kubepods）、containerd（containers）、CRI-O（crio）都会在路径中写入对应标识。宿主机上该文件通常以 / 或 /init.scope 开头，不包含这些子串。
常见错误现象：只检查文件是否存在（stat("/proc/1/cgroup", &st) 成功就返回 true），但没读内容——有些精简镜像（如 distroless）或 rootless 容器会挂载空 /proc，文件存在却无有效数据。
- 必须逐行读取并搜索子串，不是判断文件是否存在
- 匹配目标应为
:/docker/、:/kubepods/、:/containers/、:/crio/、:/lxc/（注意开头的:和中间的/） - Linux 5.16+ 启用 cgroup v2 时，
/proc/1/cgroup首行可能是0::/，此时需 fallback 到检查/proc/1/mountinfo中是否含overlay或overlay2
如何安全读取 /proc/1/cgroup 并解析
用 std::ifstream 打开后，要处理三类异常情况：文件不存在（errno == ENOENT）、权限拒绝（EACCES）、只读挂载下部分字段不可读（极少见但 Alpine + --read-only 可能触发）。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 使用
std::getline()逐行读取，避免整文件加载导致缓冲区溢出 - 对每行做小写转换后再查找，避免大小写敏感漏判（例如某些 runtime 写
Docker） - 发现任意一行含目标子串即可返回
true，无需遍历全部 - 若
open失败或首行读取即 EOF，直接跳过，进入下一检测项
示例关键逻辑：
在 Linux 上通过 Docker 运行 OpenClaw，并使用 Tailscale 实现远程访问。⚠️ 涉及 sudo、Docker、Tailscale和凭证挂载——请先查阅安全章节...
std::ifstream f("/proc/1/cgroup");
std::string line;
while (std::getline(f, 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(":/containers/") != std::string::npos) {
return true;
}
}
为什么不能只靠 /.dockerenv
/.dockerenv 是 Docker daemon 启动容器时写入的空文件，但 Kubernetes 默认不创建它，Podman、containerd、LXC 等运行时也不写；部分安全加固镜像（如 Google distroless）会主动删除它。
实操建议：
- 仅作为快速辅助：用
stat()检查存在性（access()在只读挂载下可能误报） - 若
stat()成功，可增强置信度；但失败完全不能否定容器环境 - 绝不可在
/.dockerenv不存在时直接返回false
补充验证：检查 /proc/1/environ 中的 container= 字段
Docker 和 LXC 会在 PID 1 的环境块中注入 container=lxc 或 container=docker，但该字段非强制，distroless 镜像、自定义 entrypoint 或 seccomp 限制都可能导致读取失败。
实操要点：
- 必须用
std::vector<char></char>一次性读入全部内容，再按\0分割解析 - 不能用
std::getline()，否则会把\0当换行符截断 - 只匹配以
"container="开头的完整键值对，避免误命中其他含container的变量名 - 读取失败（
errno == EPERM或ENODEV）时静默跳过，不抛异常
这个字段在 Podman 中也可能返回 lxc，所以它不能区分 Docker 和其他容器引擎，仅作交叉验证用。
cgroup 路径解析看似简单，但实际要覆盖 cgroup v1/v2、rootless、seccomp、只读挂载、distroless 等多种边缘场景，单点判断极易失效。真正健壮的实现必须组合多个信号，并按可靠性排序：先 /proc/1/cgroup，再 /proc/1/environ，最后 fallback 到 /.dockerenv 或 /proc/sys/kernel/osrelease 写失败等行为特征。
