云服务器Ubuntu的SWAP挂载后重启就没了，怎么配才能一直生效
云上常见的怪事：新开的 Ubuntu 虚拟机 free -h 一看，Swap 一栏是 0；照教程建交换文件、mkswap、swapon，当时明明生效，重启完又回到 0。业务一旦吃内存，进程被内核杀掉，日志里一行 out of memory——昨天配过的东西，怎么说没就没。
原因分析
两头原因叠在一起。其一，云厂商镜像默认不做交换分区：云主机按套餐卖内存，厂商希望内存不够就升配，而不是靠换页把负载甩给共享的宿主机磁盘，出厂为零是设计而非缺陷。其二，手动 swapon 只是让内核“现在开始用这块空间“，没有告诉系统“下次开机也用“——开机挂载归 /etc/fstab 管，漏了这步重启自然清零。更隐蔽的是第三层：云平台的开机代理会按自己的配置重置磁盘状态。Azure 的 Linux 装着 waagent，开机按 /etc/waagent.conf 处理资源盘与交换文件，EnableSwap 与 SwapSizeMB 的组合等于每次开机替你重新安排一遍；再叠一层 cloud-init 的 disk_setup 每启动重写分区挂载。fstab 写了也消失的，多半是这两位在开机瞬间改了回去。
分步解决
- 先看清现场。free -h、swapon –show、cat /proc/swaps 三条命令把当前交换设备列清楚；再看 /etc/fstab 有没有 swap 那行，是缺行还是被覆盖，处理路线完全不同。
- 建交换文件。系统盘上 fallocate -l 2G /swapfile（个别文件系统不支持就退回 dd 慢路线），chmod 600 收紧权限，mkswap 打标记，swapon 挂上——free -h 此刻已能看到它。
- 写进 /etc/fstab。追加一行 /swapfile none swap sw 0 0，这是通用持久层；写完先 swapoff 再 swapon 走一遍，语法错误当场暴露，别留到重启才发现。
- 管住云代理的开机重配。Azure 机器改 /etc/waagent.conf：不想让代理碰交换就把 ResourceDisk.EnableSwap 置 n；也可以把 SwapSizeMB 设成目标值，交换整体交给代理托管——二选一，别两头都开。装 cloud-init 的再查 /etc/cloud/cloud.cfg，把每启动执行的 disk_setup 固化成每实例一次。
- 重启验收。reboot 后 free -h 确认 Swap 仍在；顺手把 vm.swappiness 调到 10 到 20 一档，数据库类业务少换出更稳。没做过“重启后仍在“验证的交换配置，一律当没配。
预防
上云初始化清单里固定加一节”重启验证”：交换空间、数据盘挂载、业务自启动三件套，交机前重启一轮全过再交付。云上”当时配好了”和”重启后还在”是两件事，把这层差别写进交付文档，接手的人就不会在同一条沟里反复跌倒。