Go应用容器内写文件permission denied，主因是USER用户无目录写权限。需检查Dockerfile USER指令、父目录属主/权限、挂载卷UID匹配及WORKDIR设置，并用strace定位系统调用失败点。
Go 应用在容器里报 permission denied 写文件？先看 USER 是谁
绝大多数情况，不是 Go 代码有问题，而是镜像里 USER 指令切换的用户没权限写目标目录。Docker 默认以 root 启动，但很多基础镜像（比如 gcr.io/distroless/static、alpine:latest）或安全策略会强制用非 root 用户运行，而 Go 程序默认尝试往 /tmp、./data 或挂载路径下写，这些位置往往属于 root 或未被 chown。
- 检查你的
Dockerfile是否有USER 1001或USER appuser这类指令 - 确认 Go 程序要写的路径是否在构建时就存在，且属主/属组已适配该用户（比如用
chown -R 1001:1001 /app/data） - 避免在
RUN阶段用root创建目录，却在USER切换后不改权限——这是最常见漏点
Go 的 os.OpenFile 在容器里失败，和 0644 权限无关
很多人以为加了 0644 就能写，其实 os.OpenFile 能否成功，取决于父目录的 w 权限，而不是文件自身的权限位。容器里常出现「文件已存在但写不了」，本质是父目录不可写。
- 用
os.Stat检查目标路径的父目录（比如写./logs/app.log，先os.Stat("./logs")） - 如果返回
stat ./logs: permission denied，说明连进目录都不行，更别说创建文件 - 不要依赖
os.MkdirAll(path, 0755)自动修复——它只在目录不存在时创建，若目录存在但权限不对，不会改 - 推荐在启动前显式确保：先
mkdir -p /app/logs，再chown -R 1001:1001 /app/logs（对应你的USERUID）
使用 docker run -v 挂载宿主机目录时，UID 不匹配导致写失败
宿主机上 /host/data 属于 UID 1000，但容器内 USER 1001 进程去访问，Linux 内核直接拒绝，哪怕目录权限是 777 也没用。这不是 Go 的 bug，是 Unix 文件权限模型本身的行为。
- 查宿主机目录真实 UID：
ls -ld /host/data，注意数字 UID，别只看用户名 - 要么让容器
USERUID 和宿主机一致（例如USER 1000），要么在宿主机上chown 1001:1001 /host/data - 避免用
docker run --user root临时绕过——这破坏最小权限原则，且可能触发 distroless 镜像拒绝启动 - 如果必须动态适配，可在容器 entrypoint 脚本里用
chown $UID:$GID /mounted/path（需提前传入环境变量）
Go 程序里硬编码路径（如 "./config.yaml"）在容器里容易失效
相对路径依赖当前工作目录（pwd），而容器中 WORKDIR 可能没设，或设得和本地开发不一致，导致 Go 打开文件时实际路径错位，报错却是模糊的 no such file or directory。
立即学习“go语言免费学习笔记（深入）”；
- 永远用绝对路径初始化关键 I/O：比如
filepath.Join(os.Getenv("APP_HOME"), "config.yaml")，并在启动时校验APP_HOME - 在
Dockerfile中明确WORKDIR /app，并确保所有COPY的配置文件都在此路径下 - 用
os.Getwd()打日志，上线前确认输出是否符合预期——别假设它一定等于WORKDIR - 如果用
embed.FS加载静态资源，记得路径是编译时绑定的，和运行时WORKDIR无关，但写操作仍受文件系统权限约束
最麻烦的不是权限报错本身，而是它常被日志掩盖：Go 程序静默跳过写失败、或只打一句 failed to save cache，背后其实是 open /cache/state.bin: permission denied 被吞了。上线前务必用 strace -e trace=openat,chmod,chown 跑一遍容器进程，看系统调用哪一步卡住。
