这两周知乎有个很有意思的现象。
一个问题，「docker真的好难用啊，为什么说它移植性好啊？」，330万阅读。高赞回答是一位运维的反驳：你让运维用 Docker 部署项目，人家表示这是基操；你让运维天天 git 拉代码、手动改配置、跑命令行部署，人家才会找你喝茶，因为一次解决就永久解决的，都不叫事。知乎
另一个问题，「现在都在说Docker好，那它有什么弊端吗？」，290多万阅读。高赞回答是泼冷水的，说容器默认的隔离其实是假象，看起来隔离、实际不隔离。知乎
更有意思的是那个经典老问题「为什么不建议在Docker中跑MySQL？」，405万阅读，但2800多赞的最高赞回答是阴阳怪气派：建议啊，没什么不可以容器化的，家里连纸巾都是跑在container里。知乎
骂它的和捧它的都有百万级声量，这工具到底值不值得继续投入？我把这几个百万级问答、B站相关视频和评论区都翻了一遍，把大家实际踩的坑归成了四类。先说结论：四类里三类能绕开或有解，只有一类是 Docker 强大的代价，得长期共存。
第一类：环境摩擦——2026年基本已经解决
吐槽最多、也最表层的一类：Windows 上装起来麻烦、吃内存、镜像拉不动。
这些曾经是真实痛点：Windows 跑 Docker Desktop 要起一个虚拟机，内存一吃就是几个 G；国内网络下拉个官方镜像，运气不好能失败一上午。
但如果你 2026 年还在为这些骂 Docker，信息确实需要更新：
Docker Desktop 六月初的大版本引入了 Resource Saver 模式，容器闲置时后台虚拟机会把物理内存还给宿主机，按相关测试的说法自身内存内耗能降六成以上。知乎嫌它吃内存的，先升级到新版再骂。
微软在 Build 2026 发布了 WSL 原生容器工具 wslc，免费、随 WSL 自带、命令语法和 Docker 基本一致，Windows 上跑容器可以完全不装 Docker Desktop。哔哩哔哩目前是公测状态，还不支持 Compose，多容器编排先别指望，但单容器开发测试已经能跑。知乎
镜像源这块没有一劳永逸的答案，只有一个残酷事实：加速地址的死亡率非常高。之前站内实测过 26 个国内加速地址，18 个已经失效，真正能用的只有 3 个。拉不动镜像时别急着换工具，先确认你的源还活着。
结论：这一类「难用」，大部分是过期信息。
第二类：概念门槛——最难熬，但一次搞懂永久解决
这是真正的重灾区，社区里的典型样本基本都长这样：
「容器明明启动了，服务却访问不到」——depends_on 只管启动顺序，不管就绪。数据库进程启动了，不等于它准备好接受连接，应用连不上数据库直接报错退出，得配 healthcheck 才算完整。知乎
「改了一行代码，docker build 就要从头跑一遍」——镜像是分层缓存的，Dockerfile 里指令顺序决定缓存命不命中。先 COPY 代码再装依赖，每次构建依赖都得重新下载，一杯咖啡喝完还没构建完。
「容器删了，数据也没了」——容器文件系统跟着生命周期走，要留数据必须挂卷。
「两个容器互相 ping 不通」——默认 bridge 网络和自定义网络的 DNS 解析行为不一样，「docker run -p 8080:80 一把梭」跑通了，不代表你懂了网络。知乎
这些问题的共同点：不是操作难，是理解难。Docker 本质上就是被打包的 Linux 进程，网络、挂载、分层全都沿用 Linux 的逻辑，只是把很多原本要手动做的事抽象成了命令参数。概念通了，坑就永远消失——那位运维说的「一次解决就永久解决」，指的就是这类。
第三类：工程习惯之争——没有对错，只有场景
争议最大的一类：数据库该不该跑容器里。
405万阅读的问题下，两派吵了很多年。反对派的顾虑是性能损耗、数据安全、排查复杂；支持派回怼：那点性能损失可以忽略，迁移备份直接把卷目录搬走就行。
两边都对，因为说的是不同场景：
开发、测试、演示、个人项目——放心跑容器。一条命令起，一条命令删，环境干净，这才是容器的甜蜜区。
生产核心数据库——主流选择仍然是裸机或云数据库。不是容器绝对不行，而是出错代价太高，没必要给自己多垫一层。
部署习惯也一样。有人觉得 Docker 部署是解放，有人说它把「改配置」变成了「管镜像」。这取决于你的规模和发布频率：单人项目一个月发一次版，真不必为了容器化而容器化；多环境部署、团队协作，那这些「麻烦」就是值得付的门票。
第四类：固有代价——解决不了，只能管理
那个290万阅读的问题里，最扎心的回答是关于安全的。
容器和宿主机共享同一个内核，namespace 和 cgroups 是资源管理工具，不是安全边界。翻译一下：容器里默认就是 root，而这个 root 离宿主机 root 只隔着一层「看起来存在」的玻璃纸。三条经典逃逸路径——特权模式（–privileged）、挂载 docker.sock、内核漏洞——每一条都有真实案例。今年就有一起 docker cp 触发的逃逸 CVE 被公开复现，Docker Engine、Docker Desktop、Docker Sandboxes 三条产品线全中招。知乎
这不是坑，是代价。Docker 轻量，正是因为它不虚拟化内核。这类问题没有「解」，只有管理：不给不明来源的容器特权，不挂载 docker.sock，版本保持更新。觉得隔离不够硬的重活，本来就该交给虚拟机。
到底谁不用 Docker？
翻完这些样本，我觉得有三类人确实不用碰：
单机脚本党。任务跑完就结束的事，写个脚本就行，容器化纯属自找麻烦。
为了学而学的人。说不出 Docker 能帮你解决什么具体问题，就先别学。那个220万阅读的「各位都在用Docker跑些什么」问题里，真实答案全是从需求出发的：自建云笔记、证书自动续期、爬虫程序。知乎都是先有「我要干这件事」，才轮到 Docker，顺序反了就会学得很痛苦。
单一服务稳定运行的人。裸机跑得挺好、一年发一次版，没有折腾的必要。
反过来，三类人应该马上用：同一份代码要部署到多个环境的、自建站和 NAS 玩家、需要统一开发环境的团队。对这三类人，Docker 的坑值得踩穿。
决定要学，给你一条最小路径
别从背命令开始，从跑起来开始：
第一步，docker run 起一个 nginx，搞清楚端口映射和容器的生死。
第二步，只学两个概念：挂载（数据放哪）和网络（容器之间怎么说话）。这是全部坑里密度最高的两块，各花一小时搞懂，能省后面几十个小时。
第三步，再碰 Dockerfile 和 Compose，此时你已经不会被「构建慢」「起不来」这种问题吓退了。
Docker 难用吗？难用的那部分，一半是过期信息，一半是没被解释清楚的概念。真正的判断标准从来不是它难不难，而是你有没有一个「非它不可」的场景。有，就值得；没有，让它躺着就好。
