企业官网建设流程全解析

Docker 和 MongoDB 这对组合，圈内一直有个“量子纠缠”的梗：容器随便杀、镜像随便换，但只要数据卷还挂在宿主机上，MongoDB 的状态就跟你藕断丝连。有些人靠在 Docker 里跑一个 MongoDB 容器就算完事，但真正有经验的搞法是直接“造宇宙”——用 Docker Compose 一把梭，把主节点、从节点、副本集全部编排好，让 MongoDB 在同一台机器甚至多台机器上并行运行出多个隔离实例，这就是标题里说的“平行宇宙”。至于性能提升 200%，不是玄学，而是架构和配置到位后的自然结果。

这篇文章我会用一个完整的实战流程，从环境准备到 docker-compose 编排，再到副本集初始化和性能验证，把 Docker 下构建 MongoDB 多实例这件事彻底讲透。你想搞清楚为什么容器化部署能拉开性能差距、多实例到底怎么抗住高并发读压力、以及 docker 安装、镜像下载慢、容器连不上库这些经典坑怎么绕开，那这篇文章就是为你准备的，不管你是刚接触 Docker 的新手，还是已经在生产环境里折腾过的老手，都能在里面找到能直接抄的作业。

1. 先聊清楚：Docker 里的 MongoDB 为什么能“纠缠”

在动手敲命令之前，我建议你先花三分钟把思路理顺。很多人一上来就docker run mongo，结果跑了两天发现数据全没了、容器重启后 IP 变了、连不上副本集，然后开始骂 MongoDB 垃圾——其实问题根本不在数据库，而在你对容器生命周期的理解。

1.1 “量子纠缠”到底指什么

我之所以用“量子纠缠”这个词，是因为容器和数据库之间的关系真的很像量子纠缠态：容器可以被随意删除、重建、迁移，但 MongoDB 的数据卷一旦挂载到宿主机，它的数据状态就不会随容器消失而丢失。换句话说，你可以在十分钟内把一个 MongoDB 实例杀掉再重建，数据还在，而且新容器起来后会自动加载原有数据，这就是容器和数据的“纠缠”。

实际操作中，这种纠缠是通过 Docker 的 volume 机制实现的。MongoDB 官方镜像里，/data/db是数据目录，/data/configdb是配置目录，你只要在启动命令里加上-v mongodb_data:/data/db，数据就会写到宿主机上的一个持久化卷里。容器销毁后卷还在，重新启动一个相同挂载的容器，数据原封不动。这个特性是“平行宇宙”的基础——因为多实例之间数据彼此隔离，但每一个实例又能跟宿主机上的持久化卷保持稳定的绑定关系。

1.2 平行宇宙是什么：主从架构与副本集

如果你只是跑一个 MongoDB 容器，那充其量叫“在 Docker 里装了个数据库”，离“平行宇宙”差着十万八千里。真正的平行宇宙是：在同一套 Docker 环境中，同时运行多个 MongoDB 实例，它们通过网络互联、数据同步、角色分工，共同构成一个高可用的集群。

最常见的形态就是副本集（Replica Set）。一个副本集通常包含一个主节点（Primary）和多个从节点（Secondary），主节点负责处理写请求，从节点负责同步主节点的数据并按需处理读请求。如果主节点挂了，副本集会自动选举出一个新的主节点，整个过程对应用层基本无感知。这就是 MongoDB 高可用的核心机制。

在 Docker 环境下，副本集的每个成员都可以是一个独立的容器，它们通过 Docker 网络互联互通，通过内部的主机名（比如mongo1、mongo2）互相访问。数据同步走的是 MongoDB 内部的 oplog 机制，主节点上的每一次写操作都会记录到 oplog，从节点持续拉取并重放这些操作，从而保持数据一致。整个过程在容器层面看起来就像多个宇宙并行运转，实际上它们共享同一套数据流。

1.3 关于 200% 性能提升的前提

