网站做好了没人访问?速查手册:发布网站的两种方法全解析

网站做好了没人访问，这绝对是很多开发者最头疼的噩梦。你花了几个月时间，代码写得漂亮，UI设计得精美，结果上线后流量惨淡，连搜索引擎都找不到你的影子。别急，问题往往出在“发布”这个环节。今天这篇速查手册，不玩虚的，直接拆解发布网站的两种方法：传统FTP/SFTP手动部署和现代CI/CD自动化部署。

很多新手觉得“发布”就是把文件传上去，其实这是最大的误区。发布不仅仅是文件传输，更涉及环境配置、域名解析、SSL证书、SEO友好性等多重技术细节。选错方法，不仅效率低，还容易埋下安全雷区。

1. 两种发布方法的底层逻辑与定位

要搞懂发布网站的两种方法，得先明白它们各自解决什么问题。

方法一：传统手动部署（FTP/SFTP/SSH） 这是最古老、最基础的方式。核心逻辑是“本地开发 -> 打包 -> 手动传输 -> 服务器重启服务”。

• 定位：适合静态网站、个人博客、小型企业官网，或者服务器资源极其有限的场景。
• 特点：门槛低，无需复杂配置，但全凭人力记忆，容易出错，回滚困难。
• 典型场景：WordPress站点更新、简单的HTML5展示页、初期MVP产品验证。

方法二：自动化持续集成/持续部署（CI/CD） 这是现代工程化的标准答案。核心逻辑是“代码提交 -> 触发流水线 -> 自动构建 -> 自动测试 -> 自动部署 -> 自动通知”。

• 定位：适合中大型项目、多环境（测试/预发/生产）、团队协作开发、高并发商城或SaaS平台。
• 特点：标准化、可追溯、可回滚、速度快。
• 典型场景：React/Vue单页应用、Node.js后端服务、微服务架构、需要频繁迭代的业务系统。

核心差异对比表：

很多初学者问：发布网站的两种方法到底怎么选？我的建议是：如果你的项目月更新频率低于2次，且只有1-2个文件变更，手动部署够用。如果每天都在改代码，必须上CI/CD，否则你会在“传文件”这件事上浪费大量生命。

2. 实操步骤与代码配置深度对比

光说理论没用，直接上干货。下面分别给出两种方法的实操细节和关键配置。

方法一：传统手动部署实战

假设你有一个基于Node.js的Express项目，或者是一个纯静态HTML站点。

步骤1：本地打包 如果是静态站，直接压缩dist文件夹。如果是Node项目，需确保node_modules不上传（服务器端安装）。

步骤2：连接服务器 使用WinSCP（Windows）或FileZilla（Mac/Linux）通过SFTP连接。

• 主机：192.168.1.100
• 端口：22
• 用户名：root
• 密码：YourStrongPassword

步骤3：上传与权限设置（关键坑点） 这是发布网站的两种方法中手动部署最容易翻车的地方。

# 在服务器终端执行，假设文件已上传至 /var/www/myapp
# 1. 设置正确权限，Nginx通常以 www-data 或 nginx 用户运行
sudo chown -R www-data:www-data /var/www/myapp# 2. 安装依赖（如果是Node项目）
cd /var/www/myapp
npm install --production# 3. 重启服务（如果使用了PM2）
pm2 restart myapp-name# 4. 检查日志
pm2 logs myapp-name --lines 50

常见错误：

• 403 Forbidden：权限没给对，或者目录缺少index.html。
• 502 Bad Gateway：Node服务没起来，端口被占用，或者Nginx反向代理配置错误。
• CSS/JS 404：本地路径硬编码了localhost，没改成相对路径或动态域名。

方法二：自动化CI/CD实战（以GitHub Actions + Docker为例）

这是目前最主流的方案。我们以一个Vue前端+Node后端的全栈项目为例，使用Docker进行容器化部署。

步骤1：编写Dockerfile

在根目录创建Dockerfile：

# 多阶段构建：第一阶段构建前端
FROM node:18-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build# 第二阶段运行后端
FROM node:18-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY . .
# 将前端构建产物复制到后端静态目录（假设后端提供静态服务）
COPY --from=builder /app/dist ./distEXPOSE 3000
CMD ["node", "server.js"]

步骤2：配置GitHub Actions (.github/workflows/deploy.yml)

name: Deploy to Productionon:push:branches: [ main ]jobs:deploy:runs-on: ubuntu-lateststeps:- name: Checkout codeuses: actions/checkout@v3- name: Set up Docker Buildxuses: docker/setup-buildx-action@v2- name: Login to Docker Hubuses: docker/login-action@v2with:username: ${{ secrets.DOCKERHUB_USERNAME }}password: ${{ secrets.DOCKERHUB_TOKEN }}- name: Build and pushuses: docker/build-push-action@v4with:context: .push: truetags: yourusername/yourapp:latest- name: SSH into Server and Pulluses: appleboy/ssh-action@v0.1.8with:host: ${{ secrets.SERVER_HOST }}username: ${{ secrets.SERVER_USER }}key: ${{ secrets.SERVER_SSH_KEY }}script: |cd /var/www/productiondocker-compose pulldocker-compose up -d

关键优势： 每次git push到main分支，GitHub Actions会自动打包镜像、推送到Docker Hub，然后SSH到服务器拉取最新镜像并重启容器。发布网站的两种方法中，这种方式的原子性极强，要么全部成功，要么全部失败，不会出现“一半文件新、一半文件旧”的灵异现象。

3. 上线部署中的SEO与性能隐形杀手

很多开发者关注代码，却忽略了发布后的“最后一公里”。这部分直接决定了你的网站能不能被百度搜索资源平台收录，能不能获得好的排名。

