从零到一：记一次Vue+Flask项目在内网PC的部署历险记

引言

最近在公司内网环境部署了一个基于 Vue + Flask + MySQL 的Web应用，本以为只是简单的“代码打包→复制→运行”，结果却遭遇了连环坑。本文将复盘整个部署过程，总结遇到的问题、解决方案，并最终探索出更成熟的部署方式。

标题：

《从单机开发到内网共享：一个Vue+Flask+mysql项目的部署踩坑与进阶实践》

一、初版部署：天真的“源码大挪移”

1. 操作步骤

将本地开发好的源码打包（Vue前端 + Flask后端 + 数据库脚本）。
复制到一台闲置的公司PC，安装Python、Node.js、MySQL。
运行 npm run build 和 python app.py，满心期待同事通过IP访问。

2. 遇到的问题

（1）同事无法访问服务

现象：浏览器输入 http://<我的IP>:5000 返回超时。
原因：
- Windows防火墙默认阻止外部访问5000端口。
- Flask开发服务器仅监听 127.0.0.1。
解决：
1
2
# 修改Flask启动配置
app.run(host='0.0.0.0', port=5000) # 允许局域网访问
并手动在防火墙中放行5000端口（控制面板→防火墙→高级设置→入站规则）。

（2）前端资源加载失败

现象：页面能打开，但API请求全部报错，登录功能失效。
原因：
- 前端代码中API地址硬编码为 http://localhost:5000，导致同事的浏览器向自己的本地发送请求。
解决：
动态配置API地址（以Vue为例）：
1
2
# .env.production
VUE_APP_API_URL=http://<我的IP>:5000
重新构建前端：
1
npm run build

二、暴露的问题与知识盲区

1. 开发环境≠生产环境

Flask自带的服务器（app.run()）是单线程调试工具，性能差且不稳定。
直接暴露后端端口（如5000）存在安全隐患。

2. 配置硬编码的代价

前端API地址、数据库连接信息写死在代码中，切换环境需重新构建。

3. 缺乏服务高可用保障

我的PC一旦关机，所有同事无法访问服务。

三、进阶方案：走向成熟部署

1. 使用Nginx反向代理

作用：
- 统一入口（80端口），隐藏后端服务。
- 高效托管前端静态文件。

配置示例：

server {
    listen 80;
    server_name localhost;

    # 托管Vue静态文件
    location / {
        root /path/to/vue/dist;
        index index.html;
    }

    # 转发API请求到Flask
    location /api {
        proxy_pass http://127.0.0.1:5000;
    }
}

2. 用Gunicorn替代Flask开发服务器

启动多进程生产级服务：

1 2	pip install gunicorn gunicorn -w 4 -b 0.0.0.0:5000 app:app

3. 自动化与进程守护

Linux：通过systemd管理服务（开机自启）。
Windows：用NSSM将Nginx/Gunicorn注册为服务。

四、最终效果

访问方式：同事只需输入 http://<我的PC IP>，无需关心端口。
性能提升：Nginx静态文件缓存 + Gunicorn多进程，并发能力显著提高。
维护便利：代码更新只需 git pull 和重新构建前端。

五、经验总结

永远不要直接使用开发服务器上线。。。。。。
环境配置动态化（环境变量 > 硬编码）。
反向代理是内网部署的黄金搭档（Nginx/YARP）。
基础设施分离（数据库、前端、后端独立部署）。

结语

这次部署经历让我深刻理解了“开发”与“运维”的鸿沟。下一次，我会直接上Docker + Kubernetes（笑）。如果你也在内网部署过项目，欢迎分享你的踩坑故事！

（完）

后续计划

尝试用Docker容器化部署。
研究内网HTTPS证书配置。
探索CI/CD自动化发布流程。