File.WriteAllText在只读文件系统中必然抛出UnauthorizedAccessException，必须将写操作移至显式指定的可写路径（如/tmp或/data），不可依赖默认路径或尝试catch fallback。
只读文件系统下 File.WriteAllText 直接报错：拒绝访问
在 Docker 容器中，基础镜像层（如 /usr/share/dotnet 或 /app 的只读挂载）默认不可写。一旦代码调用 File.WriteAllText、Directory.CreateDirectory 等写入 API，会立刻抛出 UnauthorizedAccessException，错误信息类似：Access to the path '/app/config.json' is denied.
这不是权限配置问题，而是文件系统本身被 mount 为 ro（read-only）。硬改宿主机挂载参数或强行 chown，既违背容器设计原则，也破坏可移植性。
- 必须把「写操作」从只读路径彻底移开，哪怕只是临时写入
- 不要尝试用
try/catch捕获后 fallback 到只读路径——失败就是失败，不会因为 catch 就变可写 - 环境变量
DOTNET_CLI_HOME、HOME、TEMP等路径需显式指向可写位置（如/tmp或/app/data），否则 .NET 运行时内部也会悄悄写失败
Path.GetTempPath() 是安全的，但默认值可能不靠谱
Docker 容器里 Path.GetTempPath() 通常返回 /tmp，而 /tmp 在绝大多数基础镜像（Alpine、Debian-slim、mcr.microsoft.com/dotnet/aspnet）中默认可写。但有例外：
- 某些定制镜像或 Kubernetes Pod 安全策略会将
/tmp也设为只读 - Windows 容器中它可能指向
C:\Windows\Temp，而该路径在只读镜像层下同样不可写 - 部分 CI 环境（如 GitHub Actions 的 self-hosted runner）会限制
/tmp权限
实操建议：
- 启动时显式设置环境变量：
export TMPDIR=/tmp && dotnet myapp.dll（Linux）或set TMP=C:\temp（Windows） - 代码中主动校验：
if (!Directory.Exists(Path.GetTempPath()) || !Directory.GetAccessControl(Path.GetTempPath()).GetOwner(typeof(System.Security.Principal.SecurityIdentifier)).ToString().Contains("S-1-5-"))—— 更稳妥的做法是直接try { File.WriteAllText(Path.Combine(Path.GetTempPath(), "test"), "x"); } catch一次 - 避免依赖
Path.GetTempPath()生成关键路径；把它当作“临时缓存区”，而非持久存储
配置文件不能硬编码写入 AssemblyLocation 所在目录
常见反模式：var configPath = Path.Combine(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location), "appsettings.local.json") —— 这个路径大概率落在只读的 /app 或 /usr/share/dotnet 下，一写就崩。
正确做法是解耦「配置读取位置」和「配置写入位置」：
- 读配置：仍可从
/app/appsettings.json（只读）加载，这是合理的 - 写配置：只允许写到明确声明的可写目录，比如通过
--data-dir /app/data命令行参数或DATA_DIR环境变量指定 - ASP.NET Core 用户注意：
IConfigurationBuilder.AddJsonFile(..., optional: true, reloadOnChange: false)中的reloadOnChange必须为false，否则底层会监听文件变更并尝试 re-read，而某些 watch 实现（如FileSystemWatcher）在只读路径上会静默失败或触发异常
Dockerfile 中必须显式声明可写层或卷
仅靠代码规避还不够。如果运行时需要持久化数据（如日志、缓存、上传文件），必须让容器知道哪里能写：
- 在
Dockerfile末尾加：VOLUME ["/app/data", "/tmp/logs"]—— 这告诉 Docker 这些路径需挂载为可写卷，即使基础层是只读的 - 避免用
RUN chmod -R 777 /app试图“修复”权限——镜像层本身不可变，该命令无效，还污染镜像 - 若用
docker run启动，务必加上-v $(pwd)/data:/app/data映射，否则/app/data仍是只读的 overlayfs 层 - 对于无状态服务（如纯 API），干脆禁用所有写操作：启动前检查
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData)是否可写，不可写则直接Environment.Exit(1)
最易被忽略的一点：.NET 的 System.IO.Ports、Microsoft.Data.Sqlite 等库会在后台自动创建临时文件或锁文件，它们默认使用 Path.GetTempPath()。就算你的业务代码没写文件，这些依赖也可能在只读环境下静默崩溃。