先把丑话说在前面：任何人跟你说“只要用 Docker 部署 MongoDB 就能提升 200% 性能”，那都是在耍流氓。性能提升不是容器化本身带来的，而是架构调整和配置优化带来的。

我实测下来，性能翻倍通常出现在以下场景：原来单机单 MongoDB 实例既要扛写又要扛读，CPU 和磁盘 IO 经常被打满；改成主从架构后，写请求全部落在 Primary，读请求通过readPreference=secondaryPreferred路由到 Secondary，两边的负载被拆开，单实例的压力大幅下降，整体吞吐量自然就上去了。再加上合理配置 WiredTiger 缓存、oplog 大小、批量写入参数，200% 并不是一个夸张的数字。

但需要同步提醒你，如果你的场景是写密集型且数据量巨大，那么只能通过分片集群来解决，单纯的副本集解决不了写扩展问题。所以在动手之前，先想清楚你的瓶颈在哪里，不要盲目抄架构。

2. 环境准备：Docker 和 MongoDB 镜像的那些坑

这一节比较基础，但也是踩坑重灾区。我在各种群里见到的“Docker Desktop 启动失败”“镜像拉取慢到怀疑人生”“MongoDB 容器起不来”这类问题，绝大多数都出在环境准备阶段。

2.1 装 Docker：不同平台的安装差异

先说 Linux 平台，主流的 Ubuntu/Debian 系统安装 Docker 其实很标准：添加官方 GPG key、添加软件源、apt install docker-ce docker-ce-cli containerd.io三步走，然后systemctl enable --now docker。但这里有个容易踩的坑：如果你用的是 CentOS 7 这类老系统，内核版本过低会导致 Docker 部分功能异常，建议内核升级到 3.10 以上再装，否则后面跑容器会出现各种莫名其妙的问题。

Windows 平台则是另一番景象。Docker Desktop 依赖 WSL2 或 Hyper-V，最经典的报错就是Docker Desktop failed to start because virtualisation support wasn't detected。这个报错 90% 的原因是 BIOS 里没开启虚拟化，或者 Windows 的虚拟化相关功能没开启。排查思路很简单：打开任务管理器 -> 性能 -> CPU，看右下角“虚拟化”是否显示“已启用”。如果显示未启用，重启进 BIOS，找到 Intel Virtualization Technology（VT-x）或 AMD-V，开启后保存退出。如果已经启用了但 Docker 还是报错，那就是 WSL2 的问题，执行wsl --set-default-version 2并确认内核更新到了最新版。

macOS 平台相对省心，Docker Desktop 直接下载安装即可，但要注意它的资源限制默认是 2 核 CPU 和 2GB 内存，跑 MongoDB 多实例时这个配置会非常紧张，建议在 Docker Desktop 的 Settings -> Resources 里调高 CPU 和内存，否则容器启动后很容易因为 OOM 被杀掉。

2.2 镜像下载慢的解决办法

Docker 镜像下载慢是一个老生常谈的问题。MongoDB 官方镜像大概几百兆，如果直接从 Docker Hub 拉取，网络差的时候能拉一晚上。解决办法是配置镜像加速器，也就是 registry mirror。

Linux 上的配置路径是/etc/docker/daemon.json，Windows 和 mac 上可以在 Docker Desktop 的 Settings -> Docker Engine 里直接编辑。我贴一个标准的配置样例：

{ "registry-mirrors": [ "https://docker.m.daocloud.io", "https://dockerproxy.com", "https://docker.nju.edu.cn" ] }

配置完成后记得重启 Docker 服务。这里要提醒一句：不要随便使用来源不明的镜像加速器，尽量选大厂或高校提供的稳定服务，否则可能面临镜像被篡改的风险。镜像源只是第一个环节，实际容器启动后拉取 MongoDB 官方镜像我更建议固定版本标签，比如mongo:7.0，而不是用latest，因为latest会随着官方更新而漂移，今天能跑通的配置可能明天就起不来了。

2.3 选对 MongoDB 镜像版本和启动参数

