企业官网建设流程全解析

从零到上线：把“未来树洞”部署到宝塔云服务器

如果你手里有一个已经写完、但还躺在本地跑的小项目，想让它真正上线，让朋友、网友能通过域名访问，那这篇内容就是为你准备的。我上个月刚把“未来树洞”这个匿名情绪倾诉社区从本地开发环境搬到了宝塔云服务器，走完了购买云服务器、安装宝塔面板、配置Nginx反向代理、部署Node.js后端、构建前端、上HTTPS证书这一整套流程，中间踩了不少坑，也总结了一整套可以直接照搬的部署方案。

“未来树洞”是一个典型的全栈Web应用：用户可以匿名写下心事、吐槽或者任何想说的话，其他用户可以浏览这些树洞内容、点赞和评论。它的核心逻辑不复杂，但部署链路涉及的东西很全——前端构建、后端进程守护、数据库初始化、域名解析、反向代理、SSL证书，几乎把个人项目上线的所有环节都覆盖了一遍。无论你手上的项目是Vue+Spring Boot、React+Flask，还是和“未来树洞”一样的Vue3+Node.js，这套部署思路都能迁移过去。花几分钟看完，你也能把自己的项目从零部署到线上。

1. 项目梳理与技术选型

1.1 “未来树洞”核心功能拆解

在动手部署之前，我先把自己的项目边界理清楚，这样部署的时候才知道要准备哪些东西。“未来树洞”的功能不算多，但每一块都会影响部署方案的选择。

一是匿名发布树洞内容，用户只需要输入昵称（也可以直接用“匿名”）、选择一种情绪标签（开心、难过、焦虑、困惑、日常），再写一段文字就能发布；二是树洞广场，按最新或者热门排序展示所有树洞内容，支持无限滚动加载；三是互动功能，包括点赞和评论，每个树洞下面可以看到点赞数和评论列表；四是内容管理后台，管理员登录后可以删除违规内容、屏蔽恶意用户；五是移动端适配，因为树洞类产品大多数用户会通过手机访问。

功能梳理完之后，部署要点其实已经很清晰了：需要一个支持Web服务的Linux环境，需要一个数据库来存树洞内容和用户互动数据，需要能跑Node.js进程并保持它常驻运行，还需要把前端构建后的静态文件交给Nginx托管，同时通过反向代理把API请求转发给后端服务。

1.2 技术栈选型与部署方案取舍

“未来树洞”的技术栈选的是：前端Vue 3 + Vite，后端Node.js + Express，数据库MySQL 8.0，服务器是Linux系统，面板用宝塔，进程守护用PM2，Web服务器用Nginx。这套组合是我在实际部署中反复验证过的，也是个人项目上线性价比最高的方案之一。

为什么不选前后端不分离的写法？因为树洞广场、无限滚动、点赞动画这些交互用前后端分离开发效率更高，而且部署时前端构建成纯静态文件、后端独立跑服务，反而是更干净的架构，排查问题也方便。为什么不选Docker？不是不能用，而是对于一台2核4G的轻量云服务器、一个体量不大的个人项目，宝塔面板直接安装LNMP环境，再配合PM2守护Node进程，已经能覆盖全部需求，还省去了学习编排、维护容器的额外负担。后面项目真到了需要横向扩展的程度，再引入容器化也不迟。

选择宝塔面板而不是纯命令行部署，主要是因为它把Linux服务器的运维操作图形化了。创建网站、申请SSL证书、管理数据库、设置计划任务、查看CPU内存监控，这些高频操作在面板里都是点几下的事情。要知道服务器部署这回事，最麻烦的不是安装软件，而是把链路串起来的那几十个配置项，宝塔把这些配置项的入口都整合好了，能大大降低出错概率。

1.3 部署链路全貌

