很多人第一次听到“本地部署”这四个字，脑子里浮现的画面大概是一堆黑底白字的终端窗口，外加几根缠绕在一起的网线。我当初也是这么想的。那会儿我在一台旧笔记本上折腾一个开源博客系统，光是让它在本地跑起来就花了大半天，中间重启了不下十次。可当浏览器里终于跳出那个首页的时候，那种成就感是直接用云服务永远体会不到的。
这份本地部署教程想做的事情很简单：把这条路从头到尾铺一遍，让你少踩一些我踩过的坑。
1.1 什么是本地部署：定义、优势、代价与适用人群
本地部署这件事，说穿了就是把原本跑在别人服务器上的软件、服务或者模型，搬到你自己能摸得到的机器上来运行。这台机器可以是书房里那台台式机，可以是角落里吃灰的迷你主机，也可以是你花大价钱攒出来的带显卡的工作站。数据不出门，算力自己管，整个系统从里到外都在你的掌控之下。
为什么有人愿意折腾这个？我自己的理由换过好几轮。最开始是图省钱，云服务器每个月的账单看着心疼。后来是因为隐私，有些数据我实在不想传到别人的机房里去。再往后是出于学习目的，想搞清楚一个服务从安装到运行到底经历了什么。每个人的出发点不同，但归结起来无非三种：控制权、隐私保护、以及那种“东西在我手里”的踏实感。
代价当然也有。电费要自己掏，硬件坏了要自己修，半夜服务挂了没人帮你重启。我有一回部署了一个数据库，忘了设开机自启，结果小区停电之后整整两天没发现服务已经停了。这些事情在云平台上基本不会遇到，平台帮你兜住了。本地部署意味着你得自己当那个“平台”。
那什么人适合走这条路？我的观察是三类人最容易坚持下来。一类是对数据敏感度极高的开发者或小团队，另一类是喜欢折腾、把部署本身当成学习过程的爱好者，还有一类是预算有限但手头有闲置硬件的个人用户。如果你只是想让一个网站跑起来、完全不关心它跑在哪儿，那云服务可能更适合你，这话我说得挺认真的。
1.2 本地部署教程的典型路线：裸机、虚拟机、Docker、大模型推理
本地部署没有唯一正确的做法，不同的路线适合不同的场景和不同的折腾意愿。我自己这几年前前后后试过四种方式，每一种都给我留下过深刻印象，有的是好的，有的是半夜三点还在查日志那种深刻。
裸机部署是最直接的一种。操作系统直接装在硬件上，软件直接装在操作系统上，中间没有任何抽象层。这种方式性能损耗最小，对硬件的控制最彻底，适合那些对延迟极其敏感的场景。代价是环境隔离几乎为零，装了两个互相冲突的依赖，整个系统都可能遭殃。我曾经在一台裸机上先后装了三个版本的 Python 库，最后把系统自带的包管理器搞崩了，只能重装系统。
虚拟机是另一条路。在一台物理机上跑一个或多个虚拟系统，每个系统有自己的内核和完整的运行环境，互不干扰。快照和回滚功能让我在搞砸的时候能一键恢复，这个体验比裸机好太多。缺点是资源开销大，每个虚拟机都要吃掉一部分 CPU 和内存，跑轻量服务的时候感觉不太划算。
Docker 是我现在最常用的方式，也是这份教程后面重点展开的内容。容器共享宿主机内核，启动速度快，资源占用小，镜像让环境一致性变得非常容易保证。我可以在笔记本上构建一个镜像，推到服务器上直接跑，不用担心依赖版本对不上。刚开始学的时候确实会被镜像、容器、数据卷这些概念绕晕，但跨过那道坎之后，回头率极高。
大模型推理是最近一年新增的热门路线，和前三种在性质上不太一样。它更关注 GPU 显存、量化格式、推理框架的选择，而不是传统意义上的“服务部署”。一台带 24GB 显存的消费级显卡能跑什么规模的模型，用哪种量化方式能在效果和速度之间取得平衡，这些问题有自己独立的讨论体系。我会在第二章里专门花篇幅来讲这块内容。
1.3 硬件与系统环境规划：CPU、内存、GPU、磁盘与操作系统选择
硬件规划这件事，我的建议是：先想清楚你要跑什么，再决定买什么。顺序反过来很容易花冤枉钱。我见过有人为了“以后可能用得上”直接上了顶配显卡，结果大部分时间都在跑一个 CPU 就够用的轻量服务。
CPU 的核心数和单核性能是两个不同的维度。跑容器编排、编译镜像这类任务更吃多核，跑某些推理框架的单线程任务则更看重单核主频。我自己的经验是，如果预算有限，优先保证核心数够用，主频不用追求极致。普通家用场景下，六核十二线程的处理器基本能应付绝大多数部署需求。
内存比很多人想象中更重要。Docker 容器本身占用不大，但如果你同时跑数据库、Web 服务、消息队列，再加上系统本身的消耗，16GB 很快就会见底。我现在的主力机器是 64GB，跑七八个容器加上一个大模型推理服务，占用大概在 40GB 上下。如果你打算碰大模型，内存至少要给到 32GB，64GB 会更从容。
GPU 这块要单独说。不是所有本地部署都需要独立显卡，但大模型推理、视频转码、某些科学计算场景确实离不开它。选择 GPU 的时候，显存容量是第一优先级，其次才是算力。一张显存不够的卡，算力再强也跑不起来模型。NVIDIA 的生态目前仍然是最成熟的，CUDA 支持广泛，遇到问题更容易找到解决方案。
磁盘方面，SSD 是必须的，机械硬盘只适合做冷备份。系统盘和數據盘最好分开，系统盘 256GB 到 512GB 足够，数据盘根据你的数据量来定。我吃过一次亏，所有东西都放在一块盘上，后来数据涨起来要扩容，迁移过程折腾了整整一个周末。
操作系统的选择上，Ubuntu Server LTS 是我最推荐的入门选项，社区大、文档全、遇到问题搜索容易出结果。Debian 更稳定但软件包版本偏旧。CentOS 已经停止维护了，不建议新项目再用。Windows 配合 WSL2 也能用，适合那些主力工作环境在 Windows 上的朋友。
1.4 软件依赖与目录规划：驱动、运行库、包管理器、配置文件与数据卷
软件依赖这块，我踩过的坑比硬件多得多。硬件买错了还能挂二手卖掉，软件环境搞乱了有时候只能重装系统，那个时间成本高太多了。
驱动是绕不开的第一关。NVIDIA 显卡需要装驱动和 CUDA 工具包，装的时候要注意版本匹配。驱动版本太新可能和 CUDA 不兼容，太旧又可能不支持新的推理框架。我的习惯是去框架的官方文档里查推荐的驱动版本，然后照着装，不自己乱猜。装完之后用 nvidia-smi 确认一下，能正常输出显卡信息就算过了第一关。
运行库和包管理器是第二关。Python 项目用 pip 或者 conda，Node.js 项目用 npm 或 pnpm，系统级的依赖用 apt 或 yum。麻烦的地方在于不同项目可能依赖同一个库的不同版本，这时候虚拟环境就很重要了。Python 的 venv、conda 环境，Node.js 的 nvm，都是用来隔离不同项目的依赖，避免互相打架。
目录规划是最容易被忽视、又最容易在后期带来麻烦的环节。我现在的习惯是把配置文件、数据文件、日志文件分开放。配置文件放在 /etc 或者项目目录下的 config 文件夹，数据文件统一挂在 /data 下面，日志放在 /var/log 或者专门的日志目录。这样做的好处是备份的时候目标明确，迁移的时候不会漏掉东西。
数据卷这个概念在 Docker 里特别重要。容器本身是无状态的，删掉重建之后里面的数据就没了。把需要持久化的数据通过数据卷挂载到宿主机上，容器怎么折腾数据都还在。我刚学 Docker 的时候没在意这个，删了一个容器之后发现数据库里的数据全没了，那次教训让我后来每次起容器之前都会先确认数据卷挂好了没有。
1.5 部署前检查清单：网络、端口、权限、备份与回滚预案
正式动手之前，花十五分钟做一遍检查，能省下后面好几个小时的排查时间。这个习惯是我在连续三次部署失败之后养成的，现在每次开新项目都会走一遍。
网络方面，先确认机器能正常访问外网，DNS 解析没问题。如果你在国内，拉取 Docker 镜像或者从 GitHub 下载资源的时候可能会遇到速度问题，提前配好镜像加速能省不少等待时间。内网方面，确认你要用的端口没有被防火墙挡住，也确认一下路由器有没有做端口转发如果外面需要访问的话。
端口检查很简单，netstat 或者 ss 命令看一眼就知道哪些端口已经被占用了。我习惯给不同服务分配固定的端口段，Web 服务用 8000 到 8999，数据库用 5000 到 5999，这样一眼就能看出哪个端口对应哪个服务。端口冲突是新手最常见的报错原因之一，提前看一眼能避开。
权限方面，Linux 下不要图省事全部用 root 跑。给每个服务分配独立的用户，需要访问硬件的时候把用户加到对应的组里，比如 docker 组或者 video 组。文件权限也要注意，配置文件里如果存了密码或者密钥，权限设成 600，别让其他用户能读到。我见过有人把数据库密码写在了一个所有人可读的配置文件里，那个安全隐患挺大的。
备份和回滚预案是最后一道保险。动手之前先把现有的配置文件和数据备份一份，记下当前可用的版本号。如果部署过程中出了问题，能快速回到之前的状态。我现在的做法是在部署脚本里写好回滚命令，出问题的时候一条命令就能切回去，不用手忙脚乱地回忆之前改了什么。
2.1 Docker 本地部署教程：安装、镜像加速、存储与网络配置
我第一次在 Linux 上装 Docker 的时候，以为一条 apt install docker.io 就完事了。结果装完发现版本太旧，好多新特性用不了。后来跟着官方文档走，先卸掉系统自带的包，再添加 Docker 官方仓库，用 apt install docker-ce docker-ce-cli containerd.io 重新装了一遍。Windows 用户走 WSL2 这条路会舒服很多，装好 Ubuntu 子系统之后，按 Linux 的方式操作就行。macOS 直接下 Docker Desktop，省心，代价是资源占用比 Linux 高一些。装完记得跑一下 docker run hello-world，看到那段欢迎信息，说明基础环境通了。
镜像加速是国内用户绕不开的一步。默认从 Docker Hub 拉镜像，速度慢到让人怀疑网络是不是断了。我现在的习惯是编辑 /etc/docker/daemon.json，加上几个国内镜像源地址，重启 Docker 服务之后拉取速度能快好几倍。不过这些镜像源时有变动，用之前最好搜一下当前可用的。存储配置也值得提前规划，Docker 默认把镜像和容器数据放在 /var/lib/docker，系统盘小的话很快就满了。我会在 daemon.json 里把 data-root 改到一块大容量数据盘上，迁移之前记得先停掉 Docker 服务，把旧数据完整拷过去。
网络配置是 Docker 里让我迷糊最久的部分。默认的 bridge 网络能让容器访问外网，外部想访问容器就得做端口映射。我一开始搞不清 -p 8080:80 的意思，把宿主端口和容器端口写反了，怎么都访问不到服务。后来才明白冒号前面是宿主机的端口，后面是容器内部的端口。需要多个容器互相通信的时候，我会创建一个自定义 bridge 网络，把容器都加进去，这样它们可以用容器名直接互访，不用记 IP 地址。host 网络模式性能最好，但会占用宿主机的端口，容器之间的隔离也弱了，我一般只在特定场景下用。
2.2 Docker Compose 本地部署教程：多容器编排、环境变量与数据持久化
手动敲 docker run 启动一两个容器还行，服务一多就受不了了。端口、环境变量、数据卷、依赖关系，每个容器都要记一堆参数。我第一个 Docker Compose 文件是照着网上示例抄的，YAML 的缩进搞错了，启动时报了一堆语法错误。调好之后才发现这东西真香，一个 docker compose up -d 就能把整套服务拉起来。文件里每个服务写清楚镜像、端口、卷、环境变量，版本控制里存一份，换台机器克隆下来就能跑。
环境变量这块我吃过泄露密码的亏。一开始把数据库密码直接写在 compose 文件里，后来用 .env 文件单独存敏感信息，compose 文件里用 ${DB_PASSWORD} 引用。记得把 .env 加进 .gitignore，别不小心推到公开仓库。数据持久化用命名卷或者绑定挂载都行。命名卷由 Docker 管理，备份稍微麻烦一点，需要先找到卷在宿主机上的实际路径。绑定挂载直接把宿主机的目录挂到容器里，备份和查看都直观。我现在的做法是数据库用命名卷，配置文件和日志用绑定挂载，两边的好处都占上。
多容器编排里有个细节容易忽略：服务启动顺序。Web 服务依赖数据库，数据库还没准备好，Web 服务就急着连，连不上就崩了。depends_on 能控制启动顺序，但不等数据库真正可用。我后来在应用里加了重试逻辑，连接失败就等几秒再试，试到成功为止。重启策略也值得配一下，restart: unless-stopped 让容器在意外退出后自动拉起来，省得半夜服务挂了第二天才发现。资源限制也可以写在 compose 文件里，给每个容器设个内存上限，避免一个服务把整台机器的内存吃光。
2.3 大模型本地部署教程：模型来源、量化格式、推理框架与显存评估
大模型文件主要从 Hugging Face 和 ModelScope 下载。Hugging Face 资源最全，国内访问有时候不太稳定，可以配镜像站或者用 hf_transfer 加速。ModelScope 在国内速度不错，模型数量也在增长。下载之前先看清楚模型的许可证，有些只允许研究用途，商用要另外申请。文件格式上，原始权重通常是 PyTorch 的 .bin 或 .safetensors，体积很大。实际部署的时候我一般会选已经量化好的版本，下载快，跑起来也省显存。
量化格式决定了模型要吃掉多少显存。GGUF 格式适合 llama.cpp 和 Ollama，能在 CPU 和 GPU 上混合推理，对硬件要求最低。Q4_K_M 是我常用的量化等级，效果和体积平衡得不错，7B 模型大概占 4GB 到 5GB 显存。GPTQ 和 AWQ 更适合纯 GPU 推理，需要显卡支持。显存评估有个粗略的算法：模型参数量乘以量化位数，再除以 8，加上上下文缓存和框架开销。比如 7B 模型用 4 比特量化，权重占 3.5GB 左右，加上 2GB 到 3GB 的额外开销，8GB 显存的卡勉强能跑。13B 模型建议 12GB 以上显存，70B 模型没有多卡基本不用想。
推理框架的选择要看你的场景。Ollama 对新手最友好，一条命令下载模型，一条命令启动服务，自带 API 接口。llama.cpp 更底层，可以精细控制参数，适合想折腾的人。vLLM 并发性能强，适合多人同时访问的场景，但对显存要求更高。我自己的主力是 Ollama，日常测试和简单应用够用了。需要更高吞吐的时候会切到 vLLM。安装框架之前先确认 CUDA 版本和驱动匹配，版本对不上会报一堆看不懂的错误。跑起来之后用 nvidia-smi 看一眼显存占用，心里就有数了。
2.4 从零启动示例：部署 Web 服务、数据库、API 与大模型对话接口
我拿一个实际项目来演示，目标是用 Docker Compose 启动一套能对话的本地服务。结构很简单：一个 Nginx 提供前端页面，一个 PostgreSQL 存对话历史，一个 FastAPI 写后端逻辑，再加一个 Ollama 提供大模型推理。四个容器放在同一个自定义网络里，互相用服务名通信。Nginx 监听宿主机的 80 端口，FastAPI 监听 8000，PostgreSQL 和 Ollama 只在内部网络暴露，不直接对外开放。这样做的好处是外部只能访问 Web 入口，数据库和模型服务相对安全。
Compose 文件里每个服务写清楚。Nginx 挂载前端静态文件目录和配置文件。PostgreSQL 用命名卷存数据，环境变量传数据库名、用户名和密码。FastAPI 服务用 build 指令从本地 Dockerfile 构建，挂载代码目录方便改完就生效。Ollama 用官方镜像，挂载模型存储卷。服务之间用 depends_on 控制启动顺序，FastAPI 依赖 PostgreSQL 和 Ollama。环境变量文件里存数据库连接串和 Ollama 的地址。写完文件之后，在项目根目录跑 docker compose up -d --build，等镜像拉取和构建完成，再等十几秒让服务初始化。
启动之后用 docker compose ps 看容器状态。四个服务都是 running 就成功了一半。打开浏览器访问宿主机 IP，应该能看到前端页面。在页面上输入一句话，请求会发给 FastAPI，FastAPI 先查数据库，再把问题转发给 Ollama，拿到回答后存回数据库，最后返回前端显示。第一次对话会慢一些，模型需要加载到显存里。后续对话就快了。想确认 API 是否正常，可以用 curl 直接请求 FastAPI 的接口，看返回的 JSON 结构对不对。数据库里查一下对话记录表，能看到历史数据，说明整条链路都通了。
2.5 验证与排错：日志查看、健康检查、端口冲突、权限与依赖问题
服务跑起来只是开始，出问题能快速定位才是真本事。日志是第一手信息，docker compose logs -f 服务名 能实时跟踪某个容器的输出。我习惯先看报错的服务，日志里通常会有明确的错误信息，比如连接被拒绝、文件找不到、端口已占用。docker compose logs --tail=100 看最近一百行，翻起来快一些。健康检查可以在 compose 文件里定义，让 Docker 定期执行一个命令判断服务是否正常。PostgreSQL 可以用 pg_isready，Web 服务可以用 curl 请求一个健康检查接口。健康状态用 docker compose ps 就能看到，healthy 才算真正可用。
端口冲突是新手最常见的报错。启动容器时报 bind: address already in use，说明宿主机上那个端口已经被别的程序占了。用 ss -tulnp | grep 端口号 或者 netstat -tulnp | grep 端口号 查一下是谁在用。可能是之前没清理干净的容器，也可能是系统里装的其他服务。换个端口映射，或者停掉占用端口的程序，问题就解决了。权限问题也常遇到，容器里以非 root 用户运行的时候，挂载的宿主机目录如果没有对应权限，读写会失败。查一下目录的所有者和权限位，用 chown 或者 chmod 调一下。把用户加入 docker 组可以免 sudo 执行 Docker 命令，记得重新登录让组权限生效。
依赖问题多半出在镜像构建阶段。Dockerfile 里 apt install 或者 pip install 失败，先看网络是否通，再看包名和版本号是否写对。构建缓存有时候会捣乱，改完 Dockerfile 之后加 --no-cache 重新构建能排除缓存干扰。容器启动后应用报缺少某个库，可能是基础镜像里没有，需要在 Dockerfile 里补上。Python 项目建议用虚拟环境或者固定版本的 requirements.txt，避免依赖版本漂移。Node.js 项目把 node_modules 放进 .dockerignore，别让宿主机的依赖覆盖容器里的。排错的过程就是不断缩小范围，从外到内一层层查，总能找到根因。
3.1 性能优化：GPU 加速、资源限制、并发参数与缓存策略
我刚开始把大模型塞进 Docker 的时候，以为容器里能直接用到显卡，结果跑起来发现速度跟 CPU 差不多。后来查了资料，需要在宿主机装 nvidia-container-toolkit，重启 Docker 服务，运行时加 --gpus all。Compose 文件里写 deploy.resources.reservations.devices 指定 GPU 数量。Ollama 默认会检测 GPU，vLLM 需要显式设置 --tensor-parallel-size 和 --gpu-memory-utilization。每次启动后用 nvidia-smi 看一眼显存占用，心里踏实。GGUF 格式的模型可以只把部分层放到 GPU 上，剩下的留给 CPU，显存小的时候这个特性很实用。
资源限制是防止一个服务拖垮整台机器的关键。Docker 允许用 --memory 和 --cpus 限制容器，Compose 里对应 deploy.resources.limits。我给数据库设了 2GB 内存上限，给 Ollama 设了 8GB，避免它把宿主机内存吃光触发 OOM。并发参数要根据显存来调。Ollama 的 OLLAMA_NUM_PARALLEL 控制同时处理的请求数，默认值可能偏高，显存不够就降到 1 或 2。vLLM 的 --max-num-seqs 和 --gpu-memory-utilization 需要反复测试，找到吞吐和延迟的平衡点。
缓存策略能省下不少算力。模型文件放在 NVMe 盘上，加载速度快很多。KV cache 可以调量化等级，牺牲一点质量换显存。应用层我加了 Redis，把常见的问答对缓存起来，用户问重复问题直接返回，不用每次都调用模型。embedding 结果也缓存，做 RAG 的时候效果明显。缓存要设过期时间，定期清理旧数据，不然磁盘会被慢慢占满。
3.2 安全加固：访问控制、网络隔离、密钥管理与数据备份
本地部署不等于安全。我一开始把数据库端口映射到宿主机，想着方便调试，后来发现公网 IP 能直接扫到。现在所有管理后台都放在 Nginx 后面，加 basic auth 或者 OAuth 代理。SSH 只允许密钥登录，改掉默认 22 端口，禁用 root 远程登录。防火墙用 ufw 或者 iptables，只开 80、443 和自定义的 SSH 端口。Docker socket 不要挂载到容器里，那等于把宿主机控制权交出去。
网络隔离靠自定义 bridge 网络实现。我把 Web 服务、数据库、模型服务放在同一个网络里，数据库和 Ollama 不映射端口到宿主机，外部只能通过 Nginx 访问 Web 入口。Compose 里可以用 internal: true 创建内部网络，容器只能内部通信，连外网都出不去。密钥管理方面，我不用环境变量传密码，因为 docker inspect 能看到。改用 Docker secrets 或者挂载文件，权限设成 600。.env 文件加进 .gitignore，别不小心推到公开仓库。
数据备份是兜底手段。数据库每天用 pg_dump 导出，模型文件和配置文件每周备份一次。备份存到另一块硬盘或者远程对象存储，遵循 3-2-1 原则。我还会定期做恢复演练，把备份文件拉到测试环境恢复一遍，确认能用。光备份不验证，等于没备份。
3.3 版本与更新管理：镜像、模型、依赖升级与回滚方案
镜像不要用 latest 标签。我吃过亏，某次 docker compose pull 之后服务起不来，查了半天发现是新版本改了配置格式。现在所有镜像都锁定具体版本号，比如 postgres:16.2、ollama/ollama:0.1.32。升级之前在测试环境跑一遍，确认没问题再动生产。模型更新也是同理，下载新版本之后保留旧的，用软链接切换。量化格式升级要注意兼容性，GGUF 的新版本可能不被旧版 llama.cpp 支持。
依赖升级要谨慎。Python 项目用 requirements.txt 锁死版本，Dockerfile 分层构建，把依赖安装和代码复制分开，利用缓存加速。安全补丁定期打，但别盲目追新。回滚方案提前准备好：保留旧镜像 tag，数据库迁移脚本要能反向执行。Compose 文件和配置全部纳入 Git 管理，回滚就是 git checkout 到上一个提交，再 docker compose up -d。简单直接。
3.4 监控与自动化：日志、指标、告警、脚本与 CI/CD
日志不限制大小会撑爆磁盘。我在 Docker 的 daemon.json 里配了 log-opts，设置 max-size=10m 和 max-file=3。集中收集用 Loki 加 Promtail，或者 ELK 栈。指标监控用 Prometheus 抓取 cAdvisor、node_exporter 和 nvidia_gpu_exporter 的数据。Grafana 面板上能看到 GPU 利用率、显存占用、容器内存、磁盘空间。这些数据比凭感觉判断靠谱得多。
告警规则按业务重要性设置。显存超过 90% 持续五分钟，发钉钉消息。磁盘使用率超过 80%，发邮件。服务健康检查失败，触发 Webhook。Alertmanager 负责路由和去重。自动化脚本能省很多重复劳动。备份脚本每天凌晨跑，清理脚本每周删旧镜像和日志，健康检查脚本每分钟调一次 API。这些脚本用 cron 或者 systemd timer 调度。
CI/CD 让部署更规范。GitHub Actions 或者 GitLab CI 在代码推送到主分支时构建镜像，推送到私有 registry。生产环境手动触发部署脚本，拉取新镜像重启服务。Watchtower 可以自动更新容器，但生产环境慎用，容易在不合适的时间重启服务。多台机器可以用 Ansible 批量管理，统一配置和部署。
3.5 常见问题与最佳实践：大模型与 Docker 部署 FAQ、避坑清单
显存不足是最常见的问题。解决办法有量化模型、减小并发数、换更小的模型、把部分层放到 CPU。模型加载慢，检查模型文件是否放在 SSD 上，用 mmap 方式加载。GPU 不可用，先确认驱动版本、nvidia-container-toolkit 是否安装、运行时有没有加 --gpus all。端口冲突用 ss -tulnp 查占用，改映射或者停掉冲突程序。权限拒绝，看挂载目录的所有者和权限位，或者把用户加入 docker 组。OOM 错误，给容器加内存限制或者调整应用的内存使用。
避坑清单我列几条：别用 latest 标签，别把数据库端口暴露到公网，别用 root 用户跑容器，日志一定要限制大小，备份一定要验证恢复，.env 文件千万别提交到 Git，镜像源失效要及时更换，Docker 存储目录要定期清理。这些坑我几乎都踩过，写下来提醒自己。
最佳实践说起来也简单：所有配置版本控制，部署步骤文档化，监控告警配好，定期更新和演练恢复。用 Docker Compose 管理单机服务足够，规模大了再考虑 Kubernetes。保持架构简单，别为了技术而技术。本地部署的乐趣在于掌控感，前提是别把自己搞得太累。
