dockur/windows：把 Windows 装进容器，但先看清 KVM 这道门槛

它解决的是安装 Windows 这件麻烦事

dockur/windows 解决的问题很具体：在 Linux 主机上用 Docker 容器运行一个完整的 Windows 系统，并且把下载 ISO、创建虚拟磁盘、执行安装、配置远程桌面这一整套流程自动化。项目 README 里明确写着“Automatic download and hands-free installation”，也就是说你不需要手动挂载安装镜像，也不需要一步步点击安装向导。容器启动后，你只需在浏览器里打开 8006 端口，剩下的安装过程由脚本完成。这个项目面向的是两类人：一类是开发者和运维，他们需要临时跑一个 Windows 环境来测试脚本、验证兼容性，或者运行只能在 Windows 上工作的工具；另一类是普通用户，想在 Linux 桌面上用 Windows 软件，但又不想折腾完整的虚拟机软件。它把 Windows 变成了一种可重复部署的容器化服务，而不是一台需要手动维护的虚拟机。

KVM 是命门，不是可选项

这个项目能跑的前提是 KVM 硬件虚拟化。README 在 Requirements 一节写得很直接：需要 Linux 主机支持 KVM，或者 Windows 11 上的 Docker Desktop 开启嵌套虚拟化。它还特别用 NOTE 标注，Docker Desktop 在 Linux、macOS 和 Windows 10 上不提供 KVM 访问，因此不支持。这意味着你没法在 Mac 上或者普通 Windows 10 笔记本上用它。容器必须挂载 /dev/kvm 设备，compose 文件里 devices 段明确写了这一项。如果没有 KVM，容器可能根本启动不了，或者即使启动也无法正常运行 Windows。这不是一个可以妥协的性能问题，而是功能上的硬性要求。所以评估这个项目的第一步不是看功能列表，而是先确认你的主机有没有 /dev/kvm，以及当前用户是否有权限访问它。

自动安装的机制藏在环境变量里

dockur/windows 的自动化逻辑主要通过环境变量驱动。VERSION 变量决定安装哪个 Windows 版本，默认是 11，对应 Windows 11 Pro，约 7.9 GB。你可以改成 10、8e、7u、xp，甚至 95 和 98，列表里从 Windows 95 到 Server 2025 都有。每个版本对应一个预设的下载源和安装流程。容器启动后，它会自动下载对应版本的镜像，然后执行无人值守安装。安装完成后，桌面上会出现一个 Shared 文件夹，对应宿主机的挂载目录，这就是文件共享的入口。整个过程不需要用户干预，但也不是完全黑盒。如果你想知道当前装到哪一步，可以打开 8006 端口的网页查看画面。这个设计把安装过程变成了一个可配置的声明式操作，你只需要在 compose 文件里写几个环境变量，剩下的交给容器。

存储和资源分配：DISK_SIZE、RAM_SIZE、CPU_CORES

默认配置给 Windows 分配 2 个 CPU 核心和 4 GB 内存，磁盘默认 64 GB。这些都可以通过环境变量调整。RAM_SIZE 和 CPU_CORES 直接控制虚拟机的资源上限，DISK_SIZE 控制虚拟磁盘大小。DISK_SIZE 有一个值得注意的特性：它可以用来扩展现有磁盘，而且不会丢数据。但 README 提醒，扩容后需要手动在 Windows 里扩展分区，因为新增的空间会显示为未分配。这一点很容易被忽略，很多人以为改大 DISK_SIZE 就完事了，实际上还要进磁盘管理工具去扩展卷。存储位置通过挂载 /storage 目录来改变，默认是 ./windows 相对路径。共享文件夹则是挂载到 /shared，在 Windows 里显示为 Z: 盘。这些配置都写在 compose 文件的 environment 和 volumes 段里，结构清晰，改起来也不复杂。

网络和远程连接：8006 网页端只是安装工具

容器启动后，8006 端口提供一个网页版查看器，但 README 明确说这个查看器主要用于安装过程，因为它的响应速度不如 RDP，也不支持剪贴板共享。安装完成后，更好的方式是使用 Microsoft Remote Desktop 客户端连接容器的 IP，用户名是 Docker，密码是 admin。这意味着日常使用走的是 RDP 协议，而不是网页。网络方面，项目支持 NAT、user-mode、macvlan 和 macvtap 四种模式，compose 文件里通过 cap_add NET_ADMIN 和 /dev/net/tun 设备来启用网络功能。如果你需要让外部设备直接访问容器里的 Windows，可能需要配置 macvlan，但 README 没有给出具体示例，这部分需要你自己去查文档。音频默认是关闭的，除非你用 RDP；要在网页端听声音，需要设置 AUDIO 为 Y，然后在网页查看器的设置里手动开启音频。这个细节说明，项目对网页端的定位是“够用就好”，真正的体验还得靠 RDP。