在开始操作前，我先把整条链路的流转画在脑子里：用户浏览器输入域名，DNS把域名解析到云服务器IP，请求到达Nginx的80或443端口；Nginx收到请求后，如果是静态资源请求（HTML、JS、CSS、图片），就直接返回前端构建产物；如果是/API开头的请求，就通过反向代理转发到本地某个端口上运行的Node.js后端进程；Node.js后端接到请求后，去MySQL数据库读写数据，返回JSON给前端。整个过程中，PM2负责保证Node.js进程一直在运行，宝塔面板负责管理Nginx、MySQL、文件、备份这些基础设施。

这条链路只要任何一个环节断了，网站就会出现问题：域名没解析好，访问不了；Nginx配置错误，报502；Node进程挂了，所有API失效；数据库连接不通，登录和发布都会失败。所以部署时我建议按“底层到上层”的顺序操作：先配置服务器基础环境，再装数据库，再部署后端，再部署前端，最后统一做域名和HTTPS，这样可以最大化减少排查问题的成本。

2. 服务器与宝塔面板部署前的准备

2.1 云服务器选型与购买配置建议

“未来树洞”对服务器的要求其实不高，我最终选的是一台2核4G内存、40G SSD磁盘、5M带宽的轻量云服务器，跑当前这个体量绰绰有余。如果你只是测试或给几十个朋友用，2核2G也够跑，但4G内存会更从容——因为MySQL和Node.js同时运行，加上系统本身，内存占用一般在1.5G到2G之间，如果再开个构建任务或者日志积累多了，2G内存就会捉襟见肘。

购买时有两个容易忽略的点。第一是系统镜像选择，我建议选Ubuntu 22.04 LTS或者Debian 12，这两者都是社区维护活跃、兼容性好的长期支持版本，宝塔面板对它们的支持也最稳定；不建议选太老的系统版本，比如CentOS 7已经停止更新维护了，装软件时经常碰到源不可用的问题。第二是安全组和防火墙端口，购买后一定要在云厂商控制台的安全组里放行几个关键端口：80（HTTP）、443（HTTPS）、22（SSH登录），如果宝塔面板的端口不是默认的8888，也要一并放行。这个操作很容易漏，漏了之后的表现就是：服务器在运行，宝塔面板也装了，但浏览器就是访问不到。

2.2 宝塔面板安装与初始化

拿到服务器之后，第一步是安装宝塔面板。用SSH客户端（我习惯用FinalShell，也可以用Termius或Xshell）登录服务器，然后用官方安装脚本一键安装。等它跑完，会输出面板的访问地址、用户名和随机密码，这些信息要先保存好，建议立刻登录进去修改成自己的密码。

安装完成后，进入面板，在首页的“软件商店”里安装LNMP环境——一键安装Nginx、MySQL 8.0、PHP（这个项目用不到PHP，但宝塔默认会装，可以不用管它）。这一步耗时较长，因为要下载编译软件包，耐心等就行。安装过程中要注意MySQL的初始密码，面板会生成一个账号和随机密码，必须记录下来，后续配置后端连接数据库时会用到。

初始化阶段还有几个顺手就该做的事：把面板的HTTPS证书开启（宝塔已经内置了免费证书申请）；修改面板默认端口，不要把8888裸奔在公网上；开启面板的BasicAuth认证或者只允许指定IP访问面板。这些操作加起来不超过五分钟，但能让你的服务器安全系数提升一大截。

2.3 域名购买、备案与DNS解析

公网IP虽然能访问，但没人会记一长串数字，而且很多云厂商都会限制未绑定的IP直接通过浏览器访问80端口，所以正规上线一定要有一个域名。“未来树洞”我注册的是future-treehole.com，域名商很多，阿里云、腾讯云、Cloudflare都可以，看哪里买便宜就好。

域名解析本身很简单，在域名服务商的控制台添加一条A记录，把主机记录填www（也有人会把@根域名一起去解析，我建议两个都解析），记录值填服务器的公网IP，TTL用默认的十分钟到半小时即可。

