应使用服务名（如mongodb）而非localhost连接同网络容器，因Docker内置DNS自动解析；需确保服务同属自定义网络、启用认证时URI包含凭据，并在应用层实现连接重试以应对启动顺序问题。
直接用 mongodb://localhost:27017 在容器里基本必连不上——因为容器的 localhost 指向自己，不是宿主机，更不是同网络下的 MongoDB 容器。
docker-compose 中用服务名当 host 最稳
这是最推荐、最符合 Docker 网络模型的做法。Docker 会自动为 docker-compose.yml 里定义的每个服务名创建 DNS 记录，同一自定义网络内的容器可直接用服务名通信。
- 确保 MongoDB 和 Node.js 应用在同一个自定义网络（默认就是）
- 在
docker-compose.yml中把 MongoDB 服务命名为mongodb，Node.js 服务里就用mongodb://mongodb:27017/yourdb - 不要加
--network=host，它会绕过 Docker 内置 DNS，反而让服务名失效 - 如果 MongoDB 启用了认证，记得在 URI 中带上用户名密码：
mongodb://root:password@mongodb:27017/yourdb
单容器启动时用 --add-host 或 --network=container:xxx
不写 docker-compose 时，--add-host 是最干净的替代方案；而 --network=container:xxx 适合调试，但有耦合风险。
-
--add-host=mongodb:172.17.0.2：手动指定 MongoDB 容器的 IP（用docker inspect mongodb | grep IPAddress查），适合临时测试 -
--network=container:mongodb：让 Node.js 容器共享 MongoDB 容器的网络命名空间，此时localhost就真指向 MongoDB ——但两个进程共用端口，不能同时监听 27017，仅限快速验证 - 避免用
--network=host：它会让容器直接使用宿主机网络，localhost虽然能通宿主机上的 MongoDB，但会丢失容器间 DNS 解析能力，且端口冲突风险高
别碰 host.docker.internal，除非你确定宿主机是 macOS/Windows
host.docker.internal 是 Docker Desktop 为 macOS 和 Windows 提供的特殊 DNS 名，Linux 上默认不存在，硬写会导致跨平台部署失败。
- Linux 用户必须显式启用：
docker run --add-host=host.docker.internal:host-gateway ... - 即使启用了，它也只指向宿主机，不能解决「Node.js 容器 → 同一 compose 网络里的 MongoDB 容器」这类场景
- CI/CD 流水线或生产服务器多为 Linux，依赖这个名等于埋雷
真正容易被忽略的是：MongoDB 容器启动顺序和连接重试。Mongoose 的 connect 默认不重试，Node.js 容器常因 MongoDB 还没 ready 就报错退出。务必在代码里加连接重试逻辑，或者用 depends_on + 自定义健康检查兜底。
