企业官网建设流程全解析

做资讯类客户端的学习项目时，本地起一个 Redis 做缓存和热榜数据几乎是标配。我最近就在这类项目里反复看到同一行报错：docker: Error response from daemon: Conflict.——第一次遇到时我还以为是镜像有问题，折腾半天重装 Docker，结果发现旧容器一直躺在那儿没删。后来把这类报错的各种变体都踩了个遍，才总结出一套比较稳的排查顺序。这篇就把我踩过的坑、用到的命令、以及最后落到项目里的防冲突做法一次讲清楚：Conflict 到底在冲突什么、6379 端口被谁占了怎么快速定位、几种修法各自的代价、以及一套真正每天都会用到的 Docker 命令清单。适合刚上手容器、本地环境经常“起不来”的朋友，也适合已经在做项目、想把本地开发环境管得更干净的人。

1. Conflict 报错的三张面孔：先分清你撞的是哪一个

很多人看到Conflict就开始乱试，其实这行字只是一个“终点”，真正的信息在后面那半句。Docker 的报错习惯是：前面是通用前缀，后面才是具体原因。所以第一件事不是敲命令，而是把完整报错读完。同样是 Conflict，背后可能是完全不同的三件事，处理方式差别很大。

1.1 端口已经被别的容器或宿主进程占住

最常见的一种，完整报错长这样：

docker: Error response from daemon: driver failed programming external connectivity on endpoint redis-test (...): Bind for 0.0.0.0:6379 failed: port is already allocated.

注意关键词port is already allocated。它的含义很明确：Docker 已经在宿主机的 6379 上做不了端口转发，因为这个端口被别人拿走了。拿走它的人有两种可能——另一个还在跑的容器，或者宿主机上直接装的一个 Redis 服务。

这里有个认知点值得说清楚：-p 6379:6379中的前半段是宿主端口，后半段是容器内端口。容器内部再干净、镜像再新，只要宿主机那半边被占了，容器就起不来。Docker 的端口映射本质是在宿主机上监听一个 socket 然后转发，和普通进程抢端口是一回事，所以“容器隔离”这件事在端口这一层是不成立的。

顺带说一句，Linux 上如果端口被占用得比较彻底，有时候报错会变成address already in use；这两种提示指向的是同一类问题，只是发生在不同的处理阶段，看到哪个都先往端口方向想。

1.2 容器名一模一样，旧容器还没清掉

第二种，报错是：

docker: Error response from daemon: Conflict. The container name "/redis" is already in use by container "3f8a1c...". You have to remove (or rename) that container to be able to reuse that name.

这个提示其实已经把答案写全了：名字被占。Docker 里容器名是全局唯一的，--name redis用过一次，只要那个容器还在（哪怕已经 Exited 停止状态），这个名字就不能再用。

这个坑的隐蔽之处在于，停止的容器在docker ps里是看不见的，因为它默认只列运行中的容器。很多人docker ps一看啥都没有，就断定环境是干净的，然后反复执行docker run，每次都撞同一堵墙。我第一次踩的时候还怀疑过是 Docker Desktop 出了 bug，重启了两回。

我的经验是，凡是要用--name显式命名的容器，验证时一律用docker ps -a，别用docker ps。这两个命令的差别不是可选项，是排错的第一道分水岭。

1.3 网络别名、卷、挂载点也会抛 Conflict

第三种出现频率低一些，但也确实会撞上，尤其是项目里用了自定义网络或 compose 之后。典型场景有两类：

一是网络别名冲突。在自定义 bridge 网络里，多个容器起同一个 alias 时，Docker 会拒绝，因为 DNS 解析会出现歧义。报错里通常会带endpoint with name xxx already exists in network yyy。

二是卷挂载相关的冲突。同一路径被两个容器以不兼容的方式挂载，或者 compose 里定义的命名卷已经存在但属性对不上，也会在启动阶段被拦下来。这类报错的共同特征是：报错文本里一定会出现具体的网络名、卷名或路径名，而不是简单的port is already allocated。

所以我在团队里推的一条小规则是：看到 Conflict，先按报错后半句对号入座，再动手。对不上号的，直接docker inspect去查那个被点名的对象，别猜。

2. 揪出6379的占用者：一条可复现的排查链路

知道有哪三种冲突之后，回到标题里的具体场景：拉 Redis、映射 6379 失败。我现在的排查顺序基本固定，三层往下走，一般到第二层就有结论了。

2.1 第一层：docker ps -a 里是不是还躺着一个redis