如果服务器在中国大陆境内，域名还需要完成ICP备案，这个过程一般需要一至两周，是纯等待的时间，可以放在项目部署之后并行推进。我这里要提醒的是，如果暂时没有备案，或者服务器在香港、新加坡等地区，就不需要等备案，但访问速度对境内用户来说会有一定延迟。“未来树洞”的服务器在境内，所以备案这条线我一直在同步处理，不耽误后面的部署操作。

3. 项目代码分析与数据库准备

3.1 项目目录结构梳理

部署之前，先把自己的项目目录梳理清楚。这一步非常重要，很多人在本地开发时目录结构随手写，结果到服务器上找不到该上传哪些文件。“未来树洞”的目录结构大致是这样：

future-treehole/ ├── client/ # 前端工程 │ ├── src/ │ ├── dist/ # build后的产物目录 │ ├── vite.config.js │ └── package.json ├── server/ # 后端工程 │ ├── routes/ # API路由 │ ├── app.js # Express应用入口 │ ├── config.js # 数据库和端口配置 │ ├── package.json │ └── uploads/ # 如果有上传文件，就放在这 └── deploy/ # 部署相关脚本和配置备份

前端和后端分开两个独立工程，部署的时候就好办：前端只需要构建产物dist目录，其余源码不需要上传到服务器（除非要做持续集成）；后端需要把整个目录上传，并安装生产依赖。如果你没有把项目推到Git仓库托管，建议先推一下，因为用git在服务器上拉取代码比用FTP上传整个目录要稳得多，而且后续更新代码也方便。

3.2 数据库表设计与初始化

“未来树洞”的数据库不算复杂，主要设计了四张表：treeholes表存储树洞内容，字段包括id、nickname、emotion_tag、content、like_count、comment_count、status、created_at；comments表存评论，关联treehole_id；users表存管理员（用户名、密码哈希、角色）；likes表做用户点赞去重，记录ip或user_id和treehole_id的组合，保证同一个人不能重复点赞。

在设计表的时候，我把索引都提前建好了：treeholes表的created_at字段建普通索引用于按时间倒序分页查询，status字段建索引用于筛选正常内容；likes表用(treehole_id, user_id)做唯一联合索引，既防止重复点赞，也加速统计。这些在数据量小的时候体现不出差异，但上线后如果有人把“未来树洞”发到社交平台引来一波流量，带索引的查询和全表扫描的执行效率完全不一样。

在宝塔面板的“数据库”菜单里，创建一个新数据库，比如命名future_treehole，字符集选择utf8mb4，排序规则选utf8mb4_unicode_ci。然后在SSH里把本地导出的SQL文件导入到线上库，命令大致是：

mysql -u future_treehole -p future_treehole < future_treehole.sql

输入数据库密码后，如果没有任何报错输出，数据就导入成功了。“未来树洞”本地的测试数据不多，也就几十条，迁移很快。如果你本地也有数据要迁，务必先确认SQL文件编码是UTF-8，不然中文内容会变成乱码。

3.3 后端接口与配置要点

后端用Express写的，接口大致分这几组：POST /api/treehole 发布树洞、GET /api/treehole 分页获取树洞列表、GET /api/treehole/:id 获取单条及评论、POST /api/comment 发表评论、POST /api/like 点赞、POST /api/admin/login 管理员登录、DELETE /api/admin/treehole/:id 删除违规内容。

部署前有一个配置项必须改，就是数据库连接。我习惯在config.js里把数据库连接信息集中管理，用环境变量传入，不在代码里写死生产库的密码。例如：

module.exports = { db: { host: process.env.DB_HOST || 'localhost', user: process.env.DB_USER || 'root', password: process.env.DB_PASSWORD || '', database: process.env.DB_NAME || 'future_treehole', }, port: process.env.PORT || 3000, };

另外还要确认一个端口问题：Node后端监听哪个端口，一定要固定下来。“未来树洞”的服务监听3000端口，监听的地址是0.0.0.0，如果只监听127.0.0.1，Nginx代理转发时会连接失败。还有CORS跨域问题，开发环境前端在5173端口、后端在3000端口，属于跨域，我在代码里用cors中间件放行了所有来源；生产环境前端和API都在同一个域名下，不跨域，所以正式部署时保持cors配置为放行模式也不影响，但如果你的后端接口只允许自己的域名访问，可以把origin改成具体的线上域名。

