Windows上Docker Desktop挂载本地隐藏文件（如.env、.gitignore）必须手动创建，Docker不自动穿透NTFS隐藏属性；只要物理存在且权限允许，容器内即可正常读写，但宿主机需提前创建并确保Users或当前用户有读取权限。
Windows 上 Docker Desktop 挂载本地隐藏文件（如 .env、.gitignore）必须手动创建，Docker 不会自动穿透或识别 NTFS 隐藏属性
Windows 的“隐藏”是 NTFS 文件系统级属性，Docker 绑定挂载（-v）只做路径映射，不读取/传播该属性。也就是说：C:/project/.env 只要物理存在且路径可访问，就能被挂载；但若它被设为隐藏，容器内 /app/.env 仍可见、可读写——隐藏状态对容器完全无效。关键不是“能不能挂”，而是“宿主机上它到底存不存在、权限是否允许访问”。
- 必须提前在 Windows 中用
notepad C:\project\.env或echo "DEBUG=true" > C:\project\.env创建该文件（不能靠容器内 touch 生成） - 若用资源管理器手动新建并勾选“隐藏”，需确认当前用户有读取权限：右键 → 属性 → 安全 → 编辑 → 确保 Users 或当前用户名有“读取”权限
- PowerShell 中用
Get-Item C:\project\.env | ForEach-Object {$_.Attributes}可验证是否真为隐藏；但此结果不影响挂载行为 - 不要依赖
dir /a查看后就认为“Docker 能看到”，而要用容器内ls -la /app/实际验证
-v 挂载单个隐藏配置文件时，路径必须绝对、容器内目标路径需匹配应用预期加载位置
比如 Node.js 应用默认读取 ./.env，但你挂载到 /app/config/.env 就不会生效——除非启动命令显式指定 dotenv_config_path=/app/config/.env。挂载本身不改变程序行为，只提供文件存在性。
- 正确示例：
docker run -v C:/myapp/.env:/app/.env -v C:/myapp/src:/app/src node:18 npm start - 错误写法：
-v C:\myapp\.env:/app/.env（反斜杠在 CMD/PowerShell 中可能被转义，一律用正斜杠） - 若镜像基于 Alpine，
ls -la可能不显示隐藏文件，换find /app -name ".*"更可靠 - 挂载单个文件时，容器内目标路径不能是已存在的目录，否则挂载失败并报错
not a directory
挂载含隐藏文件的整个目录时，Docker 默认同步所有内容，但要注意 WSL2 文件系统层对 .dockerignore 的忽略逻辑不生效
.dockerignore 只在 docker build 阶段起作用，绑定挂载（-v）是运行时行为，完全绕过该机制。也就是说：即使你把 .git 目录设为隐藏，它依然会完整出现在容器里。
- 若想排除某些隐藏内容（如
.git、.DS_Store），只能靠宿主机侧清理：Get-ChildItem C:\myapp -Hidden -Recurse | Where-Object {$_.Name -in @('.git', '.DS_Store')} | Remove-Item -Force - 挂载整个项目目录（
-v C:/myapp:/app）后，容器内ls -la /app会列出所有隐藏项，包括.env、.git、.idea等 - 某些 IDE（如 VS Code）生成的
.vscode/目录若含调试配置，挂载后可能被容器内进程误读，建议明确只挂载必要子目录（如C:/myapp/src和C:/myapp/.env分开挂）
挂载失败时最常被忽略的三个 Windows 特有检查点
报错 invalid argument 或挂载后容器内为空，90% 是卡在这三处，而非路径写法本身。
- Docker Desktop Settings → Resources → File Sharing 中，对应驱动器（如 C:）未勾选或勾选后没点 Apply & Restart —— 这是 Windows 独有前置门槛，跳过直接失败
- 宿主机路径中含空格或中文没问题，但若父目录名含
.开头（如C:/.devcontainer），部分旧版 WSL2 内核会拒绝挂载，建议避开 - 使用
docker exec -it <容器名> sh -c "ls -la /app/"验证前，先确认容器内 shell 是否支持-la（Alpine 用ash，ls默认不显示隐藏文件；加-a才行）
