毕设项目部署到服务器教程：从本地到公网访问

摘要

毕设和课程设计往往需要一个能公网访问的地址，用于答辩演示、导师查看或作品展示。本文完成一个学生项目从本地到公网的部署，涵盖配置选择与成本控制、环境准备、常见技术栈（Java、Python、Node.js、前端）的部署方式、数据库配置、域名与 HTTPS、答辩前的稳定性检查，以及演示当天的应急预案。

一、部署前的准备判断

先明确要部署什么

不同类型的项目部署方式差别很大：

配置怎么选

学生项目的访问量通常很小，主要是自己测试、导师查看和答辩演示，几个人同时访问就是峰值。不需要高配置。

成本控制的几个实用建议

学生项目通常预算有限，有几点值得注意：

• 按实际需要的时长购买。 如果只需要用到答辩结束，不必买一年。但要注意备案对购买周期有要求，需要域名访问时要提前规划。
• 优先考虑学生优惠。 云服务商通常有面向学生的优惠方案，可以在官网查询当前可用的活动。
• 用 IP 直接访问可以省掉域名和备案环节。 如果只是答辩演示，用服务器 IP 加端口访问完全可行，能省下备案的时间成本。需要正式域名时再补。
• 答辩结束后及时处理实例。 如果项目不再需要维护，记得释放实例避免继续计费。想保留作品的话，可以先做一份快照或备份，再决定是否长期保留。

关于地域和备案，这一点影响项目排期

如果要用域名访问且服务器在中国内地，必须先完成 ICP 备案，备案通过后网站才能正常访问。备案需要域名已实名认证、服务器为包年包月且剩余时长满足要求，审核也需要时间。

对时间紧张的毕设项目，有两个务实选择：

• 直接用服务器 IP 加端口访问，不绑定域名，跳过备案。
• 选择中国香港等地域的实例，无需备案即可用域名访问。

不要在答辩前一周才开始考虑备案，时间上很可能来不及。

二、准备服务器与端口

操作系统建议 Ubuntu 22.04 或 24.04，社区资料多，遇到问题容易搜到解决方案。

需要放通的端口：

轻量应用服务器在实例详情页的「防火墙」页签点击「添加规则」，协议选 TCP、填入端口、策略选允许；云服务器 CVM 在安全组的「入站规则」中添加。

这里有个新手最常踩的坑：应用在服务器上跑起来了，本机 curl 也能访问，但从自己电脑的浏览器打不开。原因几乎都是端口没在控制台放通。系统内的防火墙和控制台的防火墙是两层，都要通。

登录服务器：

ssh root@服务器公网IP

首次登录后建议先更新系统：

sudo apt update && sudo apt upgrade -y

三、按技术栈部署

方式一：用容器部署（推荐）

如果项目已经有 Dockerfile，或者你愿意写一个，容器方式最省事——环境依赖都打包在镜像里，不会出现本地能跑服务器跑不起来的情况。

先安装 Docker：

curl -fsSL https://get.docker.com | sudo sh
sudo usermod -aG docker $USER
newgrp docker

以一个包含应用和数据库的项目为例，编写 compose.yaml：

services:
  db:
    image: mysql:8.0
    environment:
      MYSQL_ROOT_PASSWORD: 替换为强密码
      MYSQL_DATABASE: myproject
      MYSQL_USER: appuser
      MYSQL_PASSWORD: 替换为强密码
    volumes:
      - db-data:/var/lib/mysql
    restart: unless-stopped

  app:
    build: .
    ports:
      - "8080:8080"
    environment:
      DB_HOST: db
      DB_NAME: myproject
      DB_USER: appuser
      DB_PASSWORD: 与上面保持一致
    depends_on:
      - db
    restart: unless-stopped

volumes:
  db-data:

注意 DB_HOST: db 用的是容器服务名。填 localhost 一定连不上，因为在容器内这个地址指向容器自身，不是数据库容器。这是容器化部署最高频的错误。

启动：

docker compose up -d
docker compose ps
docker compose logs -f app

方式二：直接在系统上部署

Java 项目（Spring Boot）

sudo apt install -y openjdk-17-jdk
java -version

把打包好的 jar 文件上传到服务器：

scp target/myapp.jar root@服务器IP:/opt/myapp/

配置为系统服务，这样断开 SSH 后程序仍在运行：

sudo tee /etc/systemd/system/myapp.service > /dev/null <<'UNIT'
[Unit]
Description=My Project
After=network.target

[Service]
Type=simple
User=ubuntu
WorkingDirectory=/opt/myapp
ExecStart=/usr/bin/java -Xmx512m -jar /opt/myapp/myapp.jar
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target
UNIT

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp --no-pager

