最可靠的方式是读取/proc/1/cgroup并匹配docker、kubepods等关键词；若不可读则fallback至/proc/1/mountinfo查overlay或/proc/1/environ解析container=字段；/.dockerenv仅作辅助，不可依赖。
最可靠的方式是读取 /proc/1/cgroup 并匹配容器路径特征，而不是查 /.dockerenv 或环境变量 —— 后两者容易缺失或被伪造。
检查 /proc/1/cgroup 是否含容器标识符
宿主机上 PID 1 的 cgroup 路径通常为 / 或 /init.scope；Docker、Kubernetes、Podman 等容器中则必然出现 docker、kubepods、lxc、crio、podman 等关键词（大小写不敏感）。
- 用
std::ifstream或fopen()打开/proc/1/cgroup，逐行扫描，避免整文件读入 - 每行转小写后用
find()检查子串，不要依赖正则（C++11 标准库正则在某些 Alpine 镜像中不可用） - 必须处理文件不可读场景：
access()返回 -1 或fopen()返回nullptr时直接跳过，不报错 - Linux 5.16+ 的 cgroup v2 模式下，第一行可能是
0::/，此时需 fallback 到/proc/1/mountinfo查overlay或overlay2
fallback 到 /proc/1/environ 解析 container= 字段
Docker 默认注入 container=docker，Podman/LXC 可能写 container=lxc，但该字段非强制，distroless 或 rootless 容器常缺失。
- 必须用
std::vector<char></char>一次性读入全部内容，按\0分割字符串 - 不能用
std::getline(..., '\0')—— 多数标准库实现不支持空字符作为分隔符 - 遍历每个
\0分隔的字符串，用starts_with("container=")判断（C++20）或substr(0, 10) == "container=" - 若
open("/proc/1/environ", O_RDONLY)失败（常见于 seccomp 限制），直接忽略此项
慎用 /.dockerenv 文件检测
该文件仅由 Docker daemon 创建，Podman、LXC、Kubernetes CRI-O 等多数运行时不生成，且 scratch 或 distroless 镜像中根本不存在。
立即学习“C++免费学习笔记（深入）”；
- 可用
access("/.dockerenv", F_OK)快速判断，但结果为true仅能确认是 Docker，false完全不能排除容器环境 - 某些定制镜像会手动创建该文件用于伪装，所以它只能作为辅助线索，不能作为主依据
- Alpine 镜像若以
--read-only启动且未挂载/proc全量路径，/proc/1/cgroup可能不可读，但/.dockerenv仍存在 —— 这种情况极少见，不值得为它增加逻辑分支
真正难处理的是 cgroup v2 + rootless + seccomp 的组合：此时 /proc/1/cgroup 和 /proc/1/environ 都可能拒绝访问，/.dockerenv 也不存在。这种情况下，唯一可依赖的是 /proc/mounts 中是否存在 overlay、overlay2 或 fuse-overlayfs，但解析它需要更多权限和更重的逻辑 —— 大多数服务不需要覆盖到这个层级，够用即可。
