C#无法在运行时切换mount namespace，必须通过unshare或容器运行时在进程启动前创建并加入新namespace；System.IO操作完全依赖当前namespace的挂载状态，且在.NET进程中调用unshare/setns极易引发不可预测错误。
Linux 中 C# 无法直接用 Namespace 隔离文件系统视图
Namespace（如 mount namespace）是 Linux 内核机制，C# 运行时（.NET Runtime）不提供任何封装或 API 来创建、切换或加入 mount namespace。你写 System.IO 相关代码时，所有路径操作都走的是当前进程所属的 mount namespace —— 换句话说，C# 看到的文件系统视图，完全由宿主进程启动时所处的 namespace 决定，代码里没法“切”过去。
想在 C# 进程里用隔离的文件系统，只能靠外部启动控制
真正起作用的不是 C# 代码，而是进程启动前的环境准备。你需要用 unshare 或容器运行时（如 runc、podman）提前创建新 mount namespace，并把 C# 程序作为该 namespace 中的首个进程（PID 1）或子进程启动。
- 错误做法：
Process.Start("unshare", "--mount --fork -- /bin/sh -c 'dotnet app.dll'')—— 这看似可行，但unshare默认不保持 mount namespace，子 shell 很可能回退到父 namespace - 正确做法：加
--user --pid --fork并配合--mount-proc，且确保后续进程不触发 namespace 重置（例如避免调用setns()或 fork 后未重新挂载） - 更稳妥方式：用
podman run --mount type=bind,source=/tmp/altroot,target=/,readonly=false --cap-add=SYS_ADMIN alpine sh -c "dotnet /app/app.dll"，让容器运行时托管 namespace 生命周期
System.IO 在不同 namespace 下的行为完全透明，但容易误判原因
Directory.GetFiles、File.Exists 这些调用不会报 “namespace not found” 类错误 —— 它们只反映当前 namespace 下的真实挂载状态。你看到 DirectoryNotFoundException，往往是因为目标路径在该 namespace 里确实没挂载，而不是 C# “不支持 namespace”。
- 典型误判场景：在 rootless podman 容器中访问
/proc或/sys，发现内容和宿主机不同 → 这不是 .NET 的问题，是内核自动为每个 PID/mount namespace 提供了隔离视图 -
Path.GetFullPath("/foo")返回结果不变，但new FileInfo("/foo").Exists可能为false→ 因为/foo在当前 namespace 未挂载或被屏蔽 - 注意
/etc/mtab在多数 modern Linux 上是软链到/proc/self/mounts，C# 读它看到的就是当前 namespace 的挂载列表
不要试图在 C# 进程内用 P/Invoke 调用 unshare/setns
虽然理论上可以调用 libc 的 unshare(2) 或 setns(2)，但 .NET 运行时对线程、信号、文件描述符的管理与 namespace 切换强耦合，极易导致：
- GC 线程或线程池线程突然看到不一致的挂载状态，引发静默失败
-
Console.WriteLine写入被重定向的/dev/console失败，进程卡死 - 已打开的
FileStream对应的底层 fd 仍指向旧 namespace 的 inode，后续读写行为不可预测 - CoreCLR 本身依赖
/proc/self获取进程信息，切换 namespace 后可能解析路径出错
这些不是边界情况，而是大概率发生的问题。真要动态切 namespace，应该用独立的 C 工具做前置处理，再 exec 进 C# 程序，而不是在 .NET 进程里硬上。
namespace 隔离的关键不在代码怎么写，而在进程怎么启。一旦启动完成，C# 就只是安静地用它 —— 安静，但也很脆弱。
