docker容器pid隔离本质是linux内核pid namespace实现的视图隔离，非进程消灭；默认为每个容器创建独立命名空间，容器内pid从1起始并承担init职责，宿主机上对应唯一全局pid，通过docker inspect可查，且容器间pid 1互不冲突。

容器进程的 PID 隔离机制，本质是 Linux 内核通过 PID 命名空间（PID Namespace） 实现的视图隔离，不是真实消灭进程，而是让不同环境“看到不同的 PID”。Docker 架构在启动容器时自动启用这一机制，默认为每个容器创建独立的 PID 命名空间。

容器内 PID 总是 1 起始，但宿主机上完全不同

容器中第一个进程（如 sleep、nginx 或 sh）在该命名空间里被分配为 PID 1，承担 init 进程职责：回收僵尸子进程、响应信号。但它在宿主机上实际对应一个普通数字（比如 5678），可通过 docker inspect -f '{{.State.Pid}}' <container_id></container_id> 查到。

• 容器内执行 ps aux → 只显示自身命名空间里的进程，主进程 PID 显示为 1
• 宿主机执行 ps aux | grep <container_process></container_process> → 看到的是全局 PID，数值更大且唯一
• 同一台机器上多个容器，它们各自的 PID 1 在各自空间中互不冲突

Docker 默认启用 PID 命名空间，也可显式控制

Docker 在调用 clone() 系统调用创建容器初始进程时，会传入 CLONE_NEWPID 标志，触发新命名空间创建。这是默认行为，无需额外参数。

minimax-mcp-docker版（适配极空间）

MiniMax 图片理解 + 网络搜索 MCP 工具。适配 Docker 环境（极空间等），支持图片 OCR 识别、图像内容理解、网络搜索。API Key 安全存储在本地 credentials 文件，不暴露在代码中。

下载

• docker run alpine ps aux → 容器使用 private PID 命名空间（默认）
• docker run --pid=host alpine ps aux → 共享宿主机 PID 命名空间，能看到所有系统进程
• --pid=container:<name_or_id></name_or_id> → 与另一个容器共享 PID 命名空间

命名空间有层级关系，父可看子，子不可见父

PID 命名空间支持嵌套。宿主机处于顶层命名空间，能遍历所有子命名空间中的进程；而容器内部无法感知宿主机或其他容器的进程，连 /proc/[pid] 下的路径都只指向本空间内的有效 PID。

• 容器内访问 /proc/1 → 指向自己的 init 进程
• 宿主机访问 /proc/5678 → 指向该容器主进程的真实进程结构
• 容器内执行 kill -9 1 → 终止整个容器（因 PID 1 退出导致命名空间销毁）

验证隔离效果的简单方法

不用写代码，用标准命令就能观察隔离现象：

• 启动容器：docker run -d --name test-pid alpine sleep 3600
• 进容器看 PID：docker exec test-pid sh -c 'echo $$; ps aux' → 输出 PID 1 和少量进程
• 宿主机查真实 PID：docker inspect -f '{{.State.Pid}}' test-pid，再 ls -l /proc/<pid>/ns/pid</pid> → 看到唯一 inode，与其他容器不同
• 对比 unshare --pid --fork /bin/sh -c 'echo $$; ps aux' → 效果一致，说明 Docker 底层正是基于此机制