3.4 前端构建与环境变量配置

前端工程用的是Vue3+Vite，构建前需要确认API请求的基础地址。这里有一个常见的坑：如果在代码里写死了开发环境的API地址（比如http://localhost:3000/api），构建后生产环境就会一直请求本地地址，页面全部报错。我的做法是用Vite的环境变量，在client目录下建一个.env.production文件，写入VITE_API_BASE_URL=/api，然后在代码里统一用这个变量拼接口请求路径。这样前端和后端在同一个域名下，符合Nginx反向代理的配置逻辑。

本地执行npm run build之后，会在client/dist目录生成纯静态文件。这一套文件后面要上传到服务器，由Nginx托管。构建过程中如果遇到依赖版本冲突或者内存溢出（Vite构建大项目时偶发），可以设置NODE_OPTIONS="--max-old-space-size=2048"来增加Node执行内存，或者删除node_modules和package-lock.json重装依赖再构建。

4. 部署实操全记录

4.1 在宝塔面板创建站点并配置反向代理

在宝塔面板的“网站”菜单里，点击“添加站点”，域名填API用的域名或主域名都可以，纯静态或PHP都不用选（因为“未来树洞”自身不带PHP），直接创建静态站点就行。创建完成后，宝塔会在/www/wwwroot/目录下生成一个以域名命名的文件夹，用于放前端文件。

接下来核心一步是配置Nginx的反向代理。找到站点的“配置文件”，在server块里加入或修改 location配置，让前端静态文件请求和API请求走不同的处理逻辑：

server { listen 80; server_name future-treehole.com www.future-treehole.com; root /www/wwwroot/future-treehole.com/dist; index index.html; location / { try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:3000; 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; } }

这里的几个关键点要说明一下：try_files的作用是配合前端history路由模式，让用户刷新某个二级页面时请求始终回到index.html，由VueRouter接管路由，不配置这个会刷新404；proxy_pass后面写的是后端Node服务的地址和端口，注意末尾不要拼路径，这样/api/开头的请求会原样转发给Node服务，比如请求/api/treehole，Node端接收到的路径就是/api/treehole；别忘了加Host和X-Forwarded开头的header，后端的Express应用拿到真实客户端IP和协议，对做访问日志、风控都有用。

配置完先点击“保存”，然后要点“重载配置”让Nginx生效。这里有个检查技巧：在SSH执行nginx -t，如果输出syntax is ok、test is successful，说明配置语法没问题；如果报错，通常是指令写错或者少加分号，把报错行对应检查一下就行。

4.2 上传后端代码与安装生产依赖

前端站点创建好之后，我把后端代码上传到服务器的/usr/local/future-treehole-server目录，不要去放在站点目录里（前端静态文件和后端代码分离，后续更新互不干扰）。上传方式我用的是宝塔面板自带的文件管理器，直接压缩打包后端目录为zip，上传到服务器后在面板里解压，比FTP快也省事。如果你的代码已经推到Git仓库，也可以直接在服务器上执行git clone，后续更新就是git pull加重启进程，效率更高。

进入后端目录，安装生产依赖：

cd /usr/local/future-treehole-server npm install --omit=dev

这一步需要一点耐心，“未来树hole”后端依赖了Express、mysql2、jsonwebtoken、cors、multer等，按现在的网络环境一般一两分钟就能装好。装完后建议手动试运行一下，先设置环境变量再启动：

export DB_PASSWORD=你的数据库密码 node app.js

看到控制台输出类似“Server running on port 3000，数据库连接成功”的字样后，说明后端在服务器上能正常跑起来。这时候顺手用curl验证一下API是不是通的：

curl -I http://127.0.0.1:3000/api/treehole

