web部署

凌晨两点，我盯着终端里那行红色的报错，咖啡杯沿结了一层干涸的奶渍。第三次了，同一个配置文件，在本地跑得欢快，一上服务器就翻脸。后来才明白，问题出在路径分隔符——Windows用反斜杠，Linux用正斜杠，就这一个小差异，能让你从黄昏折腾到天亮。

部署这件事，本质上就是把你电脑上的代码，搬到另一台永远开机的机器上，让它替用户服务。听起来简单，做起来全是坑。我见过最惨烈的案例，是有人用FTP手动上传文件，漏了一个文件夹，结果整个网站白屏——用户看到的是404，他看到的是一整夜的加班。

现在主流的玩法，大概分三种。第一种是传统的一键安装包，像宝塔面板那种，鼠标点几下，Nginx、MySQL、PHP全给你装好。适合小项目，或者你只想快速验证个想法。缺点也明显，环境是别人打包的，出问题你得猜它内部怎么配的。

第二种是容器化部署，Docker是代表。你把应用和它的依赖全塞进一个镜像里，扔到哪都能跑。我有个朋友，把公司老旧的PHP项目容器化之后，从三台服务器缩到一台，成本直接砍半。但镜像也不是万能的，你得处理数据卷、网络模式，搞不好容器一重启，数据全没了——那种感觉，比失恋还难受。

第三种是云厂商的托管服务，像AWS的Elastic Beanstalk或者Vercel。你只管推代码，平台自动帮你构建、扩容、灰度发布。省心是真省心，但价格也真不便宜。我见过一个小团队，月流水不到十万，光云服务费就烧掉两万，老板看着账单脸都绿了。

说到底，选哪种部署方式，得看你的项目阶段。个人博客用FTP传都行，反正挂了也不心疼。但你要是做电商，哪怕只是个小店，也得考虑自动化部署——至少弄个Git钩子，push完自动拉代码、跑测试、重启服务。手动操作次数越多，出错概率越大，这是铁律。

还有那些细节，容易被忽略却要命。比如环境变量，数据库密码别硬编码在代码里，用环境变量注入。我见过有人把AWS密钥传上GitHub，半小时内就被机器人扫到，然后你账户里多了几百刀的挖矿账单。再比如日志，别只print到控制台，部署环境里你得有日志文件，最好能轮转切割，不然硬盘满了，整个服务静默崩溃。

去年我帮一个客户迁移服务器，老机器上跑着五年前的代码，连PHP版本都还是5.6。他们不敢动，怕炸。我硬着头皮在测试环境模拟了一遍，改了几处废弃函数，加了个自动部署脚本，最后切流量那天，全程无感。客户问，这就完了？我说，完了。他愣了半天，说以前每次升级都要停机两小时。

部署的终极目标其实就一句话：让发布变成一件无趣的事。无趣意味着稳定，意味着你不需要在深夜盯着进度条祈祷。我现在的习惯是，每次部署前写个checklist——备份数据库、确认配置文件、跑一遍冒烟测试。哪怕再急，这四步不能省。省一步，后面可能要多花十步来补救。

对了，别忘了监控。部署完不是结束，是开始。至少配个简单的健康检查，每五分钟请求一次首页，返回200就说明活着。有次我部署完就去吃饭了，回来发现服务早挂了，磁盘被日志塞满。要是早点有告警，那顿火锅能吃得安心些。

做这行越久，越觉得部署不是技术活，是责任心活。代码写得再漂亮，部署环节掉了链子，用户只看得到打不开的页面。反过来，部署做得干净利落，哪怕代码偶尔有点小瑕疵，你也有余裕去修。先让系统跑起来，再谈优化，这个顺序永远别搞反。