Docker部署实战：非程序员也能用AI轻松把网站送上服务器

从AI帮你把代码写出来到别人真的能在浏览器里访问到你的网站中间这一段路就是“上线部署”。很多人学AI编程学得挺顺代码能跑、界面能看结果卡在这一步本地好好的怎么一上服务器就各种问题这篇文章我就站在一个非程序员的角度把部署这件事彻底讲明白。不堆概念不装高深用最直白的语言告诉你部署前要想什么、部署时怎么做、部署后又怎么排查。整篇内容我会把Docker部署作为主线因为它是目前最值得非程序员掌握的部署方式同时也会给出不用Docker的替代路线。无论你是做了一个个人网站、一个小工具还是帮别人做的展示页面这篇都能帮你少走很多弯路。1. 部署到底在解决什么问题一场关于“开门营业”的认知转变1.1 本地能跑和线上能访问中间隔着一台“24小时开机的机器”先说一个很多新手都会产生的困惑我的网站在自己电脑上明明能打开为什么朋友访问不了原因很简单。你本地预览的时候网站服务运行在localhost或者127.0.0.1上这个地址是电脑自己访问自己的专用通道相当于你店里装修得再漂亮但门开在自己家里外人根本找不到入口。而部署要做的事情就是把这个“店”搬到一台24小时不关机的“商铺”里然后给商铺挂上一个外人能找到的招牌域名或者IP客人才进得来。这台24小时开机的机器就是服务器。它可以是云厂商的一台云服务器也可以是一台你放在家里的旧电脑但实际使用中基本都是前者。你花钱买的不只是一台“远程电脑”还是一个稳定的公网入口。服务器拿到手之后你在上面安装运行环境、放上你的项目文件、启动服务再开放端口全世界的人就能通过IP或域名访问到了。1.2 非程序员需要建立的三个部署心智模型非程序员学部署最怕的就是把自己当成运维工程师想把所有底层原理都搞清楚再动手。以我的经验真的不需要。你只需要建立三个心智模型。第一个模型叫“构建”。你的源码不是浏览器能直接运行的东西构建这一步会把源码转换成浏览器能认的静态文件HTML、CSS、JavaScript同时还会压缩体积、优化加载。对前端项目来说构建完之后你会得到一个dist文件夹这才是你要部署的“货物”。第二个模型叫“传输”。你不能把本地文件凭空变到服务器上得通过某种方式传上去。用图形面板上传、用FTP工具上传、用git拉取代码到服务器再构建都可以。选哪种不重要重要的是你理解服务器上的文件和本地文件是两份东西要更新网站就得把新的“货物”再传一遍。第三个模型叫“运行和暴露”。文件传到服务器只是第一步还得有一个“服务员”来端盘子——它会接收浏览器的请求把对应的文件返回给用户。这个服务员就是Nginx、Apache这类Web服务器。它占着服务器的某一个端口通常是80你说一声“访问这台服务器的80端口”它就把网站首页端出来。这三个模型建立起来后面所有操作都是围绕它们展开的再也不会觉得部署是一团迷雾。1.3 把“上线”拆开看构建 传输 运行 暴露入口很多人一听“上线部署”四个字就头大其实把它拆开就没那么可怕。整个流程可以压缩成四个动作构建在本地或者服务器上把源码变成dist静态文件传输把dist和必要的配置文件送到服务器运行在服务器上用Nginx或Node等把项目跑起来暴露入口开放服务器的80端口绑定域名让所有人都能访问。这篇文章后面讲的Docker部署本质上只是把这四个动作做了一个标准化打包。它不是新的魔法只是把“该装什么环境、该配置什么文件、该执行什么命令”这些步骤固化下来让你每次部署都像流水线一样稳定。2. 先选路线再动手三种部署方式怎么挑2.1 平台托管适合“赶紧让别人看一眼”的场景如果你现在的需求就是把一个小页面发给朋友看看或者做一个个人名片式的展示站最省事的路子根本不是买服务器而是用平台托管。这类平台你只需要注册账号把代码仓库比如Git仓库关联上去它就能自动完成构建、托管、给你一个网址。有些平台连代码仓库都不需要直接把文件夹拖上去就能发布。整个过程几乎是可视化的完全不用碰命令行。平台托管最大的优点是快免费额度也够个人项目用。但缺点也很明显它更适合纯前端静态网站。如果你的项目需要一个数据库存数据或者需要一个后端逻辑跑接口免费托管的模式就不太够用了。而且托管平台的服务节点通常离你比较远国内访问速度会有波动这个要有心理准备。我的建议是演示用、临时用走平台托管打算长期运营、数据自己掌控别偷懒往服务器上走。2.2 云服务器 可视化面板适合“有个服务器但不想折腾命令”如果你想自己掌控一切但看到命令行就头大那“云服务器 可视化面板”是一个很好的过渡方案。具体做法是到云厂商买一台轻量应用服务器在服务器上安装一个叫宝塔的面板软件。装好之后你就可以通过浏览器登录面板像操作电脑软件一样拖拽上传文件、创建网站、申请SSL证书、管理数据库。很多非程序员用这个方案做出了自己的第一个线上项目我也带过不少零基础的朋友用面板部署WordPress或静态站基本一小时之内就能搞定。面板方案的门槛确实低但也不是没有代价。它把很多底层操作藏起来了遇到问题时你很难判断到底哪一环出了问题。而且不同服务商的面板环境有差异以后想换台服务器重新部署光靠“我当初点了什么按钮”的记忆是不够的。所以我的看法是面板适合快速落地也适合不想深入折腾的人。但如果你发现自己要反复重装环境、换服务器、改配置就该考虑更规范化的Docker了。2.3 Docker容器化适合“想长期维护、不想反复踩环境坑”Docker这几年能火核心就一句话它把你整个项目的运行环境打包成了一个标准集装箱搬到哪里都能跑。过去你部署一个项目要先在服务器上装Node、装Nginx、调各种配置每台服务器都要从头来一遍中间还容易因为版本不一致出问题。用Docker之后你只需要写一个Dockerfile把“用什么镜像、复制哪些文件、执行什么命令、开放哪个端口”全部写清楚然后一条命令就能构建出镜像再一条命令就能启动项目。对非程序员来说Docker最实际的价值有三个。第一你的部署步骤被“写成了文件”而不是存在你脑子里换服务器也记得住。第二环境问题大幅减少本地能跑的服务器上通常也能跑。第三回滚容易旧版本镜像还在出事了一句命令切回去。当然Docker也有学习成本这也就是为什么我推荐你在选这条路之前先看看前两种方案。但如果你已经在用AI编程做了多个项目想认真把一两个项目长期维护起来Docker这条路的投入产出比非常高。2.4 一张表看清三种路线方案上手难度适合场景主要缺点推荐指数平台托管极低纯前端静态站、临时Demo后端支持弱、访问速度受平台影响演示和临时场景很高云服务器 面板较低个人网站、带数据库、想可视化管理环境依赖隐藏、迁移麻烦第一台服务器很推荐Docker 部署中等长期维护、多项目、需要标准化和回滚需要理解几个基本概念长期项目强烈推荐选路线的时候别贪。如果你现在只想把一个静态页面发出去就别先花几天学Docker直接用平台托管发布让事情先跑起来。而如果你已经决定要做一个正经项目那就一次性选择Docker把基础打扎实。3. Docker部署前端项目从本地到公网可访问的完整链路3.1 先认识Docker的三个基本名词在你动手之前我先用大白话把Docker的三个核心词解释一下不然你后面看命令会一头雾水。Dockerfile可以理解成“配方文件”。它把你想要的环境写清楚从哪个基础镜像开始、需要复制哪些文件进去、要安装什么、要暴露哪个端口。AI帮我们写的多半就是这个文件。镜像镜像就是根据配方做出来的“成品包”。它体积大内容完整里面已经有Nginx、有你项目的静态文件是一个只读的模板。你用同一个镜像能开出多个一样的容器。容器容器是镜像运行起来后的实例。镜像好比是“菜谱做好的半成品”容器则是“把半成品下锅炒出来的那盘菜”。一个镜像可以同时开多个容器互相隔离。看到这里别急着往下走你只需要记住一条完整的链路写Dockerfile → 构建出镜像 → 用镜像启动容器。后面所有命令都是围绕这三步在转。3.2 本地构建把源码变成发布版用AI编程写项目不管你是用Vite、Create React App还是别的工具上线之前都要先执行“构建”。构建输出的dist文件夹里才是你真正要部署的静态文件。具体操作通常是这样在项目根目录打开命令行先安装依赖再执行构建命令。npm install npm run build执行完之后项目目录下会出现一个dist文件夹有的项目叫build。如果你不确定自己的项目应该执行哪个构建命令直接把你的项目目录结构复制给AI问它我项目根目录下有这样一个结构贴目录结构我使用的是一个前端框架请告诉我构建命令是什么以及构建产物输出到哪个文件夹。这一步的产出是“发布版”文件后面的Docker打包都是以这个文件夹为基础的。**本地改动再多不重新构建部署到线上也不会变。**这是新手最容易忽略的一点我见过太多人改完代码直接上传服务器然后发现页面一点没变其实就是忘了他上传的是构建产物而不是源码。3.3 让AI帮你写Dockerfile和Nginx配置现在进入正题。你不需要自己从头写配置文件你要做的是学会给AI下指令。打开你的AI编程助手直接复制这个示例我是一个前端新手项目基于Vite构建构建命令是 npm run build构建产物在 dist 目录。我想用Docker加Nginx把这个项目部署到一台Ubuntu服务器上。请帮我写一个 Dockerfile 和一个 nginx.conf要求镜像尽量小使用 nginx:alpine支持单页应用路由刷新不404静态资源比如 js、css、图片缓存7天请给每行配置加注释解释作用。AI生成的配置通常长这样下面我逐行拆给你看。# 基础镜像轻量版Nginx体积小启动快 FROM nginx:alpine # 把构建产物dist目录复制到Nginx默认站点目录 COPY dist /usr/share/nginx/html # 把自定义的Nginx配置文件复制到容器内 COPY nginx.conf /etc/nginx/conf.d/default.conf # 容器对外暴露80端口 EXPOSE 80这个Dockerfile很简单但绝对够用。它做的事情就是拿一个干净带Nginx的镜像把构建产物放进去再把Nginx的个性化配置放进去最后告诉外部“我在80端口等你”。Nginx配置是这个方案里的关键尤其是前端路由这行新手必须重点看。server { listen 80; server_name _; # 站点根目录 root /usr/share/nginx/html; index index.html; # 前端路由回退找不到文件时返回index.html location / { try_files $uri $uri/ /index.html; } # 静态资源缓存7天 location ~* \.(js|css|png|jpg|jpeg|gif|svg|woff2?)$ { expires 7d; add_header Cache-Control public; } }我来说说这两段配置为什么这么写。try_files $uri $uri/ /index.html这行是给单页应用用的没有它你访问某个子路由再刷新时Nginx会去找对应路径的文件找不到就404。有了这行它会在找不到文件时直接回退到index.html把路由交回前端处理。很多新手部署完网站首页能打开但点进详情页刷新就白屏大多就是少了这行配置。配置文件写好后把它们和项目文件放在一起比如项目根目录下新建一个deploy文件夹里面放Dockerfile和nginx.conf。3.4 服务器准备买机器、登录、装Docker配置文件准备好了接下来就是让服务器接手。先买一台云服务器。非入门项目一台轻量应用服务器就够用了配置选1核2G即可操作系统选Ubuntu。买的时候通常会让你设置root密码或者密钥记好它。登录服务器的方式有很多。苹果电脑和Windows都可以打开终端用SSH连上去ssh root你的服务器IP输入密码之后就进入服务器命令行这说明你已经能远程控制这台机器了。接下来安装Docker。官方给了一行安装脚本直接用就行curl -fsSL https://get.docker.com | sh装完验证一下docker --version能输出版本号说明Docker已经装好。服务可以先启动起来systemctl start docker如果这一步遇到权限问题可以给当前用户加Docker组或者直接用sudo前缀执行Docker命令。3.5 把项目文件送上服务器并启动容器现在到了真正“上线”的一步。你需要在服务器上找一个目录放项目文件比如/opt/my-site然后把dist文件夹、Dockerfile、nginx.conf都传上去。传文件的方式很多。如果你之前装了宝塔面板可以直接用面板的上传功能。不想装面板的话Windows可以用一些图形化SFTP工具Mac也有类似软件。更极客一点的做法是在服务器上直接git clone你的代码仓库然后让AI帮你写一条构建命令在服务器上执行npm run build生成dist。文件就位后在Dockerfile所在目录执行构建docker build -t my-website .-t my-website是给镜像起个名字“.”表示用当前目录下的Dockerfile。构建过程会有日志看到Successfully tagged my-website:latest就说明成功了。构建好之后启动容器docker run -d -p 80:80 --name my-site --restartalways my-website一条条拆给你看-d后台运行关掉终端不影响服务-p 80:80把服务器的80端口映射到容器内的80端口。冒号左边是服务器端口冒号右边是容器内端口。外部访问你的服务器80端口就会被转到容器里Nginx的80端口--name my-site给这个容器起个名字后面管理容器都靠它--restartalways服务器重启或Docker重启时容器会自动拉起来my-website镜像名。启动完直接在你自己电脑浏览器访问http://你的服务器IP。如果能看到你的页面恭喜你的项目已经成功上线了。3.6 绑域名和HTTPS让网站看起来“像那么回事”用IP访问虽然能用但正式上线还是建议绑域名。步骤不难。先在域名服务商后台添加一条A记录把域名指向你的服务器IP。说白了就是告诉全世界“这个域名对应这台服务器”。等DNS生效浏览器里输入你的域名就能访问。然后处理HTTPS。没加HTTPS时浏览器地址栏会显示“不安全”看着就很劝退。现在给Nginx容器加SSL证书可以走自动申请比如用certbot工具。如果你用面板直接在面板里申请证书就行点几下自动配置好。这里提醒一句国内大陆地区的云服务器绑定域名访问时通常需要按服务商页面的提示完成相应的网站接入登记手续。这个流程每个服务商差异不小最好提前操作别等域名绑完了才想起来白白耽误上线时间。4. 部署后最常见的四个坑及完整排查链路4.1 外网打不开安全组、端口、容器状态三大嫌疑部署完打不开页面这是新手第一大拦路虎。我排过的多数情况都不是代码问题而是下面三个原因。第一步排查容器状态。执行docker ps看my-site是不是在运行中。如果没在列表里再看日志docker logs my-site日志能告诉你容器启动时发生了什么。这一步的排查思路是先确认服务自己在不在再看门开没开。第二步排查服务器端口。在服务器本机执行curl http://localhost如果本地能返回页面内容说明服务本身没问题。这时候你可以访问http://服务器IP再试一次如果还是打不开问题大概率出在云平台的安全组规则上。第三步是很多新手最容易漏掉的大多数云服务器在控制台里都有一个“安全组”或“防火墙”设置。你系统里的Docker跑得再欢安全组不对外开放80端口外网照样进不来。去控制台找到安全组添加一条入站规则放行TCP 80端口如果做了HTTPS443也要放行。这一步做完页面通常就通了。4.2 刷新变成404前端路由和服务器回退首页能打开点进某个子页面再按刷新页面变成404。这个坑我在前面提到Nginx配置时已经打过预防针它是一个非常典型的前端路由问题。现在很多前端框架用的都是history模式路由切换是前端自己处理的。但刷新时浏览器会向服务器真实请求/about这个地址如果服务器找不到对应的物理文件就会返回404。解决方式就是前面nginx.conf里那一行location / { try_files $uri $uri/ /index.html; }如果你已经部署完才发现这个问题不用慌改掉nginx.conf重新构建镜像、重启容器即可。改一次配置以后就不会再犯这个错了。4.3 接口、样式、图片异常环境与路径问题页面能打开是好事但别忘了点几个功能。如果你发现接口请求失败、图片裂掉、样式全丢通常不是部署问题而是构建时写死了路径。比如前端代码里接口地址写的是http://localhost:3000本地开发没问题部署到线上自然请求不到。这类问题的处理方式是让AI帮你检查构建产物中的API地址配置。很多项目会把接口地址放到环境变量里构建时读取。部署时用--env参数或者通过面板设置环境变量这样换环境就不用改代码。图片和样式丢失常见原因是构建配置里的base路径不对。假如项目被部署在域名根目录那base一般设成/如果你是用IP访问又部署在子路径下就要把base改成对应路径。开发时不会发现因为本地预览的路径和线上不一样。排查这种问题有一个很实用的方法在浏览器里按F12打开开发者工具看Network面板哪个资源返回404就往哪个路径去查。把截图或者报错信息丢给AI让它帮你判断是路径问题还是接口跨域问题。4.4 线上一直是旧版本缓存与镜像重建改完代码重新部署结果线上还是老页面。这种问题新手几乎都遇到过原因主要有两类。第一类是浏览器缓存。浏览器为了加快速度会缓存JS和CSS文件。Nginx配置里给静态资源设置7天缓存后用户端可能还是旧文件。解决办法是构建时给文件名加哈希或者Nginx配置里合理设置缓存策略。这样每次发布后文件名变了浏览器就会拉新文件。第二类是镜像没有真正重建。你可能以为自己重新部署了但实际执行的是docker start或者docker restart而不是重新构建镜像。Docker容器启动时运行的是镜像里的文件如果你更新了dist但没有重新执行docker build新代码根本不会进入镜像。改了代码之后的完整更新流程应该是docker stop my-site docker rm my-site docker build -t my-website . docker run -d -p 80:80 --name my-site --restartalways my-website简单说就是停掉旧容器、删掉旧容器、重新构建镜像、用新镜像启动新容器。这一步别省。5. 给非程序员的AI部署提问清单可直接复制5.1 提问的底层原则要把“检查报告”交给AI我平时用AI排查部署问题时最大的心得是AI能不能给你准确答案取决于你给它多少有效信息。就好比你去看医生只说我头疼医生没法确定你是感冒还是偏头痛。你把体温、血压、有没有其他症状都告诉他他才能开对药。AI也一样。你给它的信息越完整它给你修好的概率越高。有效信息包括三种目标你想干什么部署新项目、排查404、还是绑定HTTPS现状项目是什么框架服务器是什么系统用了什么配置报错完整报错信息、日志输出、页面截图。不要只甩一句“我的网站打不开”。这句话信息量为零。5.2 六个可以直接复制的部署提示词以下是我自己验证过好用的提示词模板你拿过去改一改就能用。模板一生成Docker部署配置项目是Vite构建的前端项目构建命令是 npm run build产物在 dist 目录。请帮我写Dockerfile和nginx.conf用nginx:alpine做基础镜像要求支持单页应用history路由刷新不404静态资源缓存7天每行都加注释。模板二排查部署后404我的网站用Nginx部署在Docker容器里首页打开正常但访问 /about 后刷新会404。项目用的是Vue Router history模式。这是我的nginx.conf内容贴配置。请帮我修复并解释原因。模板三排查端口访问不通我的服务器公网IP是填IP在服务器上执行 curl http://localhost 有返回但从浏览器访问 http://填IP 打不开。服务器是Ubuntu系统Docker容器状态是运行中。请告诉我一步步排查顺序和命令。模板四生成一条龙更新脚本我每次更新网站都要手动执行 docker stop、docker rm、docker build、docker run容易漏。请帮我写一个 deploy.sh 脚本放到服务器项目目录后执行一次完成上述所有步骤并且带日志输出和错误提示。模板五申请并配置HTTPS我有一个域名填域名已解析到服务器IP。服务器是UbuntuDocker里有一个Nginx容器占用80端口。我想申请Lets Encrypt证书并配置自动续期请给出具体操作步骤不要影响现有容器运行。模板六解读容器日志这是我的容器日志贴日志。我的网站首页能打开但注册接口返回500。请帮我判断是前端还是后端问题下一步应该检查什么。5.3 AI给完命令之后的三个核对动作AI给出的命令不一定每条都适合你当前的系统环境复制粘贴之前先做三个核对。第一问清楚这条命令在哪台机器上执行。是本地还是服务器很多新手把该在服务器执行的命令写到了本地报错之后完全摸不着头脑。拿不准的时候直接问AI“这条命令应该在本地还是服务器上执行”第二观察命令里有没有危险操作。看到rm -rf、docker rm这类命令时先让AI解释一下它会删掉什么。AI是好帮手但不意味着它可以乱删东西。我自己的习惯是重要命令前加上一句“执行前请解释它会做什么”确认无误再回车。第三注意替换占位符。AI给的命令里经常有虚拟域名、虚拟IP、虚拟路径如果你直接复制它会操作到错误目标上。把整条命令里的示例内容都替换成你自己的真实信息再进行下一步。6. 部署完不是结束更新、维护与回滚6.1 把更新做成一条命令网站上线只是开始后面你还会反复改需求、加功能、修bug。如果每次更新都要手敲四条Docker命令早晚会出错。第5.2节的模板四就是让AI帮我们写一个deploy.sh更新脚本。它看起来大致是这样#!/bin/bash echo 开始更新网站... docker stop my-site docker rm my-site docker build -t my-website . docker run -d -p 80:80 --name my-site --restartalways my-website echo 更新完成访问 http://你的服务器IP把脚本放到服务器项目目录执行chmod x deploy.sh ./deploy.sh只要把新的dist文件传入服务器运行一次脚本更新就算完成了。你可以让AI把脚本再扩展一下比如构建之前先备份当前镜像、失败时自动回滚这些都不难。6.2 自愈与日志让容器自动重启服务器环境不是永远安稳的偶尔会遇到进程崩溃或者服务器重启。如果想让网站尽可能稳定记得在启动容器时加上--restartalways参数。这个参数的作用是只要Docker还在运行容器挂了会自动拉起来服务器重启后容器也会自动启动。等于给网站上了一道保险。想看容器发生了什么用日志docker logs my-site只看最近50行docker logs --tail 50 my-site遇到看不懂的日志直接复制给AI让它帮你分析。这是排查线上问题最高效的路径。6.3 备份、回滚与版本管理部署到线上之后备份工作也要跟上。前端项目的备份相对简单dist目录和Dockerfile保存好就行必要的时候把镜像导出去留档。镜像打标签可以作为版本管理的一种方式docker tag my-website my-website:20250601这样每个版本的镜像都有名字出了事想回退直接用旧镜像启动新容器即可docker run -d -p 80:80 --name my-site-backup --restartalways my-website:20250601如果项目还带了数据库备份数据库比备份代码更重要。具体怎么备份取决于数据库类型建议让AI针对你的项目写一份备份脚本最好加入定时任务每周自动备份一次。6.4 我的部署经验和最后的自检清单这篇写到这里我把自己的经验打包成一份自检清单你部署完可以对着过一遍。本地是否能正常访问页面是否执行了构建dist目录是否是最新产物Dockerfile、nginx.conf是否已经确认无误服务器安全组和防火墙是否放行80/443端口域名解析是否生效HTTPS证书是否配置完成改动后是否重新构建镜像并启动新容器有没有设置容器自启动更新脚本和备份脚本是否已经就绪这个清单帮我避免了很多次低级失误。非程序员做部署不靠记性靠的是把流程写成文件、把经验变成脚本。你不需要成为一个运维专家但成为那个“自己能把网站送上线”的人真的会很有成就感。