1. 域名与SSL证书

• HTTPS强制跳转：现代搜索引擎（包括百度、Google）都将HTTPS作为排名因素。如果你只部署了HTTP，流量会流失。
• 证书配置：
  • 手动部署：需手动上传.crt和.key文件到Nginx/Apache配置。
  • CI/CD：建议结合Let's Encrypt的certbot自动化续签脚本，避免证书过期导致网站打不开。

2. 响应时间与TTFB

• TTFB (Time To First Byte)：从用户发起请求到收到第一个字节的时间。
  • 手动部署在老旧VPS上，TTFB常超过500ms。
  • CI/CD结合CDN（如Cloudflare、阿里云CDN），可将TTFB降至50ms以内。
• 优化建议：无论哪种发布方式，务必开启Gzip/Brotli压缩。
  • Nginx配置示例：

  gzip on;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
  

3. 搜索引擎友好性

• robots.txt与sitemap.xml：
  • 发布时，务必确保这两个文件在根目录可访问。
  • 如果使用了CI/CD，建议在部署脚本中加入“生成sitemap”步骤。
• 结构化数据：如果是电商或新闻站，发布时需确保JSON-LD结构化数据正确注入，这有助于在搜索结果中获得富媒体展示。
• 百度站长平台：部署完成后，立即在百度搜索资源平台提交URL，并配置站点地图。不要指望百度能立刻发现你的新站，主动推送是加速收录的关键。

4. 安全加固

• 隐藏版本号：手动部署时，package.json或composer.json若暴露在公网，会被扫描器探测。CI/CD可通过.dockerignore或.gitignore排除敏感文件。
• CSP策略：配置Content-Security-Policy头，防止XSS攻击。
• 备份策略：
  • 手动：记得定期tar -czvf打包备份。
  • CI/CD：利用Docker镜像版本标签（如v1.0.1, v1.0.2），保留最近5个版本，一键回滚。

4. 适用场景与选型建议

回到最初的问题：发布网站的两种方法适合什么场景？这里给出明确的选型建议。

场景A：个人作品集 / 博客 / 静态官网

• 推荐：传统手动部署 或 Netlify/Vercel托管。
• 理由：静态资源无需后端逻辑，FTP上传速度快。或者使用Vercel这类平台，git push即部署，零服务器运维成本。
• 注意：务必开启CDN，否则海外用户访问慢。

场景B：企业官网 / 营销落地页

• 推荐：传统手动部署（配合Nginx）。
• 理由：更新频率低（可能一个月一次），主要是改文案或图片。手动部署成本低，且便于客户自行通过FTP后台修改内容（如果使用了CMS如WordPress）。
• 注意：需配置好Nginx缓存，提升加载速度。

场景C：电商商城 / SaaS平台 / 高频迭代产品

• 推荐：自动化CI/CD（Jenkins/GitLab CI/GitHub Actions + Docker/K8s）。
• 理由：
  1. 数据库迁移：每次发版常伴随数据库结构变更，CI/CD可集成数据库迁移脚本（如Prisma, TypeORM），确保数据一致性。
  2. 多环境管理：开发、测试、预发、生产环境隔离，避免“在我机器上是好的”这种扯皮。
  3. 高可用：配合K8s或Swarm，可实现无停机发布（Blue-Green部署或Canary发布）。
• 注意：初期配置成本高，但长期看ROI（投资回报率）极高。

场景D：微信小程序 / 混合开发

• 推荐：混合模式。
• 理由：前端H5部分可走CI/CD，后端API走传统部署或云函数。需注意微信对HTTPS域名的严格校验，发布前务必检查域名白名单配置。

5. 常见故障排查与避坑指南

在实际操作中，发布网站的两种方法常遇到以下问题，提前知晓可避免90%的焦虑。

1. 域名解析不生效

• 现象：代码传上去了，域名访问还是旧页面或无法访问。
• 原因：DNS缓存。
• 解决：使用nslookup或dig命令检查解析IP是否变更。本地清除DNS缓存（ipconfig /flushdns）。

2. 时区问题导致日志混乱

• 现象：服务器日志时间与北京时间相差8小时。
• 解决：在Dockerfile或服务器配置中统一设置TZ=Asia/Shanghai。

3. 大文件上传失败

• 现象：手动上传视频或大图时，FTP中断。
• 解决：
  • 手动：使用分卷压缩或专用对象存储（OSS/S3）。
  • CI/CD：在Docker构建阶段不处理大文件，直接通过对象存储URL引用。

4. 环境变量泄露

• 现象：config.js中包含数据库密码，被推到GitHub公共仓库。
• 解决：
  • 使用.env文件，并加入.gitignore。
  • CI/CD平台中配置Secrets，构建时注入，绝不硬编码在代码中。

5. 浏览器缓存导致更新不可见

• 现象：用户反馈“改了没生效”。
• 解决：
  • 静态资源文件名加Hash（Webpack/Vite默认支持）。
  • HTML文件设置Cache-Control: no-cache，强制每次检查更新。
  • 静态资源设置Cache-Control: max-age=31536000，长期缓存。

结语

发布网站的两种方法，本质上是效率与稳定性的博弈。没有绝对的好坏，只有是否匹配你的项目阶段和团队能力。

对于初学者，建议从手动部署开始，理解服务器、Nginx、端口、权限的基本原理。当项目复杂度上升，团队规模扩大，再平滑迁移到CI/CD。这个过程本身，也是技术成长的最佳路径。

记住，发布不是终点，而是运维和优化的起点。关注百度搜索资源平台的数据反馈，持续监控网站性能和安全日志，才能让网站真正“活”起来，吸引到源源不断的访问。

你的网站用的什么技术栈？评论区聊聊