如果返回HTTP/1.1 200 OK，说明接口可以正常访问。确认没问题后，按Ctrl+C停掉这次手动启动，接下来正式交给PM2托管。

4.3 使用PM2守护后端进程

手动启动的问题是：SSH窗口一关，进程就没了；而且如果进程意外崩溃，网站就彻底挂了。所以必须用PM2来做进程守护和开机自启。先全局安装PM2：

npm install -g pm2

然后启动后端并设置开机自启：

pm2 start app.js --name future-treehole --update-env pm2 save pm2 startup

pm2 startup命令执行完会输出一条系统级命令，需要复制那条命令再执行一次，才能完成开机自启的注册。不要跳过这一步，不然服务器重启后PM2不会自动拉起Node进程，网站就“神秘失踪”了。

日常运维常用的PM2命令也顺便列一下：pm2 logs future-treehole查看实时日志，pm2 restart future-treehole重启应用，pm2 stop future-treehole停止应用，pm2 status查看所有进程的运行状态。PM2接管后，就算进程崩溃，它会在几秒内自动重启，这就是所谓“守护进程”的意义。

4.4 上传前端构建产物并配置HTTPS证书

后端跑通之后，把本地的client/dist目录上传到服务器站点目录下，也就是我上面Nginx配置里root指定的 /www/wwwroot/future-treehole.com/dist。上传完成后，先用IP或者临时配置的域名访问一下，看看页面是否能正常打开。此时如果没有配置HTTPS，浏览器会提示不安全，这属于正常现象，还没到配证书那步。

接下来配置HTTPS。宝塔面板有一个很省心的功能：在站点设置里选择“SSL”，勾选“Let's Encrypt”免费证书，填写域名，自动签发并部署。整个过程一般几十秒就完成。签发完之后，面板会自动帮你在Nginx配置里加入证书路径和443监听，还会生成HTTP强制跳转HTTPS的规则。我需要确认的是，证书能正常续期——宝塔通常会自动续期，不用自己管。

强制HTTPS之后，之前写的反向代理配置里X-Forwarded-Proto参数就起作用了，后端可以通过req.headers['x-forwarded-proto']识别用户是用HTTPS还是HTTP访问的，这对需要生成绝对链接的场景很有用。“未来树洞”目前没有这种需求，但日志里能看到访问协议，排查混合内容问题时也有帮助。

4.5 全链路联调与上线确认

所有模块都部署完，最后要进行一次完整的线上联调。我列了一个检查清单，照着跑一遍基本能覆盖所有核心功能：

• 浏览器输入https://future-treehole.com，首页能打开，且锁定图标显示证书有效
• 前端页面能正常加载CSS和JS资源，打开开发者工具的Network面板，所有静态资源请求都返回200
• 访问一个API接口，比如GET /api/treehole，Network里显示请求成功，返回JSON数据
• 发一条树洞内容，能正常写入数据库；刷新页面，内容出现在列表中
• 点赞、评论功能可用，点赞数实时更新
• 用管理员账号登录后台，能查看到树洞列表，删除一条违规内容，前端对应内容消失
• 手机浏览器访问，页面自动适配，布局不变形

其中第2和第3条如果出现连着好几个请求是红色或者404，问题大都在Nginx配置上；如果页面能打开但数据全是空的，问题多半在后端或数据库连接上。这些我会在下面常见问题部分详细展开排查思路。

5. 上线后的安全加固与日常维护

5.1 服务器安全加固清单

上线不等于万事大吉，反而意味着服务器开始暴露在公网环境下。“未来树洞”上了线之后，我做的第一件事是加固服务器安全，这些操作建议每个部署个人项目的人都认真做一遍。

