File.WriteAllText在容器中写入文件后找不到，是因为容器默认使用临时文件系统，只有挂载的volume或bind mount路径才持久化；需挂载宿主机目录到容器/data并确保权限正确，且用原子写法（File.Replace）安全保存JSON配置。
为什么 File.WriteAllText 在容器里写完文件却找不到？
因为默认情况下，C# 应用运行在容器的临时文件系统中，容器重启或删除后，所有写入 /app、/tmp 等路径的文件都会丢失。真正能持久化的只有挂载进来的数据卷（volume）或绑定挂载（bind mount）路径。
你必须显式把宿主机目录或命名 volume 挂载到容器内某个路径（比如 /data），然后 C# 代码只对那个路径做读写——否则一切 IO 都是“假持久化”。
- 检查 Docker 运行命令是否包含
-v /host/path:/data或--mount source=myvol,target=/data - 在 C# 中硬编码路径时，优先用环境变量（如
Environment.GetEnvironmentVariable("DATA_DIR") ?? "/data"），别写死/data - 容器内进程默认以非 root 用户（如
dotnet用户）运行，确保挂载路径在容器内可读写：docker run -v $(pwd)/localdata:/data:rw ...
如何安全地在 /data 下读写 JSON 配置文件？
直接调用 File.WriteAllText 写配置有风险：若写入中途失败（磁盘满、权限丢、容器被杀），原文件可能被清空或损坏。推荐用原子写法 + 显式异常处理。
string dataDir = Environment.GetEnvironmentVariable("DATA_DIR") ?? "/data";
string configPath = Path.Combine(dataDir, "config.json");
string tempPath = Path.Combine(Path.GetTempPath(), $"config_{Guid.NewGuid()}.json.tmp");
<p>try
{
string json = JsonSerializer.Serialize(config, new JsonSerializerOptions { WriteIndented = true });
File.WriteAllText(tempPath, json);
File.Replace(tempPath, configPath, null); // 原子替换，Windows/Linux 都支持
}
catch (UnauthorizedAccessException)
{
throw new InvalidOperationException($"无法写入 {dataDir}，请检查挂载权限和 SELinux/AppArmor 设置");
}
catch (IOException ex) when (ex.Message.Contains("No space left on device"))
{
throw new InvalidOperationException("数据卷空间不足，请清理或扩容");
}注意：File.Replace 在 Linux 容器中依赖底层文件系统支持 rename（ext4/xfs 都 OK），但 NFS 挂载可能不支持原子替换，此时需退回到先写临时文件、再 File.Delete + File.Move 组合，并加锁。
挂载 volume 后仍提示 DirectoryNotFoundException 怎么办？
常见原因是挂载点在容器启动时尚未创建，而 .NET 的 Directory.CreateDirectory 默认不会递归创建父目录（尤其当挂载目标是空 volume 时）。更糟的是，如果挂载路径权限不对（例如宿主机目录属主是 root，容器用户无权进入），Directory.GetDirectories 也会抛这个异常，而非更明确的 UnauthorizedAccessException。
- 启动容器前，在宿主机手动创建并授权：
mkdir -p /host/data && chmod 755 /host/data && chown 1001:1001 /host/data（1001 是 SDK 镜像中dotnet用户 UID） - C# 中不要只靠
Directory.Exists判断，要主动尝试创建并捕获异常：try { Directory.CreateDirectory(dataDir); } catch (UnauthorizedAccessException) { /* 处理权限 */ } - 避免在
Program.cs顶层直接操作路径，放到Startup.ConfigureServices或 HostedService 初始化阶段，确保容器已完全启动、挂载就绪
Docker Compose 中怎么配 volume 才让 C# 应用可靠访问？
用命名 volume 比 bind mount 更可控，尤其适合多容器共享或 CI/CD 场景；但开发时 bind mount 更方便调试。关键不是“怎么写”，而是“谁拥有它”和“是否提前初始化”。
services:
myapp:
image: myapp:latest
volumes:
- mydata:/data # 命名 volume，Docker 自动创建，属主为 root，需在镜像中 chown
# - ./localdata:/data:rw,z # bind mount，z 表示 SELinux 标签（RHEL/CentOS 必须）
<p>volumes:
mydata:
driver: local
driver_opts:
type: none
o: bind
device: /absolute/path/on/host # 强制映射到宿主机真实路径，避免 Docker 自建空 volume最易忽略的一点：如果你用 docker-compose up 第一次启动，Docker 会自动创建名为 mydata 的 volume，但它内部是空的，且属主是 root。你的 .NET 应用以非 root 用户运行，/data 目录不可写。解决方案是在 Dockerfile 中加一句：RUN mkdir -p /data && chown dotnet:dotnet /data，或者改用 device 显式绑定真实路径。
