这次我把阿里云新加坡上的 WordPress 服务器从 Debian 11（bullseye）升级到 Debian 12（bookworm）。配置不高（1C/1GB RAM/2GB Swap/40GB），所以思路很简单：尽量少折腾、尽量可回滚、尽量用可复制粘贴的命令。下面是完整过程、遇到的坑，以及升级后如何把多出来的空间清掉。
一、升级前我做了哪些准备
升级系统最怕两件事：
- 源没改干净/混了第三方源，升级中途依赖炸裂
- 升完服务起不来（nginx/php-fpm/mysql）
我先做了三件事确认系统状态：
1）确认当前版本
cat /etc/debian_version
uname -r
当时显示 11.11，内核还是 Debian 11 的 5.10。
2）确认没有 hold 包（避免升级被锁）
apt-mark showhold
没有输出，说明没有 hold。
3）确认 APT 源文件到底在哪
一开始我用 grep 扫 /etc/apt/sources.list.d/*.list 没扫到任何东西，后来才发现：我的源非常干净，只有 /etc/apt/sources.list 里 3 行官方源，没有 .sources、没有第三方 .list。
直接看内容最靠谱：
ls -l /etc/apt/sources.list
sed -n '1,200p' /etc/apt/sources.list
当时是典型的 bullseye 三行：
deb http://deb.debian.org/debian bullseye ...deb http://deb.debian.org/debian bullseye-updates ...deb http://security.debian.org/debian-security bullseye-security ...
二、正式升级：bullseye → bookworm（全程不需要编辑器）
1）先把 Debian 11 更新到最新
apt update
apt -y full-upgrade
apt -y autoremove --purge
reboot
2）备份 sources.list（留后路）
cp -a /etc/apt/sources.list /etc/apt/sources.list.bak.$(date +%F)
3）把 bullseye 替换为 bookworm
sed -i 's/bullseye/bookworm/g' /etc/apt/sources.list
cat /etc/apt/sources.list
4）两段式升级（更稳）
apt update
apt -y upgrade
apt -y full-upgrade
apt -y autoremove --purge
apt -y autoclean
reboot
三、升级后怎么验证“已经是最新版”
我用的是三层验证法：系统版本、核心包一致性、无可升级包。
1）系统版本确认
cat /etc/os-release
cat /etc/debian_version
这次结果是：
Debian GNU/Linux 12 (bookworm)/etc/debian_version显示12.13
2）关键基础包是否“已安装 = 仓库候选”
apt-cache policy base-files | sed -n '1,20p'
我这里 Installed 和 Candidate 一致，说明当前就是仓库提供的最新版本。
3）是否还有可升级内容（最直观）
apt update
apt -s full-upgrade
输出 0 upgraded, 0 newly installed...，这就很干脆：已经到顶。
4）内核是否已切到 Debian 12 默认 6.1 线
uname -r
dpkg -l | grep -E '^ii\s+linux-image-amd64|^ii\s+linux-image-6\.1'
我升级后跑的是 6.1.0-43-amd64，并且 linux-image-amd64 元包也在，后续内核更新就能跟着走。
四、升级过程里遇到的两个“小坑”
坑 1：apt 提示 non-free 组件变化
升级后 apt update 会出现类似提示：
bookworm 把 non-free 拆成了
non-free与non-free-firmware
这不是错误，只是提醒 sources 的组件写法旧了。云服务器一般不靠额外固件包，不处理也能用；想“规范 + 消提示”可以这样改（按需）：
sed -i 's/ main contrib non-free$/ main contrib non-free non-free-firmware/' /etc/apt/sources.list
apt update
坑 2：systemctl 查服务显示 “Unit nginx.service could not be found”
我用的是 AMH/LNMP 这套环境，nginx/php-fpm/mysql 是装在 /usr/local/... 下跑的，不是 Debian 的 systemd unit 标准服务名，所以会出现：
Unit nginx.service could not be found.Unit mysql.service could not be found.
这不代表服务没跑，只代表“你不能用 Debian 默认 unit 名称去查”。
更靠谱的检查方式是看进程：
ps aux | egrep 'nginx:|php-fpm|mysqld' | grep -v egrep
五、升级后硬盘占用多了接近 1GB：怎么清理
升级完成后我发现磁盘多占了将近 1GB，这种情况十有八九是旧内核包没清。
我当时系统里同时存在：
- Debian 11 的
linux-image-5.10.0-38-*和 headers - Debian 12 的
linux-image-6.1.0-43-*和 headers
先确认我当前正在跑 6.1（避免误删正在使用的内核）：
uname -r
然后列出内核包：
dpkg -l | grep -E 'linux-image-|linux-headers-' | awk '{print $2,$3}'
确认 5.10 那套还在后，直接 purge 掉旧内核（只删 5.10，不动 6.1）：
apt -y purge linux-image-5.10.0-38-amd64 \
linux-headers-5.10.0-38-amd64 \
linux-headers-5.10.0-38-common
update-grub
apt -y autoremove --purge
apt -y clean
删完再看一次内核列表，确保只剩 6.1：
dpkg -l | grep -E 'linux-image-|linux-headers-' | awk '{print $2,$3}'
这一步通常就是“那 1GB 的主要来源”。
六、顺带记录：面板里的 PHP 扩展怎么取舍（WordPress 场景）
我当时也顺手看了下 PHP 扩展（面板里勾选那种）。对 WordPress 来说，我的倾向是：最小集合 + 按需添加。
建议保留：
fileinfo（常用）mysqli+mysqlnd（WP 默认）opcache（强烈建议）sodium（现代加密）exif（图片方向/元信息）imagick（图像处理能力强，有则留）
一般不建议默认开启：
xmlrpc（能不用就不用，常被扫）ffi、swoole、pcntl、sockets（非 WordPress 常规需求）pdo_mysql（WP 本体一般不用，除非插件明确要求）redis/memcached这类缓存扩展（你没跑对应服务、没用对象缓存插件时开了也没意义）
七、升级后这台 1GB 小机器的实际状态
升级到 Debian 12 后我看了下内存：
- 总内存约 899MB（云厂商常见）
- swap 已使用约 180MB 左右
这种状态不算崩，但说明机器在某些时刻被顶过。最常见的内存大户就是 MySQL，其次是 php-fpm 并发设置过大。
对 1GB 机器来说，我更愿意牺牲一点并发峰值，换稳定性：把 php-fpm worker 上限收紧，把 MySQL buffer pool 控制住，swap 不持续上涨就是胜利。
结语
这次从 Debian 11 升到 12 的体验整体很顺：源干净、没 hold、按标准流程升级基本不会翻车。真正“看起来麻烦”的反而是升级后的小尾巴：非 systemd 安装的服务怎么检查、non-free 的提示要不要处理、旧内核清理掉回收空间。这些处理完，系统就稳了。