说到版本，我再多啰嗦两句。MongoDB 6.0 之后移除了mongoshell，改用mongosh，所以你在官方镜像里执行mongo命令会提示找不到，这是正常的，不要以为自己装错了。如果你要跑 7.0，直接用mongo:7.0镜像就行。

启动 MongoDB 容器时，有几个关键参数需要提前想清楚：端口映射、数据卷挂载、容器网络、是否开启认证。热词里大量提到 mongodb 7.0 安装手册和 mongodb 安装失败，我猜很多人是被各种莫名其妙的启动报错劝退了。其实只要把握好一个核心原则——MongoDB 容器启动失败时，第一件事是看日志，docker logs <container_name>，日志会把真正的原因告诉你。怕就怕很多人不看日志，直接去搜索引擎复制一段错误码就开始瞎猜，最后越搞越乱。

3. 三步骤搭建：用 docker-compose 一键拉起 MongoDB 副本集

接下来就是重头戏了。我会用一个完整的 docker-compose.yml，带你一步步搭建一个包含主节点和一个从节点的 MongoDB 副本集。这个架构已经能覆盖读写分离和高可用的基本需求，生产环境如果节点不够，照着同样的模式扩展就行。

3.1 第一步：编写 docker-compose.yml

先给出完整的 Compose 文件，然后逐段解释关键点：

version: '3.8' networks: mongo-net: driver: bridge volumes: mongo1-data: mongo2-data: services: mongo1: image: mongo:7.0 container_name: mongo1 restart: always networks: - mongo-net ports: - "27017:27017" volumes: - mongo1-data:/data/db command: mongod --replSet rs0 --bind_ip_all --keyFile /etc/mongo-keyfile environment: - MONGO_INITDB_ROOT_USERNAME=admin - MONGO_INITDB_ROOT_PASSWORD=admin123 healthcheck: test: ["CMD", "mongosh", "--eval", "db.runCommand('ping').ok", "--quiet"] interval: 10s timeout: 5s retries: 5 mongo2: image: mongo:7.0 container_name: mongo2 restart: always networks: - mongo-net ports: - "27018:27017" volumes: - mongo2-data:/data/db command: mongod --replSet rs0 --bind_ip_all --keyFile /etc/mongo-keyfile environment: - MONGO_INITDB_ROOT_USERNAME=admin - MONGO_INITDB_ROOT_PASSWORD=admin123 depends_on: - mongo1

这个文件看起来简单，但里面有几个点不是一眼能看明白的。首先是网络配置，我让 mongo1 和 mongo2 共用一个自定义网络mongo-net，这样它们就能通过容器名mongo1、mongo2互相访问，而不是依赖易变的 IP 地址。端口映射上，mongo1 映射到宿主机的 27017，mongo2 映射到宿主机的 27018，这样宿主机上的应用可以通过不同端口访问两个独立实例。

其次是副本集名称，我在 command 里加了--replSet rs0，这个名称在初始化副本集时必须保持一致。--bind_ip_all是必须的，否则 MongoDB 默认只监听 127.0.0.1，容器外部和跨容器访问都会失败。--keyFile是副本集成员之间认证用的密钥文件路径，这个文件需要提前生成并挂载到容器里，我下面会细讲。

健康检查部分，我用mongosh --eval "db.runCommand('ping').ok"去探测 MongoDB 是否存活。注意 7.0 镜像里用的是mongosh，不是mongo，这个细节在 6.0 以下的镜像里是反过来的，别搞混。

3.2 第二步：生成 keyFile 并启动集群

keyFile 是副本集内部成员互相认证的凭证，没有它，从节点连接主节点时会报Authentication failed。生成方法很简单：

openssl rand -base64 756 > mongo-keyfile chmod 600 mongo-keyfile

这个文件的内容是一长串随机字符串，MongoDB 要求它的权限必须是 600（只有 owner 可读写），否则 mongod 启动时会直接拒绝加载。然后我在宿主机上建一个目录，比如./config，把 keyFile 放进去，接着在 docker-compose.yml 里通过 volumes 挂载到容器：

