文件权限变动本身不会直接触发Docker构建缓存重建——Docker仅校验COPY/ADD文件的内容哈希和指令字符串，不检查权限、所有者或mtime；但权限变更常伴随文件重写、上下文污染等深层问题，导致实际内容变化而缓存失效。
文件权限变动本身不会直接触发 docker 构建缓存重建——docker 的缓存机制只校验 copy/add 指令所涉及文件的内容哈希值 和 指令字符串本身，不检查文件的权限（mode）、所有者（owner）或时间戳（mtime）。但权限变动常是更深层问题的“信号灯”，真正导致缓存失效的，往往是伴随权限变更发生的其他行为。
先确认：权限改了 ≠ 缓存一定失效
Docker 构建时对本地文件做内容校验，用的是类似 SHA256 的哈希（基于文件字节流），和 chmod、chown 无关。也就是说：
- 仅执行
chmod 644 config.php，不改内容 → 缓存仍会命中 - 仅执行
chown www-data:www-data app/→ 不影响 COPY 层缓存 - 但若你用
sudo cp或编辑器保存时“悄悄重写”了文件（如 Vim 会先删再写），实际内容已变 → 哈希改变 → 缓存失效
权限变动常暴露的四类真实缓存破坏源
当发现“一改权限，后续构建就全量重跑”，重点排查以下场景：
- 文件被工具覆盖重写：IDE、编辑器、部署脚本在修改权限时顺手重写了文件（尤其带 BOM、换行符转换、UTF-8 编码修正），导致二进制内容变化
-
构建上下文混入临时文件：权限修改操作（如
find . -type f -exec chmod 644 {} \;）可能把.git、node_modules、*.log等不该进构建上下文的文件也纳入了COPY . /app，而这些文件的权限/内容频繁变动，拖垮整个缓存链 -
CI/CD 中用户切换引发路径解析差异：在 CI 流水线里用
root用户运行 chmod，但构建命令由gitlab-runner用户执行，不同用户下realpath()或符号链接解析结果不同，导致 COPY 源路径实际指向了不同文件 -
使用了未忽略的元数据文件：比如
.env.local权限从600改成644，但它本身被COPY . .带入，而该文件内容虽未变，其 inode 或扩展属性（xattr）在某些文件系统上可能影响 tar 打包行为（极少见，但 NFS/CIFS 挂载时偶发）
快速验证是否真因“文件内容变”导致缓存失效
别猜，用命令实锤：
- 运行构建前，记录待 COPY 文件的哈希：
sha256sum src/index.php - 执行权限修改后，再跑一次：
sha256sum src/index.php→ 若输出不同，说明内容已被改写 - 对比两次构建日志中
COPY步骤的输出：Step X/Y : COPY src/ /app/ ---> abc123vs---> Using cache，确认哪一层断了 - 用
docker build --no-cache -v查看详细层生成过程，定位首个---> [internal] load build context后首次执行的 COPY 是哪个
治本建议：隔离权限操作与构建流程
避免让权限管理干扰构建稳定性：
- 在 Dockerfile 内统一设权限：
RUN chmod 644 /app/config.php && chown nginx:nginx /app，而非在宿主机改 - 用
.dockerignore显式排除权限易变目录：.git/、logs/、tmp/、*.swp - CI 中固定构建用户，避免 sudo + 切用户组合；必要时用
chown -R $USER:$USER .统一归属，再构建 - 对敏感配置文件，改用
ARG+ENV注入，或挂载（docker run -v），完全绕过 COPY
