个人项目用 Docker 是不是过度设计

2026-09-10 Docker,容器化,个人项目,部署运维

我那个简笔画画板，纯前端、零运维，两天写完，从头到尾没碰过容器。个人项目用 Docker 是不是过度设计，我的判断是：看你一年部署几次。一次两次，它是负担；经常部署或者环境复杂，它才回本。

我不想讲概念，直接列我自己会看的四个维度。

一、个人项目用 Docker 是不是过度设计，先看四个维度

| 维度 | 用 Docker | 不用 Docker |

|------|-----------|-------------|

| 首次搭建成本 | 要写编排文件、调镜像，第一次投入明显更高 | 装好运行环境就能跑 |

| 环境一致性 | 本地和线上基本一致，少一类「我这儿能跑」的问题 | 靠手工对齐，换机器要重来一遍 |

| 排错难度 | 多一层，日志和网络要看两处 | 直接在机器上查，路径清楚 |

| 长期维护 | 依赖和升级集中管理，多个服务时省事 | 服务一多就容易互相污染 |

这四行里只有第一行是确定的成本，其余三行取决于你的项目长什么样。别拿别人的收益来替自己做决定。

不用 Docker 适合这类项目：只有一个服务、依赖简单、部署频率低、出问题自己能上机器查。

我那个画板就是这个类型。它几乎没有后端依赖，部署动作就是把静态文件放上去，引入容器只会多一个需要维护的东西。

用 Docker 适合另一类项目：依赖装起来麻烦、需要在多台机器上跑出一样的结果、或者有多个服务要一起起。

这种情况下手工对齐环境的成本会反复出现，容器把这件事一次解决掉，后面每次部署都省力。

还有第三种做法，很多人忽略了：只把最难装的那部分容器化。

比如数据库或者需要特定版本的工具链，用容器跑；自己的服务直接跑在机器上。这样既解决了环境难对齐的问题，又没把整套部署都套进容器里。

我个人偏向这个做法，因为它把复杂度花在真正难的地方。而且它有个额外好处：想撤回来很容易，不用把整套部署流程重做一遍。

有三个信号出现，就说明手工部署已经开始收利息了。

第一个是同一个环境问题出现了第二次。第一次不算，第二次说明这不是偶然。第二个是部署步骤多到需要对着文档一步步做，漏一步就出问题。第三个是你需要在不止一台机器上跑出完全一样的结果。

这三个信号里任何一个成立，容器带来的收益就开始超过它的搭建成本。

反过来，如果这三个都没出现，上容器就是在为一个还不存在的问题付钱。

新项目先不上容器，等它疼了再说。

「疼」的定义是可观察的：环境问题反复出现、部署步骤多到容易漏、或者需要同时跑多个服务。在那之前，上容器属于提前支付成本。

判断标准是重复次数，不是技术先进性。一件事你一年做两次，手工做完全够用。

个人项目用 Docker 是不是过度设计，这个问题没有通用答案，但有一个通用的问法：我现在疼吗。不疼就别上。

Q：个人项目用 Docker 是不是过度设计？

A：部署频率低、依赖简单的项目里是。手工部署更快也更省心，等环境问题反复出现再引入容器更合适。

Q：用了 Docker 以后部署会更省时间吗？

A：在依赖复杂或者要跑多个服务的项目里通常会，但第一次搭建的投入不小，还要算上日常排查多出来的那一层，把这些都算进去再判断。

Q：能不能只把一部分服务放进容器？

A：可以，而且这是我更推荐的做法。把依赖最难装的那部分容器化，其余的直接跑在机器上，复杂度花在刀刃上，想撤回来也容易。