volumes: - ./config/mongo-keyfile:/etc/mongo-keyfile

注意我前面写的第一版 Compose 文件里没有挂载 keyFile，实际使用时要补上这一行，否则容器启动后会报错。原因就是 MongoDB 找不到 keyFile 文件，无法完成内部认证配置。

都配置好后，执行：

docker compose up -d

看到两个容器都处于 Up 状态后，先别急着初始化副本集，先检查日志确认 MongoDB 已经正常启动。重点看一下有没有包含waiting for connections这样的日志行，这表示 mongod 进程已经就绪。

3.3 第三步：初始化副本集并验证主从状态

进入 mongo1 容器，用 mongosh 连接本地实例：

docker exec -it mongo1 mongosh -u admin -p admin123 --authenticationDatabase admin

然后执行副本集初始化命令：

rs.initiate({ _id: "rs0", members: [ { _id: 0, host: "mongo1:27017" }, { _id: 1, host: "mongo2:27017" } ] })

这里要注意的是，host 字段必须是容器网络内可解析的地址，也就是mongo1、mongo2这种容器名，而不是localhost或者宿主机的 IP。原因在于副本集成员之间需要互相通信，它们只认 Docker 网络里的主机名。如果你填了 localhost，从节点尝试连接主节点时会连到自己的容器内部，永远连不上。

初始化成功后，执行rs.status()或者rs.isMaster()查看状态。正常情况下，mongo1 的角色是 PRIMARY，mongo2 的角色是 SECONDARY，并且stateStr字段显示各自角色。到这里，你的“MongoDB 平行宇宙”已经搭建完成了，两个独立容器、一个副本集，数据会从主节点自动同步到从节点。

接下来还有一步很关键：创建应用使用的业务账号。初始化的 admin 用户是超级管理员，日常应用不要直接用这个账号连接，应该创建一个权限更小的专用账号：

use admin db.createUser({ user: "app_user", pwd: "app_pass", roles: [ { role: "readWrite", db: "testdb" }, { role: "read", db: "readonlydb" } ] })

3.4 性能相关的关键配置

副本集跑起来只是第一步，真正拉开性能差距的是 MongoDB 引擎参数。默认情况下，mongod 会根据宿主机物理资源自动调节，但容器环境里这个自动调节经常不准，所以我建议你在 compose 文件的 command 里把核心参数写死。

第一个是 WiredTiger 缓存大小。MongoDB 默认把缓存设置为“物理内存的 50% 减去 1GB”，在容器环境里，如果宿主机内存很大但容器被限制了内存配额，这个默认值可能导致容器 OOM。所以我通常显式指定：

mongod --replSet rs0 --bind_ip_all --keyFile /etc/mongo-keyfile --wiredTigerCacheSizeGB 1

这个参数值怎么定？我的经验是设为容器可用内存的 50% 到 60%。比如容器 memory 限制为 4GB，那就写--wiredTigerCacheSizeGB 2左右，留一部分内存给 MongoDB 的连接、排序和聚合操作。

第二个是 oplog 大小。oplog 是副本集同步的核心机制，它记录了所有写操作，从节点靠它来追数据。默认情况下，oplog 的大小是可用磁盘空间的 5%，但对于写入量大的场景，这个值偏小，可能导致从节点长时间离线后追不上主节点。如果你的应用写密集，建议显式设置：

--oplogSize 1024

单位是 MB，也就是 1GB。这个值不是越大越好，因为 oplog 占用的磁盘空间不会被自动回收，设置太大浪费存储。

第三个是连接数。mongod 默认最大连接数是 65536，一般不需要改，但如果你发现容器日志里出现too many open files的报错，那大概率是宿主机或容器的文件描述符限制太小。可以在 compose 文件的 service 下加ulimits配置，或者修改/etc/sysctl.conf里的fs.file-max。

