docker cp 不支持双向同步，仅单向复制，无文件比对、增量更新或冲突检测能力；路径斜杠影响行为，权限需手动调整；真正同步应使用挂载或封装脚本。
docker cp 本身不支持双向同步，它只做单向复制；所谓“双向”，是你手动执行两次 docker cp —— 一次从宿主机到容器，一次从容器到宿主机。
为什么不能用 docker cp 实现真正的双向同步
docker cp 是一次性、无状态的拷贝命令，没有文件比对、增量更新或冲突检测能力。它不像 rsync 或 unison 那样能识别哪些文件被修改/删除/新增。如果你期望“改了宿主机配置自动生效到容器，改了容器日志自动拉回本地”，docker cp 做不到。
常见误判场景：
- 执行
docker cp ./conf/ myapp:/etc/nginx/conf.d/后，又在容器里改了其中某个.conf文件，再运行一遍相同命令 —— 它会直接覆盖，不会跳过未变更文件 - 用
docker cp myapp:/etc/nginx/conf.d/ ./conf-backup/拉取后，本地删了一个文件，下次再推过去，这个文件依然会被重新写入容器（因为docker cp不感知删除）
复制配置文件时路径结尾斜杠决定行为
容器内目标路径是否以 / 结尾，直接影响是“放进去”还是“重命名”。这是最容易出错的地方。
-
docker cp nginx.conf myapp:/etc/nginx/conf.d→ 把文件存为/etc/nginx/conf.d（覆盖该路径，变成一个文件） -
docker cp nginx.conf myapp:/etc/nginx/conf.d/→ 把文件存为/etc/nginx/conf.d/nginx.conf（末尾斜杠表示目录） -
docker cp ./conf.d/ myapp:/etc/nginx/conf.d/→ 复制整个目录内容到目标目录（需加-r） -
docker cp ./conf.d myapp:/etc/nginx/→ 把conf.d这个目录整体复制成/etc/nginx/conf.d
建议统一在目标路径末尾加 /，并显式使用 -r：比如 docker cp -r ./conf.d/ myapp:/etc/nginx/conf.d/，语义清晰、不易歧义。
权限和属主问题常导致容器内配置不生效
复制进容器的文件默认归 root 所有，但很多服务（如 Nginx、PostgreSQL）以非 root 用户运行，会因权限拒绝读取配置。
- 先确认容器内目标目录权限：
docker exec myapp ls -ld /etc/nginx/conf.d/ - 若需非 root 用户可读，可在复制后修正：
docker exec myapp chown -R nginx:nginx /etc/nginx/conf.d/ - 或复制前在宿主机设好权限：
chmod 644 ./conf.d/*.conf - 注意：
docker cp -a可保留原始权限和时间戳，但无法解决 uid/gid 映射问题（宿主机的 uid 1001 在容器里可能不存在）
想真正双向同步？得换工具或加一层封装
如果项目中频繁需要配置双向流动（比如开发调试阶段），docker cp 手动操作成本高且易漏。这时可考虑：
- 用
docker run -v挂载宿主机目录，实现天然实时同步（但要求启动容器时规划好，已运行容器无法热加挂载） - 写简单 shell 脚本封装两次
docker cp，例如：./sync-conf.sh up（推）和./sync-conf.sh down（拉） - 对复杂场景，用
tar流式传输 +rsync容器内比对（需容器装 rsync，且开放 shell 权限）
最常被忽略的一点：docker cp 对已停止容器同样有效，但很多人误以为必须容器 running 才能传 —— 其实不用。停着的容器也能备份配置、提取日志，这点在故障排查时特别有用。