第一条命令永远是这条：

docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}"

用--format而不是直接docker ps -a，是因为默认输出太长会换行，端口那列常常被截断，看得很累。用模板把名字、镜像、状态、端口四列拉出来，一眼就能扫到有没有 redis 相关的容器，它现在是 Up 还是 Exited，有没有占着 6379。

如果发现一个 Exited 的redis容器，基本可以锁定是 1.2 节说的名字冲突；如果发现一个 Up 状态的容器，Ports 列显示0.0.0.0:6379->6379/tcp，那大概率就是它在占端口。

还有一条更直接的命令，专治“谁占了这个端口”：

docker ps -a --filter "publish=6379"

publish过滤的是宿主端口映射，直接把所有映射了 6379 的容器筛出来。这个过滤器知道的人不多，但非常好用，尤其是在容器数量多的时候，比肉眼扫表格可靠得多。

2.2 第二层：宿主端口探测与进程反查

如果容器层是干净的，那占用者就在宿主机上。这一步要看系统。

Linux 下我习惯用：

ss -lntp | grep 6379

ss比netstat快，也基本是现在发行版的标配。输出里会带进程名和 PID，能直接看到是redis-server还是别的什么东西。如果系统上没有ss，退一步用netstat -tulnp | grep 6379或者lsof -i :6379，效果一样。

macOS 上ss是没有的，用：

lsof -nP -iTCP:6379 -sTCP:LISTEN

-nP的作用是不做域名和端口名的解析，输出更快更干净。少了这两个参数，命令有时会卡几秒种在反向解析上，急性子容易被误判成“卡死了”。

Windows 下：

netstat -ano | findstr :6379 tasklist /FI "PID eq 12345"

先拿 PID，再用tasklist反查进程名。这两步要连着做，因为 Windows 下 PID 复用比较常见，隔太久再查可能已经换成别的进程了。

这里有个细节值得单独提一下：ss或netstat只显示监听中的端口。如果端口被某个进程以TIME_WAIT之类状态占着，可能会看到端口“没被监听但也绑不上”。这种情况一般等一会儿自己就好了，或者干脆换个端口，不用深究。

2.3 第三层：确认占用者身份之后再决定处置方式

拿到占用者之后，别急着 kill。先判断它是谁，再决定动不动它。

这张表看着简单，但它救过我一次。当时一个同事看到 6379 被占，反手一个kill -9，结果干掉的是另一个项目的生产数据同步程序。端口号是公共资源，撞上是常事，处置之前多问一句“这是谁的”，比事后解释便宜得多。

3. 三种处置方案的取舍：换端口、清旧容器、走容器网络

定位完之后就是选方案。同一个问题至少有三种解法，各有各的代价，我按自己的使用频率从高到低排。

3.1 换宿主端口：改一个数字，但埋下配置漂移的隐患

最快的一招，把宿主端口换掉：

docker run -d --name redis-demo \ -p 6380:6379 \ -v redis-demo-data:/data \ redis:7-alpine

容器内的 6379 不动，只把宿主侧换成 6380。好处是不用碰任何已有服务，风险最低。

但代价要算清楚：应用的连接配置得跟着改。项目的application.yml、本地.env、同事的启动脚本、甚至某些写死在测试用例里的连接串，都得同步。改一处漏一处，最后表现为“我本地能连、他本地连不上”，排查成本远超当初省下的那几分钟。

我的做法是：只有在占用者明确是别人的、不能动的时候才换端口，而且换了之后立刻把端口写进项目 README 的本地环境那一节，或者直接放到.env里由 compose 读取，避免端口号散落在多个文件里：

# .env REDIS_HOST_PORT=6380

ports: - "${REDIS_HOST_PORT}:6379"

这样换端口就是改一行的事，不需要满仓库搜索替换。

3.2 停掉并删除旧容器：最干净，但要守住数据卷

如果占用者就是自己之前留下的测试容器，正确做法是清掉它：

docker stop redis-test docker rm redis-test

或者一步到位：

docker rm -f redis-test

-f相当于先发 SIGKILL 再删，对于本地测试容器完全可以接受，省一步。但要注意：docker rm删的是容器，不删数据卷。如果你当初用的是命名卷或 bind mount，数据还在，重新run时挂上同一个卷就能恢复。

反过来，如果你压根不要旧数据了，那还得顺手清卷：

docker volume ls | grep redis docker volume rm redis-demo-data