4. 性能提升原理与压测验证

架构搭好了，参数调完了，接下来要用数据说话。这一节我会从原理上拆解为什么读写分离能带来性能提升，并给出一个简单的压测思路，让你自己不靠猜也能验证效果。

4.1 200% 是怎么来的

先画一个简单的场景模型：假设你有一个单机 MongoDB，读写混合，每秒大概能处理 3000 个请求就达到瓶颈了，瓶颈点可能是 CPU，也可能是磁盘 IO。这时候你变成一主一从，写请求仍然由主节点处理，读请求通过readPreference=secondaryPreferred路由到从节点，那么理论上主节点的负载直接砍掉了一半（读流量），总吞吐量自然就上去了。

实际压测中，如果读占比是 70%，你用一主一从架构，总吞吐量大约能提升到原来的 1.7 倍左右；如果读占比 90%，接近 2 倍很正常。这就是“性能提升 200%”的数学来源。更要紧的是，从节点并不仅限于一个，如果读需求继续上涨，你可以在 compose 文件里继续加 mongo3、mongo4，把读流量分摊到更多实例上。

但这里面有个前提：你的从节点不能拖后腿。如果从节点的磁盘性能比主节点差很多，同步 oplog 追不上写入速度，那么读请求不仅快不了，反而会因为从节点数据滞后出现一致性问题。所以我建议所有副本集成员尽量用相同规格的存储和内存配置，不要搞一个高配主节点加一堆低配从节点，这种设计在 MongoDB 副本集里是大忌。

另外，连接池和批量写入是另一个容易被忽视的性能杠杆。应用端通过连接池复用连接，而不是每次请求新建连接，可以显著降低握手开销。批量写入时，MongoDB 的insertMany比循环insertOne快一个数量级，原因就在于减少了网络往返次数。这两点配合读写分离，实际上才是性能翻倍的完整拼图。

4.2 用 mongostat 和 mongosh 观察实时负载

性能优化不能靠感觉，要有数据支撑。MongoDB 自带一个轻量级的实时监控工具mongostat，在容器里可以直接通过mongosh体系执行，不过更方便的是在宿主机上安装mongodb-database-tools后使用。如果不想装额外工具，直接进入 mongosh，执行db.serverStatus()也能看到几乎全部关键指标。

我最常用的几个指标如下：

• opcounters：insert、query、update、delete的累计次数。压测前后各取一次，做差除以时间，就是每秒操作数。
• connections.current：当前活跃连接数。如果这个数值持续偏高，检查是否有连接泄漏。
• mem.resident：常驻内存。注意和 WiredTiger 的 cache 使用量区分开，前者是进程内存，后者是引擎缓存。
• metrics.document.deleted、metrics.document.inserted：文档级别的计数，可以辅助判断数据写入速率。

如果你想快速观察两个节点的负载差异，分别进入 mongo1 和 mongo2 执行db.serverStatus().opcounters就能看到各自的读写压力分布。正常情况下，mongo1 的 insert/update/delete 计数增长更快，mongo2 的 query 计数增长更快，这说明读写分离已经生效了。

4.3 用 Python 脚本做一个简单并发压测

下面我贴一个基于pymongo的简单压测脚本，它的逻辑并不复杂：一部分线程往主节点写数据，一部分线程通过readPreference=secondaryPreferred从从节点读数据，然后统计每秒完成的读请求数和写请求数。

import threading import time from pymongo import MongoClient READ_CONN = MongoClient( "mongodb://app_user:app_pass@localhost:27017,localhost:27018/?replicaSet=rs0&readPreference=secondaryPreferred&authSource=admin" ) WRITE_CONN = MongoClient( "mongodb://app_user:app_pass@localhost:27017/?authSource=admin" ) stop = False read_count = 0 write_count = 0 def write_worker(): global write_count while not stop: WRITE_CONN["testdb"]["test_collection"].insert_one({"ts": time.time()}) write_count += 1 def read_worker(): global read_count while not stop: list(READ_CONN["testdb"]["test_collection"].find().limit(10)) read_count += 1 threads = [] for _ in range(4): t = threading.Thread(target=write_worker) t.start() threads.append(t) for _ in range(8): t = threading.Thread(target=read_worker) t.start() threads.append(t) time.sleep(10) stop = True for t in threads: t.join() print(f"writes/sec: {write_count / 10}") print(f"reads/sec: {read_count / 10}")

