作为有5年前端开发经验的程序员，去年跟风转全栈时踩了个致命坑——花3个月开发的客户管理系统刚上线，就被异常请求搞崩了。后台日志刷满了“数据库连接池耗尽”的报错，用户反馈订单加载不出来，领导盯着我24小时内解决。试了3种方案后，最终靠一款轻量WAF逆袭，不仅拦住了恶意请求，还让系统扛住了3倍流量高峰。今天把从崩溃到稳定的全过程复盘，给前端转全栈的同行避坑。
一、全栈新手的致命盲区：只懂业务代码，忽略服务防护
我用SpringBoot+Vue开发完系统后，直接把jar包扔到阿里云1核2G服务器上，配了Nginx反向代理就上线了。当时觉得“内部系统访问量小，防护没必要”，结果上线第3天就出问题：
- 中午12点突然收到告警：服务器CPU飙升到98%，内存占用100%，系统直接卡死；
- 翻Nginx日志发现，10分钟内有2000+次异常请求，全是带“../config/db”的路径遍历和“or 1=1”的SQL注入；
- 紧急重启服务后，不到半小时又被攻崩，客户那边已经开始投诉。
更尴尬的是，我作为前端转全栈的新手，只会改业务代码，面对这种攻击完全手足无措。找运维同事求助，他甩了句“你这连基础防护都没做，不崩才怪”，给了我3个方向：改代码加校验、装商业WAF、用开源防护工具。
二、3种方案试错：新手该避开的坑
1. 方案一：代码层加校验（失败）
我先试着在Controller层加参数校验，用正则匹配SQL注入关键词，花了4小时改了20多个接口。结果上线后还是被攻崩——攻击者把参数做了Base64编码，正则根本识别不出来。而且每个接口都加校验，后续迭代太麻烦，果断放弃。
2. 方案二：商业WAF（放弃）
咨询了某云厂商的商业WAF，基础版每年要8000多，而且需要配置负载均衡、改DNS解析，对我这个全栈新手来说操作太复杂，预算也超了，只能pass。
3. 方案三：开源WAF（成功）
运维同事推荐了雷池社区版，说它“部署简单、不用改代码、免费”。抱着死马当活马医的心态试了下，没想到30分钟就部署完成，而且真的解决了问题。
三、新手也能上手的WAF部署全流程（附避坑指南）
我的服务器是CentOS 7.9+Nginx 1.22，全程不用改业务代码，复制命令就行，前端转全栈的新手跟着做绝对没问题。
1. 前置准备：确认端口和权限
先检查80/443端口没被其他程序占用（Nginx占用没问题），执行命令：
# 查看端口占用
netstat -tuln | grep -E "80|443"
# 确保有root权限，没有就加sudo
sudo -i
2. 3步部署WAF，全程复制命令
# 1. 安装Docker（已装的跳过，5分钟完成）
curl -fsSL https://get.docker.com | bash -s docker --mirror Aliyun
# 2. 启动Docker并设置开机自启
systemctl start docker && systemctl enable docker
# 3. 一键部署雷池，自动适配Nginx
docker run -d --name leichi -p 80:80 -p 443:443 -v /etc/leichi:/etc/leichi --restart=always leichi/waf:community
部署完成后，执行docker ps，看到“leichi”状态是“Up X seconds”就成功了。再执行docker logs leichi | grep "初始密码"，把密码记下来，后面登录要用。
3. 关联系统：3分钟让防护生效
- 打开浏览器，输入服务器公网IP，用账号“admin”和刚才的初始密码登录，第一次登录改个复杂密码；
- 点击左侧“网站管理→添加网站”，填3个关键信息（不用懂原理，照着填）： 网站域名：系统的域名（没有就填服务器公网IP）
4. 后端地址：服务器内网IP（执行
ip addr能看到，比如172.16.0.5）；
- 后端端口：Nginx的端口（默认80）。
- 点击“保存”，30秒后防护生效，不用重启Nginx和业务服务！
4. 新手避坑：端口冲突怎么办？
如果部署时提示“端口被占用”，大概率是Nginx占了80端口，执行下面命令先停Nginx，部署完再重启：
systemctl stop nginx
# 部署WAF的命令（上面第3步的命令）
docker run -d --name leichi ...
# 重启Nginx
systemctl start nginx
四、逆袭效果：从崩溃到稳抗高并发
部署后我做了3个测试，结果远超预期：
1. 攻击拦截：异常请求全挡住
用之前攻崩系统的Payload测试，比如访问“http://域名/?id=1' or 1=1 --”，直接显示“请求被拦截”。后台日志显示，拦截率100%，再也没出现数据库连接池耗尽的情况。
2. 性能影响：几乎无感
最担心的“拖慢系统”没发生：CPU占用从之前的98%降到35%，内存占用380MB，客户管理系统的响应时间从500ms变回180ms，比之前还快！
3. 高并发测试：扛住3倍流量
用JMeter模拟3倍日常流量（之前崩掉的流量），系统稳定运行，Nginx连接数控制在安全范围，没有出现一次请求超时。
五、前端转全栈的防护启示：别等崩了再补救
现在系统已经稳定运行6个月，经历了3次月底结账的流量高峰，累计拦截1500+次高风险请求，再也没出过错。作为前端转全栈的过来人，我总结了3个血的教训：
- 全栈不只是“前端+后端代码”，服务防护是底线，上线前一定要做；
- 新手别硬刚代码层防护，选对工具比自己瞎改代码高效10倍；
- 免费工具不代表不靠谱，像雷池这种适配性强的开源WAF，完全能满足中小项目需求。
如果你的前端转全栈之路也遇到了服务安全问题，不妨试试这个方案，30分钟部署换长期安心，比熬夜改代码香多了。
标签：#前端转全栈 #服务防护 #WAF实战 #全栈踩坑记
