System.IO 在容器中读不到挂载目录，因容器通过 namespace 隔离文件系统视图，API 仅看到容器内路径；需检查 volume 挂载配置、权限、挂载时机，并避免跨挂载点操作及长期持有 FileStream。
为什么 System.IO 在容器里读不到挂载目录？
因为容器运行时（如 Docker）通过 Linux namespace 和 cgroups 实现文件系统视图隔离，System.IO 的所有 API（比如 Directory.GetFiles、File.Exists）都直接调用底层 OS 系统调用，它们看到的永远是当前进程视角下的 root —— 也就是容器镜像 + 挂载点构成的“伪根”，不是宿主机的 /。
常见错误现象：Directory.Exists("/data") 返回 false，但你在 docker exec -it xxx sh 里用 ls /data 却能看到文件；或者程序启动时报 DirectoryNotFoundException，而你确认 volume 已声明并绑定。
- 检查是否漏了
-v /host/path:/container/path或mounts配置 —— 容器内路径必须显式挂载，镜像里不存在的路径不会自动继承 - 注意挂载权限：Linux 容器默认以非 root 用户运行时（如
dotnet:7-alpine基础镜像），挂载目录若属 root:root 且无 world-readable 权限，System.IO会静默失败或抛UnauthorizedAccessException - Windows 容器对符号链接和重解析点支持弱，
Directory.EnumerateFiles可能跳过某些挂载子树，建议统一用 Linux 容器跑 .NET 应用
Path.GetFullPath 在容器里返回的路径可信吗？
可信，但它只做字符串规范化，不校验实际存在性。在容器中，Path.GetFullPath("../config/appsettings.json") 会返回类似 /app/../config/appsettings.json → /config/appsettings.json，这个结果本身没问题，但后续 File.Read 是否成功，完全取决于该路径是否被挂载进当前容器命名空间。
使用场景：配置加载、日志路径拼接、临时文件生成 —— 这些地方常依赖 Path 工具类构造路径，但容易误以为“路径合法 = 文件可访问”。
- 不要用
Path.GetFullPath的输出直接做存在性断言，它不等价于File.Exists - 避免在路径拼接中硬编码
".."，尤其当基础目录来自环境变量（如ENV_DIR="/data"）时，Path.Combine(envDir, "..", "conf")可能越出挂载边界，返回宿主机不可见路径 - 推荐用
AppContext.BaseDirectory或Environment.CurrentDirectory作为锚点，它们在容器中指向的是工作目录（通常为镜像内设定的WORKDIR），更可控
Dockerfile 中 WORKDIR 和挂载点冲突怎么办？
冲突会直接导致 System.IO 操作失败，但错误信息往往不指明根源。比如 Dockerfile 写了 WORKDIR /app，又通过 -v /host/logs:/app/logs 挂载，此时 Directory.CreateDirectory("/app/logs/archived") 会成功，但创建的其实是宿主机 /host/logs/archived —— 因为挂载点覆盖了原 /app/logs 目录。问题在于：你无法从 C# 代码里区分“这是镜像里的空目录”还是“这是挂载来的可写卷”。
性能影响：跨挂载点操作（如从 /app/bin 复制文件到 /data/output）可能触发 copy-up，在 overlayfs 下有明显延迟；兼容性上，Directory.Move 跨挂载点会失败并抛 IOException（错误信息是 "Cross-device link"）。
- 始终用
stat或findmnt在容器启动时验证挂载点状态，例如findmnt -T /data看是否显示为overlay或bind - 避免在
WORKDIR下直接挂载子目录；优先把数据目录设为独立挂载点（如/data），并在代码里明确用环境变量控制，例如Environment.GetEnvironmentVariable("DATA_ROOT") ?? "/data" - 对需要原子移动的场景（如归档日志），改用
File.Copy+File.Delete组合，绕过跨设备限制
容器重启后 FileStream 持有的句柄还有效吗？
无效。容器生命周期结束时，OS 会强制回收所有进程打开的文件描述符，无论是否显式 Dispose。如果 C# 代码里长期持有 FileStream（比如单例日志写入器），容器重启后该句柄指向的底层 inode 已销毁，再次写入会触发 IOException，错误信息通常是 "The process cannot access the file because it is being used by another process" 或更隐蔽的 "Bad file descriptor"（Linux errno 9）。
这在 Kubernetes 环境尤为典型：滚动更新、节点故障迁移都会触发容器重建，而应用若没监听 SIGTERM 做优雅关闭，就可能遗留未刷新的缓冲区或损坏的文件头。
- 所有
FileStream必须用using或显式Dispose，禁止长期持有实例 - 日志类库（如 Serilog、NLog）要配置
flushToDisk和closeOnExit，并启用watchForFileChanges避免因挂载点变更导致写入阻塞 - 关键数据写入后，调用
fileStream.Flush(true)强制落盘，再检查fileStream.CanWrite—— 它在句柄失效后会返回false，可作为早期探测信号
最麻烦的不是路径错，而是路径对了但挂载时机不对：比如 initContainer 没等 NFS 卷 ready 就启动主应用，这时 System.IO 看到的是空目录，连 stat 都不报错，只能靠主动 probe 文件系统类型或等待 /proc/mounts 更新来规避。
