企业官网建设流程全解析

从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 一张表看清三种路线

选路线的时候别贪。如果你现在只想把一个静态页面发出去，就别先花几天学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，要求：

1. 镜像尽量小，使用 nginx:alpine；
2. 支持单页应用路由刷新不404；
3. 静态资源比如 js、css、图片缓存7天；
4. 请给每行配置加注释解释作用。

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 --restart=always my-website

一条条拆给你看：

• -d：后台运行，关掉终端不影响服务；
• -p 80:80：把服务器的80端口映射到容器内的80端口。冒号左边是服务器端口，冒号右边是容器内端口。外部访问你的服务器80端口，就会被转到容器里Nginx的80端口；
• --name my-site：给这个容器起个名字，后面管理容器都靠它；
• --restart=always：服务器重启或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端口（如果做了HTTPS，443也要放行）。这一步做完，页面通常就通了。

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 --restart=always 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。服务器是Ubuntu，Docker里有一个Nginx容器占用80端口。我想申请Let's 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 --restart=always my-website echo "更新完成，访问 http://你的服务器IP"

把脚本放到服务器项目目录，执行：

chmod +x deploy.sh ./deploy.sh

只要把新的dist文件传入服务器，运行一次脚本，更新就算完成了。你可以让AI把脚本再扩展一下，比如构建之前先备份当前镜像、失败时自动回滚，这些都不难。

6.2 自愈与日志：让容器自动重启

服务器环境不是永远安稳的，偶尔会遇到进程崩溃或者服务器重启。如果想让网站尽可能稳定，记得在启动容器时加上--restart=always参数。

这个参数的作用是：只要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 --restart=always my-website:20250601

如果项目还带了数据库，备份数据库比备份代码更重要。具体怎么备份取决于数据库类型，建议让AI针对你的项目写一份备份脚本，最好加入定时任务，每周自动备份一次。

6.4 我的部署经验和最后的自检清单

这篇写到这里，我把自己的经验打包成一份自检清单，你部署完可以对着过一遍。

• 本地是否能正常访问页面？
• 是否执行了构建？dist目录是否是最新产物？
• Dockerfile、nginx.conf是否已经确认无误？
• 服务器安全组和防火墙是否放行80/443端口？
• 域名解析是否生效？HTTPS证书是否配置完成？
• 改动后是否重新构建镜像并启动新容器？
• 有没有设置容器自启动？
• 更新脚本和备份脚本是否已经就绪？

这个清单帮我避免了很多次低级失误。非程序员做部署，不靠记性，靠的是把流程写成文件、把经验变成脚本。你不需要成为一个运维专家，但成为那个“自己能把网站送上线”的人，真的会很有成就感。