最可靠的方式是读取/proc/1/cgroup文件并扫描docker、kubepods、lxc等关键词，因其直接反映内核cgroup事实；失败后依次fallback至/proc/1/environ（解析container=字段）和/.dockerenv文件，三者均不可读才判定为非容器环境。
读 /proc/1/cgroup 是最可靠判断依据
直接读取 /proc/1/cgroup 文件并扫描关键词，是当前最轻量、最不易被绕过的方式。它不依赖外部命令、不查环境变量、也不受 LD_PRELOAD 干扰，本质是读内核暴露的 cgroup 路径事实。
宿主机上该文件首行通常是 / 或 /init.scope；Docker 容器中几乎必含 docker、docker-、containerd 等子串（cgroup v2 下也常见 io.containerd.）；Kubernetes 则多见 kubepods；LXC/Podman 对应 lxc 或 podman。
- 用
std::ifstream或fopen()以只读方式打开，必须处理FileNotFoundError和PermissionError（如 rootless 容器或 seccomp 限制） - 逐行读取，对每行转小写后用
std::string::find()查找"docker"、"kubepods"、"lxc"、"crio"、"containerd"、"podman" - 不必解析完整层级，避免误判
/sys/fs/cgroup/docker/xxx这类伪路径（仅旧版 systemd + cgroup v1 组合存在） - Linux 5.16+ 的 unified cgroup v2 模式下，
/proc/1/cgroup首行可能是0::/，此时需 fallback 到/proc/1/mountinfo查 overlay/overlay2 挂载
/proc/1/environ 中的 container= 字段可作辅助验证
Docker 默认会在 PID 1 进程的环境块中注入 container=docker 或 container=lxc，但该字段非强制写入——distroless 镜像、自定义构建或某些 Podman 场景可能缺失，不能单独作为判定依据。
读取时必须按 <p>读取时必须按 <code>\0 分隔解析，不能当普通文本用 std::getline() 处理，否则会截断或乱码。
std::getline() 处理，否则会截断或乱码。
立即学习“C++免费学习笔记（深入）”；
- 推荐用
std::vector<char></char>一次性读入全部内容，再遍历每个\0分隔的字符串 - 查找是否以
"container="开头，然后比对值是否为"docker"（注意大小写） - 若读取失败（权限拒绝或文件不可见），直接跳过，不中断主逻辑
- 该字段在 LXC/Podman 中也可能返回
lxc，无法单凭此区分 Docker 和其他运行时
/.dockerenv 文件存在性仅作快速兜底
/.dockerenv 是 Docker daemon 创建容器时写入的空文件，存在即强提示 Docker 环境，但它不是内核级事实：Podman、Kubernetes、自定义镜像或某些安全加固配置下该文件可能不存在或被删除。
- 用
access("/.dockerenv", F_OK)或std::filesystem::exists()（C++17）检查即可，开销极低 - 仅建议放在
/proc/1/cgroup检查失败后作为 fallback，不前置、不依赖 - 不要用它替代 cgroup 检查——它容易被手动删掉，且不反映真实 cgroup 层级
避免踩坑：别信 /etc/os-release 或 hostname
/etc/os-release 里的 PRETTY_NAME 可能写 “Ubuntu with Docker”，但这只是镜像作者填的描述字段，完全可伪造；hostname 随机长字符串（如 8a3f2b1e9c4d）虽常见于容器，但也可被 docker run --hostname 手动覆盖，不可靠。
-
/proc/sys/kernel/osrelease返回的是内核版本号，和是否容器无关 - 查
mount输出是否有overlay或overlay2可行，但需解析/proc/1/mountinfo，且部分只读容器可能未挂载/proc全集 - 调用
docker info或访问localhost:2375API 更不可取——需要额外权限、网络连通性，且在非 Docker 运行时（如 Podman）根本不可用
cgroup 路径匹配是唯一真正反映进程所属控制组的事实来源，其余都是旁证。实际编码时，优先走 /proc/1/cgroup，失败再依次 fallback 到 /proc/1/environ 和 /.dockerenv，三者都不可读才视为非容器环境——这个顺序和容错逻辑，比单点判断重要得多。