注意这段代码只是用来对比相对差异，不是专业压测工具，不要拿它的绝对值到处说。实际对比时，你可以在单实例架构上跑同样逻辑，然后再在副本集架构上跑，对比读写吞吐量差异，这个横向对比才有意义。

我在测试中发现一个有意思的现象：单实例架构下，读写混合时读请求往往会挤占写请求的资源；拆成主从后，写请求的延迟也明显下降，因为 CPU 不用在处理写的同时还要响应大量读请求了。这个现象也从侧面说明，副本集的价值不只是“多了几个备份”，而是确实把资源隔离了出来。

5. 常见问题排查实录

这一节我整理了实战中最高频的问题，并给出排查思路和方法。这里的很多情况热词里都出现过，比如 docker desktop 启动失败、mongodb 安装失败、windows 安装报错等，我将它们合并到容器化场景下一并说明。

5.1 Docker Desktop 启动失败：virtualization support not detected

这个问题在 Windows 上出现的频率极高。报错信息通常显示Docker Desktop failed to start because virtualisation support wasn't detected，但你机器上可能已经用 VMware 或 VirtualBox 跑过虚拟机，所以觉得自己开启了虚拟化。实际上，Windows 上的虚拟化支持分为两个层面：BIOS 层面的 CPU 虚拟化，以及 Windows 功能层面的 Hyper-V/WSL2，缺一不可。

排查路径如下：

1. 打开任务管理器 -> 性能 -> CPU，确认“虚拟化”状态是否为“已启用”。
2. 如果未启用，重启电脑进 BIOS，开启 Intel VT-x 或 AMD-V。
3. 如果已启用但 Docker 仍报错，打开“控制面板 -> 程序 -> 启用或关闭 Windows 功能”，确认适用于 Linux 的 Windows 子系统和虚拟机平台两个选项都被勾选。
4. 以管理员身份运行bcdedit /set hypervisorlaunchtype auto，重启后再试。

其中第 4 步特别容易被忽略，因为 Windows 的 Hyper-V 被禁用时，Docker Desktop 即便检测到 CPU 虚拟化也无法正常启动。

5.2 MongoDB 容器连不上：Connection refused

容器起来了，日志也显示waiting for connections，但宿主机上用客户端连接就是报Connection refused，这个情况十有八九是端口映射和绑定地址的问题。

首先确认容器是否真的在运行：docker ps，然后再看端口映射：docker port mongo1。如果端口映射正常，但 MongoDB 只监听了 127.0.0.1，你从宿主机访问时会失败。MongoDB 6.0 之后，默认配置下 mongod 只监听本机回环地址，这是出于安全考虑，但在容器里需要显式用--bind_ip_all或--bind_ip 0.0.0.0来放开监听。这也是我在 compose 文件里加--bind_ip_all的原因。

还有一个容易踩的坑是云服务器安全组或宿主机防火墙。即使容器配置全对，如果防火墙没放行 27017 端口，外部机器依然连不上。你可以先用telnet 127.0.0.1 27017在宿主机本地测试，确认端口可达，再逐步排查网络链路。

5.3 副本集认证失败：Authentication failed

副本集成员之间通过 keyFile 认证后，如果你发现从节点日志里反复出现Authentication failed，先检查 keyFile 的权限和内容。keyFile 要求权限为 600，如果不是，mongod 不会启动或不会加载它。另外所有副本集成员的 keyFile 内容必须完全一致，我见过有人分别在两台机器上执行openssl rand -base64 756生成不同的 keyFile，导致同步失败。