它不擅长什么：一个真实的边界

这个项目不是万能的。首先，它不提供图形化的管理界面，所有配置都靠环境变量和 compose 文件，对不熟悉 Docker 的人有门槛。其次，它依赖 KVM，这决定了它只能跑在 Linux 主机上，而且主机必须支持硬件虚拟化。如果你的服务器是云主机，很多云厂商默认不开放嵌套虚拟化，你可能连 /dev/kvm 都没有。第三，自动安装虽然方便，但如果你需要定制安装过程，比如指定分区、预装软件、修改注册表，它提供的变量可能不够用。第四，性能虽然号称接近原生，但那是针对 KVM 加速的情况，实际上还是会有虚拟化开销，尤其是图形密集型任务。最后，安全方面，默认用户名和密码是 Docker/admin，如果你暴露了 RDP 端口到公网，这是一个明显的风险。README 没有提到任何安全加固措施，所以部署时你需要自己考虑端口暴露和密码修改。

替代方案：不是所有容器化 Windows 都一个样

如果你需要的是 Linux 容器里跑 Windows 应用，而不是完整 Windows 系统，那么 Wine 或 WinApps 是更轻量的选择。WinApps 项目在 README 里被列为使用 dockur/windows 作为后端的项目之一，但它的目标不同：它让你在 Linux 桌面上直接打开 Windows 应用，就像打开本地程序一样，底层可能还是需要一个 Windows 环境。如果你不需要完整桌面，只是跑单个 exe，Wine 不需要 KVM，也不需要 32 GB 磁盘，但兼容性差很多。另一个方向是真正的虚拟机方案，比如 Proxmox VE 或 VirtualBox，它们同样需要 KVM 或类似虚拟化支持，但提供了更成熟的快照、克隆和迁移功能。dockur/windows 的优势在于它是容器化的，可以用 docker compose 管理生命周期，但代价是它把 Windows 的安装和运行逻辑封装在脚本里，出了问题你很难调试。选择哪个取决于你需要的是“容器化的 Windows”还是“虚拟化的 Windows”。

维护成本和许可证：MIT 协议下的取舍

项目使用 MIT 许可证，这意味着你可以自由使用、修改和分发，只需要保留版权声明。仓库的活跃度看起来不错，最近一次提交是 2026 年 8 月，版本号已经到 v6.05，说明项目还在持续更新。但维护成本不低：你需要跟进版本升级，因为 Windows 镜像下载源可能会变化，旧版本可能失效。另外，自动安装脚本依赖第三方镜像源，如果源被屏蔽或删除，安装就会失败。升级容器镜像时，要注意 /storage 目录中的数据是否会被迁移，README 没有明确说明升级对已有磁盘的影响，建议升级前备份整个 windows 目录。许可证方面，MIT 只覆盖项目本身的代码，你安装的 Windows 系统仍然是微软的专有软件，你需要自己处理 Windows 的授权问题。项目默认安装的 Windows 11 Pro 是未激活的，长期使用可能需要购买许可证。这一点 README 没有提，但你应该知道。

编辑结论

dockur/windows 适合两类人：一是手头有 Linux 服务器且开了 KVM，想快速起一个临时 Windows 环境做测试或跑老旧软件；二是想用容器方式管理多个 Windows 实例，省去虚拟机管理器的额外开销。不适合的人很明确，Docker Desktop 在 Linux、macOS 和 Windows 10 上拿不到 KVM，项目文档直接说不支持，这些用户装了也白装。采用前先验证三件事：确认 /dev/kvm 存在且当前用户有权限访问，确认磁盘空间至少 32 GB 且 /storage 挂载路径可写，确认 8006 端口没有被占用。如果这些条件都满足，它确实能让你用一条 docker run 命令得到一台装好的 Windows；如果满足不了，去找 Proxmox 或 VirtualBox 更实际。

官方来源

1. Official README
2. Project repository
3. Release notes