这一步要格外小心。docker volume rm是不可逆的，删之前先docker volume inspect看一眼 Mountpoint，确认是不是你以为的那个目录。我见过有人为了“清干净”直接跑docker system prune --volumes，结果把另一个项目还没备份的数据库卷一起带走了。

提示：docker system prune -a --volumes这类命令在个人机器上都很危险，在多人共用的开发机上基本属于禁用操作。清理类命令每次执行前，先用--dry-run思路过一遍：把命令里的prune换成ls，先看看会删掉什么。

3.3 让容器之间直接对话：从根源上绕开宿主端口

如果 Redis 只是给项目里的其他容器用的，比如应用容器要连它做缓存，那压根不需要把 6379 暴露到宿主机。这是我后来最喜欢的方式：

services: cache: image: redis:7-alpine command: ["redis-server", "--appendonly", "yes"] # 不写 ports，只在内部网络可达 app: build: . environment: REDIS_HOST: cache REDIS_PORT: 6379

同一个 compose 网络里，服务名就是主机名，cache直接能被解析成容器 IP。这样宿主机上 6379 是不是被占，跟这个项目一点关系都没有，冲突问题从根上消失了。

代价是你在宿主机上没法用本地客户端直接连进去看数据了。我的折中做法是：平时不暴露端口，需要调试时临时用docker exec进去：

docker exec -it demo-cache-1 redis-cli

或者实在需要图形化工具，临时起一个端口映射的旁路容器，用完就删。这样既保持了环境干净，又不影响调试体验。

4. 日常真正用得上的 Docker 命令分层清单

标题里带了“常见命令总结”，但我不打算把所有命令列一遍——docker --help比任何清单都全。我按“什么时候用哪一组”来分，这样记起来有场景锚点，不容易忘。

4.1 生命周期类：run、start、stop、restart、rm

这一组是每天都要敲的，重点不在命令本身，而在几个容易混的边界。

最关键的一条认知：容器创建时的参数是固化的。你用-p 6379:6379建了容器，后面想改端口，docker start改不了，docker restart也改不了，只能删了重建。这就是为什么我后来一律用 compose 管理，改配置直接docker compose up -d，它会自己判断要不要重建。

docker run还有几个我常用的参数，值得单独记住：

docker run -d --name redis-demo \ --restart unless-stopped \ -p 6379:6379 \ -v redis-demo-data:/data \ redis:7-alpine redis-server --appendonly yes

-d后台运行；--restart unless-stopped让容器跟随 Docker 服务自启，本机开发很实用；-v挂数据卷；镜像后面跟的是覆盖容器默认启动命令的参数，这里顺手开了 AOF 持久化。最后这一招比改配置文件方便，适合临时验证。

4.2 取证类：logs、inspect、stats、top

容器起来了但用不了的时候，这四个命令是我排查的主力。

docker logs是第一站，加上-f持续跟踪，加--tail 100只看看最后一段，避免日志刷屏：

docker logs -f --tail 100 redis-demo

Redis 启动失败常见的原因是配置文件写错、数据目录没权限。日志里会直接告诉你它读的是哪个路径、卡在哪一行，比瞎猜快得多。

docker inspect是信息量最大的一个，但直接敲会吐出一大坨 JSON。我一般配合--format只取关心的字段：

# 看容器 IP docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' redis-demo # 看端口映射 docker inspect -f '{{json .NetworkSettings.Ports}}' redis-demo # 看退出码 docker inspect -f '{{.State.ExitCode}}' redis-demo

退出码这个特别有用。容器起来立刻退出，docker ps -a只显示 Exited，看不到原因，但退出码能给出方向：1 一般是应用自身报错，137 是被 SIGKILL（常见于内存不足被系统杀），143 是收到 SIGTERM 正常退出。对着退出码查，比翻日志效率高。

docker stats看实时资源占用，docker top看容器内的进程列表。这两个排查“容器活着但不干活”的场景很有用——比如 Redis 的maxmemory设太小，你会看到内存一直贴着上限跑然后疯狂淘汰 key。

4.3 端口与网络类：port、network ls、network inspect

端口相关的三个命令，我用得最多的是第一个：

# 查某个容器实际映射到了宿主哪个端口 docker port redis-demo # 输出示例：6379/tcp -> 0.0.0.0:6379

当你不确定当初-p是怎么写的，用它一查就知道。尤其是用了随机端口-p 6379的时候，宿主端口是 Docker 分配的，只能靠docker port问出来。

网络排查这块，容器之间连不通，先看它们在不在同一个网络：