应用连接时报认证失败，最常见的原因是连接串里没写authSource=admin。MongoDB 中用户是建立在特定数据库下的，默认认证库是admin，如果你的用户建在admin库，但连接串没指定认证库，mongod 会默认去尝试连接串中第一个数据库进行认证，结果自然失败。正确的连接串格式应该类似：

mongodb://app_user:app_pass@localhost:27017,localhost:27018/?replicaSet=rs0&readPreference=secondaryPreferred&authSource=admin

5.4 数据持久化与备份防丢

有人会在容器里直接用docker run mongo，不挂载任何数据卷，然后写了一些测试数据，结果发现容器一被删，所有数据都没了。原因很简单：/data/db没有挂载任何 volume，数据写在容器的可写层里，容器删除后可写层也被清理。

这是一个非常基础但危害极大的坑。正确的做法是至少用 named volume 或将宿主机目录挂载进去。我强烈建议用 named volume 而不是宿主机目录，因为在 Linux 上宿主机目录的权限如果不对，mongod 会因为无法写入数据目录而启动失败。named volume 由 Docker 管理，权限问题基本不存在。

备份方面，最直接的工具是mongodump。备份命令：

docker exec mongo1 mongodump --uri="mongodb://admin:admin123@localhost:27017/?authSource=admin" --out=/dump docker cp mongo1:/dump ./backup

恢复时用mongorestore。在副本集架构下，备份建议在从节点上执行，这样可以不干扰主节点性能。

5.5 热词里那些安装报错：the installer has encountered an unexpected error

有部分热词来自 Windows 本地直接安装 MongoDB 的报错，例如the installer has encountered an unexpected error。如果你打算在 Windows 上直接装 MongoDB，我的建议是放弃这条路，直接改用 Docker 跑。原因很简单：Windows 原生安装 MongoDB 不仅踩坑概率高，而且安装后的服务管理和版本升级都很麻烦。相比之下，Docker Desktop 里的 MongoDB 容器能避开绝大多数 Windows 平台原生环境依赖问题。

如果你执意要装原生版，这个报错往往是你电脑上已经装过 MongoDB Compass 或其他相关组件，导致安装程序冲突。解决办法通常是卸载全部 MongoDB 相关程序，清理C:\Program Files\MongoDB目录和注册表残留，再重新安装。但真的，这条路的性价比远不如 Docker。

5.6 镜像下载慢的补充排查

前面我讲了配置镜像加速器，但如果你配置了依然很慢，可以试试直接在 Dockerfile 或 compose 中使用具体版本的镜像，比如mongo:7.0-jammy，有时候特定标签的镜像已经存在于本机或其他节点，能走本地缓存。另外，如果你在公司网络环境下，某些公共镜像源可能被限制，这时候可以换一个加速源试试。我给的配置里包含了多个加速源，Docker 会按顺序尝试，总有一个能通。

结尾再聊几句实在的

三步骤搭建 MongoDB 平行宇宙，真正跑通一遍之后，你会发现难点不在 compose 文件本身，而在那几张容易被忽略的小配置上：keyFile 的权限、容器网络内的主机名、WiredTiger 缓存大小的显式指定。我自己踩过不少坑，第一次搭副本集的时候，因为没挂载 keyFile，从节点日志刷了几百行 Authentication failed；还有一次因为端口映射写错，应用连接串对着两个端口折腾了大半天。这些经验写出来，就是希望你能一次少走几小时弯路。

最后再分享一个小技巧：不要在生产环境里用默认参数启动 MongoDB 容器。哪怕你只加两个参数--wiredTigerCacheSizeGB和--oplogSize，都比裸启动稳定得多。默认参数是为通用场景设计的，但在容器这个有限资源环境里，显式声明往往是最安全的选择。参数怎么定，记住一个简单原则：内存留一半给系统和应用，oplog 按写入峰值评估，写到日志里看到经常刷满再调大也不迟。