第一，修改SSH端口。默认的22端口每天会被大量僵尸程序暴力扫描，改成比如2299端口能大幅减少被扫描的几率。改端口在宝塔面板的“安全”菜单里就可以操作，改完记得在云厂商安全组里同步放行新端口，同时关掉旧的22端口。第二，设置宝塔面板的访问安全，把默认的8888端口改成其他端口，并开启面板SSL。第三，数据库不允许外网直接连接，MySQL只监听127.0.0.1即可，宝塔默认就是这样的配置，手动确认一下就行。第四，创建专门的数据库账号，不要用root连应用，给“未来树洞”的应用账号只授权future_treehole库的增删改查权限，这样即使代码被注入攻击，数据库层面的损失也被控制在单库范围内。第五，如果有邮件服务或者后台登录功能，设置登录失败次数锁定，防止暴力破解密码。

安全加固这件事，不做不一定会立刻出问题，但一旦出问题，轻则被植入挖矿程序拖慢服务器速度，重则数据库被勒索、用户数据泄露。个人项目也是项目，隐私数据泄露的责任一点都不比大公司少。

5.2 数据备份策略与恢复演练

“未来树洞”的数据库是核心资产，用户发布的树洞内容、评论互动数据，一旦丢失基本无法找回。所以部署完成后，我立刻在宝塔面板的“计划任务”里配置了自动备份。

我设置的备份策略是：每天凌晨3点，通过面板的备份功能自动备份数据库future_treehole，同时把站点目录（包括上传文件）一起打压缩包，保留最近7天的版本。面板支持把备份存到服务器本地，也可以配置云存储（比如阿里云OSS、腾讯云COS），这里建议至少要有一份异地备份，避免服务器硬件故障导致本地备份一起丢失的极端情况。

定时备份配置好之后，我还做了一次恢复演练：把备份文件下载到本地，用另一个空的MySQL实例导入，确认能完整还原。这个步骤很多人会省略，但真到了需要恢复的那天，你才会发现备份文件是不是可用的。备份的目的是恢复，不是为了产生一个压缩包摆在服务器里自欺欺人。

5.3 日志查看与监控告警

网站上线后，日常做的最多的操作就是看日志。PM2负责后端日志，默认输出在~/.pm2/logs目录下，我习惯在宝塔面板的“文件”菜单里打开这个目录，或者直接用pm2 logs future-treehole命令实时滚动查看。Nginx的访问日志和错误日志在/www/wwwlogs目录下，比如future-treehole.com.access.log和future-treehole.com.error.log。当用户反馈页面出错时，先去看错误日志，通常能直接定位到是静态资源问题还是后端接口问题。

宝塔面板本身有资源监控功能，可以看到CPU、内存、网络流量的实时走势。我给“未来树洞”设置了一个简单的“人工告警机制”：每天登录一次面板看一眼CPU和内存占用，如果CPU长时间超过80%，或者内存占用接近上限且不回落，就说明可能有异常进程或流量攻击，需要上服务器排查。

6. 部署过程中我踩过的坑和排查实录

6.1 502 Bad Gateway，后端连不上

有一次我在配置完反向代理后，刷新页面发现所有API请求都返回502 Bad Gateway。先检查后端进程状态，pm2 status显示started，但后来发现端口监听的是localhost（127.0.0.1），而配置里写的是内网IP或另一个地址，导致Nginx转发失败。我的解决方法是：统一让Node进程监听127.0.0.1这个地址，Nginx的proxy_pass也指向http://127.0.0.1:3000，两边保持一致就再不会出这个问题。

还有另一种可能，就是后端进程确实没起来。可以执行pm2 logs future-treehole查看日志，看有没有报错信息，比如数据库连接失败或者Node语法错误。解决思路是优先看日志，而不是反复重启。

6.2 前端调接口出现跨域报错

上线前我一度担心CORS问题，因为开发环境前后端端口不同，我在后端引用了cors中间件并设置origin为true，放行所有来源。上了生产环境后，由于前端和API同域，其实不跨域，所以问题没出现。

但如果你把前端放在A域名、API放在B域名，比如前端用静态托管、后端用云服务器，就一定会遇到跨域问题。这时要么在后端cors里配置具体的域名白名单，要么还是通过Nginx反向代理把API和前端放在同一个域名下更稳妥。我的建议是：个人项目尽量同域部署，少一个跨域变量，少一个坑。