docker network ls docker network inspect demo_default --format '{{range .Containers}}{{.Name}} {{end}}'

inspect后面那段模板是列出该网络里的所有容器名。如果两个服务互相连不上，八成是其中一个被单独docker run起在了默认 bridge 网络，另一个在 compose 的自定义网络里，两个网络不互通。

4.4 清理类：prune 系列命令的杀伤半径

清理命令我单独拎出来讲，因为它是最容易造成不可逆损失的。

我的习惯是：prune之前一定先ls看一眼。比如要清卷，先docker volume ls，确认列表里没有还在用的业务数据卷——注意volume prune只删“未被任何容器引用”的卷，听起来安全，但一个刚被docker rm掉的容器留下的卷，正好符合“未被引用”这个条件。

docker image prune单独说一下：不加-a只清 dangling 镜像，也就是那些<none>标签的中间层，很安全，可以定期跑。加了-a会把所有没被容器引用的镜像都删掉，包括你特意留着备用的旧版本，下次构建就得重新下载基础镜像，网络不好的时候很痛苦。

5. 把防冲突做进项目：compose 与启动脚本的工程化处理

排查是个事后动作，真正省时间的是事前设计。这一节是我从反复踩坑里总结出来的，落到项目里的三件事。

5.1 compose 文件里的命名、端口与重启策略

一个本地开发用的 compose 文件，我会固定写这么几项：

services: cache: image: redis:7-alpine container_name: demo-cache ports: - "${REDIS_HOST_PORT:-6379}:6379" volumes: - cache-data:/data command: ["redis-server", "--appendonly", "yes"] restart: unless-stopped volumes: cache-data:

几个细节值得解释。

container_name我倾向于写死，因为本地开发就一个实例，固定名字方便敲docker exec和看日志。副作用是它会绕过 compose 的自动命名，多个项目同时用一个名字就会撞——所以名字里带上项目前缀，demo-cache这种。

${REDIS_HOST_PORT:-6379}是带默认值的变量写法，.env里没配就用 6379。这样默认情况下配置一致，遇到端口冲突的同事只需要在自己本地.env里加一行REDIS_HOST_PORT=6380，不用改代码也不用改 compose 文件，更不会误提交到仓库。

更彻底的做法是干脆不写ports，只在需要宿主机访问时才开。前面 3.3 节讲过，这是我最推荐的默认状态。

5.2 启动脚本前置检查：先把脏环境扫一遍

团队里环境不一致，光靠文档约束不住。我一般会在项目根目录放一个小脚本，本地起服务前先跑一遍：

#!/usr/bin/env bash set -euo pipefail PORT="${REDIS_HOST_PORT:-6379}" # 1. 检查同名容器 if docker ps -a --format '{{.Names}}' | grep -qx "demo-cache"; then echo "容器 demo-cache 已存在，尝试重建..." docker rm -f demo-cache >/dev/null fi # 2. 检查宿主端口 if command -v ss >/dev/null 2>&1; then if ss -lnt | grep -q ":${PORT} "; then echo "端口 ${PORT} 已被占用，请检查占用进程或改用其他端口" exit 1 fi fi docker compose up -d cache

这段脚本没有多高明，但它把前面几节讲的排查逻辑固化成了机械动作。set -euo pipefail保证出错就停，避免半路失败还继续往下跑；grep -qx精确匹配容器名，防止demo-cache-1误匹配成demo-cache。

注意脚本里的端口检查只在有ss的系统上做，macOS 没有ss就跳过。这里我选择了“降级但不阻断”，因为在 Mac 上装lsof解析的开销反而更高，而且 Docker Desktop 会自己做一层端口探测，冲突时给的报错也足够清楚。

5.3 多人协作时的端口约定与文档化

端口这东西，一个人的机器上是私事，一个团队里就是契约。我参与的协作项目里，会在 README 里维护一张表：

规则很简单：默认用标准端口，撞了就往后挪到 1xxxx 段，并且在.env里改，绝不改代码。1xxxx 这个选择不是随便定的——高位端口被系统服务占用的概率低得多，不容易再撞第二回。

还有一个容易被忽略的点：文档里要写清楚“换端口之后哪些地方要跟着改”。我们项目里 Redis 的连接信息只在.env出现一次，由 compose 和应用配置同时读取，所以只需要改一处。如果换成配置散落的情况，这张表的意义就大打折扣了。

6. 冲突解决了却连不上：几类二次踩坑