-Xmx512m 限制 Java 堆内存。2 GB 内存的机器上不加限制，Java 可能占用过多内存导致系统卡死。

Python 项目（Django / Flask）

sudo apt install -y python3-pip python3-venv
cd /opt/myapp
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
pip install gunicorn

不要用开发服务器跑正式演示。 Django 的 runserver 和 Flask 的内置服务器都是开发工具，性能和稳定性都不适合对外提供服务。用 Gunicorn 这类生产级服务器：

gunicorn -w 2 -b 127.0.0.1:8000 myproject.wsgi:application

同样配置为系统服务，ExecStart 指向虚拟环境中的 gunicorn。

Node.js 项目

curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt install -y nodejs
node -v

安装依赖并构建：

cd /opt/myapp
npm ci --omit=dev
npm run build

用进程管理工具保持运行：

sudo npm install -g pm2
pm2 start npm --name myapp -- start
pm2 startup
pm2 save

pm2 startup 和 pm2 save 让应用在服务器重启后自动恢复。

纯前端项目

构建后把静态文件交给 Web 服务器：

sudo apt install -y nginx
sudo cp -r dist/* /var/www/html/

前端路由使用 history 模式时，需要配置将未匹配的路径回退到入口文件，否则刷新子页面会 404：

location / {
    try_files $uri $uri/ /index.html;
}

四、配置数据库

如果不是容器化部署，需要单独装数据库：

sudo apt install -y mysql-server
sudo mysql_secure_installation

安全向导中建议：启用密码强度校验、设置 root 密码、移除匿名用户、禁止 root 远程登录、删除测试库。

为项目创建独立的库和账号：

CREATE DATABASE myproject CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'appuser'@'localhost' IDENTIFIED BY '强密码';
GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX ON myproject.* TO 'appuser'@'localhost';
FLUSH PRIVILEGES;

字符集必须用 utf8mb4。 MySQL 中的 utf8 只支持三字节字符，存不了 emoji 和部分生僻字。毕设项目里如果有用户输入内容，用错字符集会在演示时出现乱码或写入报错。

不要用 root 账号连数据库。 除了安全考虑，用受限账号还能避免代码里的误操作删掉整个库。

导入本地的数据结构和测试数据：

mysql -u appuser -p myproject < schema.sql
mysql -u appuser -p myproject < data.sql

数据库端口不要对公网放通。 应用和数据库在同一台机器时，数据库只监听本机是最安全的。3306 端口对公网开放会立刻遭到扫描和爆破尝试。

五、配置反向代理与 HTTPS

直接暴露应用端口（如 8080）能用，但有几个问题：地址要带端口不好记、没有 HTTPS、多个服务无法共用 80 端口。用反向代理解决。

用 Nginx

sudo nano /etc/nginx/sites-available/myapp

server {
    listen 80;
    server_name myproject.example.com;

    client_max_body_size 50M;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

启用并重载：

sudo ln -s /etc/nginx/sites-available/myapp /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

nginx -t 先检查语法，避免配置错误导致服务起不来。

如果项目有文件上传功能，client_max_body_size 必须设够大。默认值很小，上传稍大的文件就会失败并返回 413，这在演示时很尴尬。

配置 HTTPS

有域名的话申请免费证书：

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d myproject.example.com

答辩演示强烈建议配 HTTPS。 浏览器会对 HTTP 页面标记"不安全"，如果项目有登录功能，还会在密码框旁提示警告，演示时观感很差。

只用 IP 访问时无法申请受信任的证书，这种情况可以接受 HTTP，但要向老师说明这是演示环境的限制。

六、答辩前的检查清单

这一节是这篇文章最实用的部分。很多项目本身没问题，却在答辩当天出状况。

功能验证

• 从自己电脑之外的网络访问，例如用手机流量。在校园网内能访问不代表公网可访问。
• 走完所有要演示的功能路径，不要只测首页。
• 注册、登录、提交、查询、上传等每个环节都实际点一遍。
• 用手机浏览器打开一次，确认移动端不会完全错版。
• 检查中文内容是否正常显示，没有乱码。

稳定性验证

• 重启服务器，确认所有服务能自动恢复。 这是最容易被忽略的一项。如果应用、数据库、Nginx 中有任何一个没配开机自启，服务器意外重启后项目就挂了：

sudo reboot
# 等待重启后重新登录
sudo systemctl status myapp nginx mysql --no-pager

• 让服务连续运行至少一天，观察是否有内存泄漏或崩溃：

free -h
sudo systemctl status myapp --no-pager

• 让几个同学同时访问，确认并发下不会出错。

数据准备

• 准备好演示数据。空数据库的界面演示效果很差。
• 数据内容要合适，不要用真实的个人信息或不当内容做测试数据。
• 导出一份数据库备份，万一演示中数据被误操作，可以快速恢复。

创建快照

答辩前给实例创建一份快照，这是最有效的保险。轻量应用服务器在实例详情页的「快照」页签点击「创建快照」，通常 5 分钟内完成且无需关机。

如果演示前项目出了问题，可以回滚到已知正常的状态。需要注意回滚会把整块系统盘恢复到快照时间点，之后的数据变更会被清除，运行中的实例会自动关机。使用存储型套餐的实例不支持创建快照。

准备应急预案

这一点很多人不做，但确实有用：

• 录一段演示视频。网络故障、服务器异常时可以放视频，不至于完全无法展示。
• 准备本地可运行的版本。极端情况下用本地环境演示。
• 把关键页面截图保存。至少能说明功能做出来了。
• 记录服务器 IP、SSH 登录方式、各服务的重启命令，出问题时能快速处理。

答辩现场的网络环境往往不受你控制，有备份方案会让你从容很多。

七、常见问题与排查

本机能访问，外网打不开

按顺序检查：控制台防火墙或安全组是否放通对应端口；应用监听地址是否为 0.0.0.0 而非仅 127.0.0.1（如果没用反向代理）；系统内防火墙是否放通。

查看监听情况：

sudo ss -lntp

SSH 断开后程序就停了

程序是在前台运行的。必须配置为系统服务或用进程管理工具托管，不要用 nohup 加 & 这种临时方式跑正式演示。

服务启动失败

查看日志定位：

sudo journalctl -u myapp -n 50 --no-pager
# 或容器部署
docker compose logs app --tail 50

常见原因：端口被占用、配置文件路径错误、数据库连不上、依赖缺失、内存不足。

数据库连接失败

检查数据库服务是否运行、用户名密码是否正确、连接地址是否正确。容器化部署时地址应填容器服务名。

中文显示为乱码或问号

字符集问题。确认数据库、表、字段和应用连接配置都使用 utf8mb4。

页面样式丢失或接口请求失败

前后端分离项目中，前端配置的接口地址可能还指向本地的 localhost。检查前端构建时的接口地址配置，改为实际的公网地址或相对路径。

内存不足导致服务被终止

free -h
dmesg | grep -i "killed process"

2 GB 内存的机器上跑 Java 应用加数据库会比较紧张。处理方式：限制 Java 堆内存、调小数据库缓冲池、或升级配置。

上传文件失败

检查反向代理的请求体大小限制和应用自身的上传配置，两处都要放宽。

八、后续维护与合规

如果项目要长期保留

• 建立定期备份，把数据库和上传的文件备份到服务器之外。
• 及时更新系统安全补丁。
• 关注磁盘和内存水位。
• 修改所有默认密码，不要留着简单密码长期对外运行。

如果项目答辩后不再需要

• 先做一份完整备份或快照保留成果。
• 代码推到自己的代码仓库保存。
• 释放实例避免继续计费。
• 如果注册了域名，注意续费提醒。

几条容易忽略的安全事项

学生项目常常在安全上比较随意，但它是公网可访问的，需要注意：

• 数据库端口不对公网开放。
• 不要在代码中硬编码密码、密钥，尤其不要提交到公开的代码仓库。已经提交的要彻底清理历史。
• 管理后台设置强密码，不要用 admin/123456 这类组合。
• 关闭调试模式。生产环境开着调试模式会暴露代码路径、配置信息和错误堆栈。
• 如果项目有文件上传功能，限制上传的文件类型，不要允许任意文件上传。

关于数据合规

• 演示数据不要使用真实的他人个人信息。需要用户数据时，用明显虚构的测试数据。
• 如果项目确实需要收集用户信息（例如做用户调研），要告知用途并获得同意，用完及时删除。
• 不要在项目中使用未获授权的第三方素材，包括图片、字体、数据集。使用开源代码要遵守其许可协议，并在文档中标注来源。
• 如果项目使用了公开数据集，注意其使用条款，部分数据集限制商业用途或要求引用出处。

项目部署上线后，如果需要为它建立更完善的备份机制，或后续想把它作为长期作品维护，可以作为下一步方向。

学生项目和小型应用部署，轻量应用服务器的套餐式规格和可视化控制台比较适合上手，配合快照能在答辩前留一份保险；需要跑模型推理的项目可以考虑高性能应用服务 HAI 的 GPU 环境，备份归档可使用对象存储 COS。