6.3 MySQL连接失败，端口和账号权限有问题

数据库连接失败是比较常见的问题，报错一般是ER_ACCESS_DENIED_ERROR或者connect ECONNREFUSED。出现这个报错时，我先在SSH里手动连一下数据库验证账号是否可用：

mysql -u future_treehole -p -h 127.0.0.1

如果账号密码错误，就去宝塔面板重置密码，然后更新后端config.js或环境变量里的配置。如果是ECONNREFUSED，说明MySQL没监听或者监听地址不对，检查/etc/mysql/my.cnf里的bind-address配置，确保是127.0.0.1，重启MySQL服务即可。

另外还有一个小坑：宝塔面板创建的数据库账号，默认权限可能只覆盖某一个数据库，但如果在代码里连接时指定了错误的目标库，同样会报无法连接。在宝塔的数据库页面里仔细核对账号绑定的数据库名，“未来树洞”用的是future_treehole，别写错成future-treehole这类带横杠的变体。

6.4 前端刷新子页面404，history路由没接住

部署后有一个很典型的问题：用户在“未来树洞”站内点击跳转一切正常，但手动刷新一个二级页面（比如直接输入某个树洞详情的URL地址）就出现404。原因就是Nginx没有配置try_files，刷新时Nginx尝试在磁盘上查找这个路径对应的文件，找不到就返回404。

解决方法是把location /配置改成带try_files的版本：

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

这段配置的意思是：先尝试按原路径找文件，找不到就返回/index.html，由前端路由接管。这是Vue Router或React Router使用history模式部署时必配的一项，一次配置，永久解决问题。

6.5 部署上线后服务器内存告急

“未来树洞”上线初期一切正常，运行一段时间后，有次登录宝塔面板发现内存占用一直在90%以上。排查下来有两个原因：一是PM2默认会记录大量日志，日志文件不断膨胀占满了内存和磁盘；二是Node.js进程发生了某种内存泄漏（常见于长连接或定时器未清理）。

处理办法是，先配置PM2的日志定期轮转：

pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M pm2 set pm2-logrotate:retain 7 pm2 set pm2-logrotate:compress true

这样单个日志超过10M就会自动切割并保留最近7份。至于内存泄漏，我给“未来树洞”加了一个每小时的定时重启兜底策略——对于个人项目这个体量，每天定时重启一次进程是完全可以接受的，能有效避免内存缓慢增长带来的崩溃风险。大项目当然要想办法根治泄漏，个人项目用重启兜底属于性价比最高的方案。

7. 个人实测体会与后续扩展建议

“未来树洞”从本地开发到正式上线，整个过程让我最大的感受是：部署本身不难，但前置的规划和排查问题的能力才是关键。提前想清楚技术栈、摸清后端依赖、配置好数据库账号密码，再按照“环境—数据库—后端—前端—域名—HTTPS”的顺序往下走，成功率非常高。反过来，如果一上来就先装宝塔，然后边传代码边想怎么配，大概率会陷入“日志看得云里雾里、配置改来改去”的泥潭。

一个我在实操中很受用的习惯是：每完成一个环节就验证一个环节。装完数据库先本地连一下，确认密码和权限没问题；后端部署完先curl测一下接口，确认能返回JSON；前端部署完先看首页，再测API链路。每一步都验证通过再进入下一步，整个部署过程几乎不会出现需要回头排查半小时的情况。

后续我会给“未来树洞”继续做几件事：接入WebSocket做实时消息通知；给树洞内容增加图片上传（阿里云OSS做存储，避免占用服务器磁盘）；再引入简单的关键词过滤，在内容审核层面做一层自动拦截。这些功能上线后，部署侧主要是做好磁盘监控和数据库备份，其他不用做太大的调整。你的项目部署上线后，也可以顺着这个思路继续迭代——先把线上跑稳，再把功能做好，这是一条低成本、高确定性的个人项目演进路线。