端口问题解决、容器 Up 起来了，故事并没有结束。后面还有几种情况会让你怀疑人生。

6.1 端口映射成功但客户端连不通的几种典型

容器Up、docker port显示映射正确，但本地客户端连上去超时或被拒。我遇到过三种原因。

第一种是 Redis 自身的protected-mode和bind配置。容器里的 Redis 如果只监听127.0.0.1，那么从宿主机通过端口映射进来是连不通的，因为请求到了容器内部，目标地址已经变成容器的本地回环之外的地址。验证方法很简单，先确认容器内部自己是通的：

docker exec -it demo-cache redis-cli ping

内部返回 PONG，外部连不上，那就往bind和protected-mode的方向查。修复方式是在启动命令里显式指定：

docker run -d --name demo-cache -p 6379:6379 redis:7-alpine \ redis-server --bind 0.0.0.0 --protected-mode no --appendonly yes

注意：本地开发图方便可以关protected-mode，但这只是本地环境。任何对外可达的环境都必须设密码并保持保护模式开启，这是底线。

第二种是连接串写错。localhost和127.0.0.1在某些客户端库里走的解析路径不同，一个走 IPv6 的::1，一个走 IPv4。宿主机映射通常只监听 IPv4，于是localhost解析到::1就连不上。我一般的处理是：应用配置里一律写127.0.0.1，不写localhost。这个习惯是从无数次“同事能连我不能连”里练出来的。

第三种是容器根本没在监听。这时候docker logs里一般能看到类似 “Ready to accept connections” 之外的信息，比如配置解析失败、持久化文件损坏。我遇到过因为挂载了旧的 AOF 文件、格式对不上导致 Redis 启动后立刻退出的情况，日志里会明确报出文件格式问题，按提示删掉旧文件重新生成即可。

6.2 旧数据卷带回来的配置残留

这个问题很阴。你删了容器、重建了容器、端口也换了，结果行为还是老样子。原因是数据卷还在，里面躺着上次的 RDB 或 AOF 文件，容器一启动就把这些数据加载回来，甚至连带着一些过期的 key 一起复活。

排查路径很直接：

docker volume inspect demo_cache-data

看Mountpoint指向的宿主目录，进去看有没有dump.rdb或appendonly.aof。如果有，而你不想要旧数据，把卷删掉重建即可。

我现在给测试环境起的 Redis，一律在容器名或卷名里带日期或用途后缀，比如demo-cache-dev和demo-cache-test分开，避免两个环境的数据互相污染。这个习惯看似啰嗦，但它省掉的“为什么我的测试数据没了”的讨论，价值远超这点命名成本。

6.3 不同宿主系统上的表现差异

同一个 compose 文件，在 Linux、macOS 和 Windows 上表现是有差别的，尤其是端口这块。

Docker Desktop 在 macOS 和 Windows 上跑在一个轻量虚拟机里，端口映射要经过两层转发。所以有时候宿主机ss/netstat看不到 6379 被监听，但容器仍然连不通，因为虚拟机的网络层出了问题。这种情况重启 Docker Desktop 比查日志快。我在 Mac 上遇到过一次，容器日志一切正常，docker port也正常，但端口死活连不上，重启 Docker 服务后立刻恢复。

Linux 上则没有这一层，但要注意权限：低于 1024 的端口需要 root 或CAP_NET_BIND_SERVICE才能绑定。所以如果你的映射写成-p 80:6379，在 Linux 上普通用户跑docker run可能直接失败，而 Docker Desktop 因为内部有代理层，往往能过。这也是我建议宿主端口一律用高位端口的重要原因之一。

另外一个差异是文件系统性能。bind mount 在 macOS 和 Windows 上跨文件系统同步，IO 性能明显比 Linux 差。Redis 开了 AOF 之后如果挂的是 bind mount，写入延迟会比在 Linux 上高不少。本地开发感受不明显，但如果你的测试依赖时序，可能会因此出现偶发的超时。这种情况我一般直接换命名卷，用docker volume管理，性能稳定很多。

最后分享一个我长期保留的习惯：本地开发环境里，凡是容器名、端口、卷名这三样，能显式写清楚就绝不留默认。默认值看起来省事，但出问题的时候，那串随机生成的容器 ID 和自动分配的端口，会让排查时间成倍增加。踩过几次“冲突—重装—还是冲突”的循环之后，我现在拉起任何服务之前，都会先花十秒跑一遍docker ps -a和端口探测，确认环境是干净的再动手。这十秒，通常能省掉后面半小时。