分类： 互联网应用

VPS 磁盘占用莫名上涨？我是这样把 Debian 11 的 journal 日志限制住的

最近排查一台新加坡节点的小 VPS，发现硬盘占用总是在慢慢往上爬。WordPress 文章、媒体库、MySQL binlog 都排除之后，最后锁定了一个很容易被忽视的来源：systemd 的 journal 日志。

这类日志不是博客内容，也不是 AMH 面板自己的日志，而是 Debian 系统层的运行日志。像 SSH 登录尝试、定时任务、服务状态变化，都会被写进去。如果服务器挂在公网，日志增长速度往往比想象中快。

我这台机器一开始查到的结果是：

journalctl --disk-usage

输出显示：

Archived and active journals take up 440.0M in the file system.

对于一台 40G 硬盘的小 VPS 来说，440M 已经没必要了。解决思路也不复杂：给 journald 设置上限，再把旧日志压缩回收。

journal 是什么

先简单说一句，避免混淆。

  • amh-access.log、nginx access.log 这类，是面板或网站自己的日志
  • journal 是 Debian 系统自己的总日志池，由 systemd-journald 管理

它通常会记录这些内容：

  • SSH 登录和爆破尝试
  • CRON 定时任务
  • 服务启动、重启、报错
  • 内核和系统消息

所以你在 auth.log 里看到一堆 Invalid user admin、Invalid user ubuntu 的同时，journal 里通常也会同步增长。

修改 journald 限制大小

直接编辑配置文件：

nano /etc/systemd/journald.conf

在 [Journal] 下面加入这几行：

[Journal]
SystemMaxUse=80M
RuntimeMaxUse=30M
SystemMaxFileSize=20M
MaxRetentionSec=7day

这几个参数的意思很直白：

  • SystemMaxUse=80M：磁盘上的 journal 总占用尽量控制在 80M 左右
  • RuntimeMaxUse=30M：运行时日志占用控制在 30M
  • SystemMaxFileSize=20M：单个日志文件不要太大
  • MaxRetentionSec=7day：最多保留 7 天

这套数值对小内存、小硬盘的 VPS 比较合适。不是绝对标准，但足够实用。

让配置生效

保存后执行：

systemctl restart systemd-journald

然后把旧日志清理到目标范围：

journalctl --vacuum-size=80M

如果想更激进一点，也可以改成：

journalctl --vacuum-size=50M

检查结果

执行：

journalctl --disk-usage

我这台机器处理完后的结果是：

Archived and active journals take up 96.0M in the file system.

虽然不是精确等于 80M，但这是正常现象。SystemMaxUse 更像一个控制目标，不是硬切到一字不差。只要从几百 MB 降下来了，而且后续不再无限增长，目的就达到了。

再顺手确认一下配置是否写进去了：

grep -Ev '^\s*#|^\s*$' /etc/systemd/journald.conf

如果输出类似下面这样，就说明已经生效：

[Journal]
SystemMaxUse=80M
RuntimeMaxUse=30M
SystemMaxFileSize=20M
MaxRetentionSec=7day

这一步能解决什么问题

限制 journal 后，至少能解决两件事：

第一，系统日志不再无上限吃盘。

第二，后面再排查磁盘占用时，能把注意力放回真正异常的目录，而不是一直被系统日志干扰。

不过也要说清楚：限制 journal 只是收口，不是治本。

如果你的服务器像我这台一样，公网不断有人扫 SSH 端口，那 auth.log 和 journal 还是会继续写，只是不会再失控。所以更彻底的做法，通常还包括：

  • 修改 SSH 默认端口
  • 禁止密码登录
  • 只允许密钥登录
  • 安装 fail2ban

最后

如果你也在用 Debian 11 或类似的 systemd 系统，发现 VPS 磁盘占用总是缓慢上涨，先别急着怀疑网站内容或者数据库。

先看一眼：

journalctl --disk-usage

很多时候，问题就藏在这里。

Debian 11 升级到 Debian 12（bookworm）实录：一步步升级、验证版本、踩坑记录与清理空间

这次我把阿里云新加坡上的 WordPress 服务器从 Debian 11（bullseye）升级到 Debian 12（bookworm）。配置不高（1C/1GB RAM/2GB Swap/40GB），所以思路很简单：尽量少折腾、尽量可回滚、尽量用可复制粘贴的命令。下面是完整过程、遇到的坑，以及升级后如何把多出来的空间清掉。

一、升级前我做了哪些准备

升级系统最怕两件事：

  1. 源没改干净/混了第三方源，升级中途依赖炸裂
  2. 升完服务起不来（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 的提示要不要处理、旧内核清理掉回收空间。这些处理完，系统就稳了。


AMH 面板下给小内存 VPS 调 MySQL的配置改法

我这台小 VPS（1 核 1G 左右内存）跑 WordPress，用的是 AMH 面板 + LNMP，数据库是 mysql-generic-8.0。这种配置最大的矛盾很现实：MySQL、PHP-FPM、Redis、Nginx 都要活着，但内存就那么一点点，稍微一波访问就容易 swap、卡顿，甚至 PHP-FPM 一个进程飙 CPU/内存把机器拖死。

所以我给 MySQL 的策略不是“性能拉满”，而是：

  • 稳：不爆内存，不轻易触发 swap 抖动
  • 够用：满足 WordPress 常见读写
  • 可控：参数简单，能在 AMH 里直接粘贴，不用手改一堆

下面记录我这次在 AMH 面板 → MySQL → 参数配置/编辑配置 里调整 MySQL 的过程、思路和最终配置。

1）先说结论：WordPress 场景下，MySQL 8 应该以 InnoDB 为核心

我当时在 AMH 的“中等配置”里看到一行：

default-storage-engine = MyISAM

这在 MySQL 8 + WordPress 上不太合理：

  • WordPress 核心表基本都用 InnoDB（事务、崩溃恢复、行级锁）更合适
  • MyISAM 在并发写入、锁竞争、崩溃恢复方面都不友好
  • MySQL 8 默认其实就是 InnoDB

我也用命令确认过运行时变量（当时查询结果里已经是 InnoDB）：

  • default_storage_engine = InnoDB

所以配置层面我也把它写成 InnoDB，避免“配置写 MyISAM、实际跑 InnoDB”这种割裂状态。

2）我关心的几个关键参数：小内存下要盯住这几项

在 1G 内存的机器上，我重点看的就是：

（1）innodb_buffer_pool_size（核心）

这是 MySQL 内存大头。太大了会挤死 PHP-FPM；太小了数据库命中率差但至少不死。

我的原则：给 InnoDB 128M～256M 这个级别，优先保证系统整体稳定。

（2）max_connections（别给太大）

WordPress 的连接通常来自 PHP-FPM。你机器 1 核 + 1G，开 200 连接只会把自己拖死。

我的原则：30～60 足够，必要时再加。

（3）table_open_cache（适中即可）

过小会频繁 open/close 表；过大又浪费内存。

我的原则：128 或 256。

（4）max_allowed_packet（别搞得太极端）

太小会导致导入/插件操作失败；太大意义也不大。

我的原则：32M（比默认 16M 更稳妥一些）。

3）AMH 面板里怎么改：直接替换“编辑配置”内容

AMH 的好处是它提供了一个“编辑配置”文本框，你可以直接把整段 my.cnf 风格内容粘进去。

我不想一条条点下拉框，所以就用“整段替换”的方式，一次到位。

下面这份就是我给 小内存 WordPress 服务器准备的版本（你可直接复制粘贴到 AMH 的编辑配置里）。

4）最终配置（可直接复制）

说明：按你面板里 mysql-generic-8.0 的路径/命名习惯写的，保持 socket、datadir、pid-file 这些 AMH 自己的字段不动，只把关键性能参数调整到更“稳”的区间。

[client]
port = 3306
socket = /tmp/mysql-generic-8.0.sock

[mysqld]
# 基础路径（保持 AMH 原配置）
port = 3306
socket = /tmp/mysql-generic-8.0.sock
lc-messages-dir = /usr/local/mysql-generic-8.0/share
basedir = /usr/local/mysql-generic-8.0
datadir = /home/usrdata/mysql-generic-8.0
pid-file = /home/usrdata/mysql-generic-8.0/mysql.pid

# 安全/兼容
skip-external-locking
skip-networking
sql_mode='NO_ENGINE_SUBSTITUTION'
default_authentication_plugin = caching_sha2_password
disable_log_bin

# ✅ 关键：WordPress 建议用 InnoDB
default-storage-engine = InnoDB

# 连接与缓存（小内存稳一点）
max_connections = 30
table_open_cache = 128

# 传输包（避免某些导入/插件操作失败）
max_allowed_packet = 32M

# InnoDB 内存（1G 机器建议 128M～256M；先用 128M 更稳）
innodb_buffer_pool_size = 128M
innodb_log_buffer_size = 8M
innodb_open_files = 200

# 一些连接级 buffer：别给太大（并发一上来会放大内存占用）
sort_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
net_buffer_length = 8K
thread_stack = 256K

# MyISAM 相关（基本用不到，但留小一点避免浪费）
key_buffer_size = 8M
myisam_sort_buffer_size = 8M

server-id = 1

[mysqldump]
quick

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

5）改完怎么验证：别信面板，要看运行时变量

我改完后，会用 MySQL 直接查运行时值（避免“配置写了但没生效”）：

mysql -uroot -p -S /tmp/mysql-generic-8.0.sock -e \
"SHOW VARIABLES WHERE Variable_name IN ('default_storage_engine','innodb_buffer_pool_size','max_connections','table_open_cache','max_allowed_packet');"

重点看这几项是不是你期望的：

  • default_storage_engine 是否是 InnoDB
  • innodb_buffer_pool_size 是否按你设定（例如 134217728 = 128M）
  • max_connections 是否为 30
  • table_open_cache 是否为 128
  • max_allowed_packet 是否约 33554432（32M）

6）我为什么这么配：一句话总结

1G 内存的 WordPress 机器，MySQL 的正确打开方式不是“提速”，而是“别抢资源”。
把 InnoDB 用对、把 buffer_pool 限住、把连接数收敛住，整体才稳

从 Debian 10.5 升级到 Debian 11（Bullseye）实录：不写编辑器、全程命令行、顺手清理老内核

我这台 VPS 之前跑的是 Debian 10.5（Buster），主要用来跑 WordPress（AMH 面板 + LNMP + MySQL 8 + PHP-FPM）。因为系统版本太老，很多源已经进入“历史归档”，apt update 直接 404，装个 screen 都困难。为了后续维护省心，我决定先升级到 Debian 11（Bullseye），并且尽量做到两点：

  1. 全程不进编辑器（不想 vi/nano）。
  2. 升级结束后把系统状态收拾干净：包无残缺、源正确、老内核清掉、重启后跑在新内核上。

下面就是我这次升级的完整过程记录。

1）升级前的现象：Debian10.5 的源开始 404

最直观的症状就是：

  • apt update 报 404 / Release file missing
  • screen 甚至都装不上（因为源不可用了）
  • 典型报错类似：... buster Release 404 Not Found ... no longer has a Release file

本质原因：Debian 10（Buster）进入 LTS/归档阶段后，默认源位置变化，继续用原来的 deb.debian.org / security.debian.org 组合，很容易遇到不可用或签名/Release 文件问题。

我当时的策略很简单：既然我有整机 snapshot，可以大胆升级；真出事就回滚。

2）准备工作：先把远程升级“稳住”（screen）

为了避免 SSH 掉线把升级卡死，我先装了 screen（这一步在 Debian 10 源恢复后做，或者先临时切 archive 源完成安装）：

apt update
apt install -y screen

装完后，进入一个 screen 会话再做后续操作：

screen -S dist-upgrade

3）确认目标：升级到 Debian 11（bullseye）

升级系统之前，我会先确认当前版本（避免搞错环境）：

cat /etc/debian_version
uname -a

4）切换 APT 源到 bullseye（不进编辑器的写法）

我不想用编辑器，所以直接用重定向覆盖 sources.list（你也可以把地址换成你习惯的镜像源）：

cat > /etc/apt/sources.list <<'EOF'
deb http://deb.debian.org/debian bullseye main contrib non-free
deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
EOF

然后检查一遍，确保没有混入 buster/bookworm：

grep -R --line-number -E 'deb .*debian|security.debian' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

5）正式升级：update → full-upgrade

这一步就是标准流程：

apt update
apt -y full-upgrade

升级过程中会遇到“配置文件冲突”的交互提示，比如：

  • /etc/crontab 被你或脚本修改过
  • /etc/ssh/sshd_config 有本地修改

我的处理原则是：能不动就不动（尤其是 sshd_config，远程机器最怕 SSH 配置被覆盖导致连不上）。

所以一般我会选：

  • keep your currently-installed version（保留本地版本）

如果想更谨慎，可以先选 D 看差异再决定。

6）升级过程中遇到的一个常见提示：是否自动重启服务

升级 libc 等关键库时，会弹出类似提示：

Restart services during package upgrades without asking?

我这台机器跑网站服务，升级期间重启服务是不可避免的。这里我的选择是：

  • 选 Yes（自动重启必要服务），减少后续手工确认的次数

同时它还会列出建议重启的服务（例如 ssh、cron），正常接受即可。一般 ssh 重启不会断开现有连接，但我还是建议在 screen 里操作，心里更踏实。

7）重启并确认版本：已经是 Debian 11

升级完成后，我会执行：

reboot

重启回来后，第一件事就是确认系统版本、内核版本：

cat /etc/os-release
cat /etc/debian_version
uname -r

看到类似输出就说明到位了：

  • PRETTY_NAME="Debian GNU/Linux 11 (bullseye)"
  • /etc/debian_version 显示 11.x（我这里最终是 11.11）
  • uname -r 是 5.10 系列（Debian 11 默认长期维护内核线）

8）升级后收尾：full-upgrade + autoremove 清垃圾

为了确保没有“升级半截”的包，升级后我会再跑一次：

apt update
apt -y full-upgrade
apt -y autoremove --purge

如果你想更严谨，可以加两条检查：

dpkg --audit || true
apt -f install -y

我这里的状态是：

  • All packages are up to date.
  • 0 upgraded, 0 newly installed, 0 to remove...
  • dpkg --audit 无异常

这基本就是“系统很干净”的信号。

9）清理老内核：/boot 只保留当前在跑的

升级后最常见的“硬盘变大”来源之一就是：多装了内核包（旧 kernel image 还留着）。

我先查看当前运行的内核：

uname -r

再查看系统安装了哪些内核包：

dpkg -l | awk '/^ii  linux-image/{print $2,$3}' | sort

也会看一下 /boot 里实际有哪些 vmlinuz：

ls -l /boot/vmlinuz-* 2>/dev/null

确认哪些是旧的以后，把旧内核 purge 掉（示例）：

apt -y purge linux-image-4.19.0-20-amd64
apt -y autoremove --purge

最后再确认一次：

ls -l /boot/vmlinuz-* 2>/dev/null
dpkg -l | awk '/^ii  linux-image/{print $2,$3}' | sort

我最终的状态是：

  • /boot 只剩 vmlinuz-5.10.0-38-amd64
  • linux-image-5.10.0-38-amd64 + linux-image-amd64 保留
  • 老内核已清理

10）最终结论：Debian 11 已升级完成且处于最新补丁状态

到这一步，我对“Debian 11 已升级完成”的判定标准是：

  1. cat /etc/os-release 显示 Debian 11 bullseye
  2. cat /etc/debian_version 为 11.x
  3. apt update 显示 All packages are up to date
  4. dpkg --audit 没有问题包
  5. 重启后 uname -r 跑在 5.10 内核
  6. /boot 里没有一堆遗留旧内核（已清理）

满足这些，就可以认为这台机器的 Debian 11 升级“收工”。

额外小建议（我自己的习惯）

  • 升级这种事，宁可慢点也别贪快：screen + snapshot 是最低成本的保险。
  • ssh 配置相关的提示优先保守：尽量保留本地 sshd_config，除非你完全知道差异是什么。
  • 升级后立刻做一次清理：autoremove + 清老内核，能省不少磁盘，也减少后续混乱。

我这个小博客的插件清单

1）我会坚定保留的（小站刚需）

Slim SEO

小站就该用这种“轻量自动化”的SEO插件。别折腾一堆花活，稳定产出内容更重要。

超级缓存

你服务器配置不高（1C/1G这种），缓存就是救命。首页、分类页、文章页命中缓存，CPU立刻轻松一截。

EWWW Image Optimizer

图片优化属于“长期收益”。建议开启自动压缩+WebP（如果你站点主题/缓存兼容）。图片体积下去，访问速度直接变好。

UpdraftPlus（备份/恢复）

小站最怕“折腾一次，站没了”。备份一定要有，而且要能一键恢复。

我建议：至少做到“数据库每日 + 文件每周”，备份放到异地（网盘/对象存储）。

Two Factor（两步验证）

必留。WordPress最常见风险不是你写错文章，而是后台被扫弱口令/撞库。

WP Mail SMTP

如果你要收验证码、找回密码、通知邮件，SMTP属于基础设施。保留。

2）我会优先考虑“精简/替换”的（它们可能在吃资源）

Jetpack（重点）

Jetpack是典型“功能强，但对小站可能过重”。如果你只用它的两三个功能（比如统计、CDN、加速、分享），我会建议你要么：

  • 只保留你用得到的模块（其他全部关掉），要么
  • 直接不用Jetpack，用更轻的替代方案（比如独立统计、独立加速）。

对小站来说，Jetpack最大的问题不是“好不好”，而是它会让站点复杂度上升，一出问题不好排查。

wpDiscuz（评论系统）

评论增强插件通常会带来额外JS/CSS、AJAX请求、表情/加载逻辑。

如果你博客评论量不大，我更倾向：保留原生评论 + 反垃圾 就够了。wpDiscuz可以留，但一旦你发现：

  • 后台变慢
  • 页面加载多一堆脚本
  • 评论区请求明显增多那我会果断建议你换回原生。

EmbedPress / Smartideo

这类“媒体嵌入/视频增强”插件也容易增加前端脚本。

我的建议很简单：你如果只是偶尔嵌入B站/YouTube/抖音，能用原生区块/iframe解决就别上插件；只有当你“频繁嵌入且确实省大量时间”，才值得常驻。

3）我会考虑直接关掉/删除的（小站收益不大）

List category posts

这种功能很多主题/区块/短代码都能替代，插件常驻意义不大。能不用就不用。

站长帮百度索引提交

如果你确实靠百度流量，这类插件可以留；但如果你主要靠Google或自然外链，它不是刚需。

我的偏好是：确定它真的在用、真的有效再留，否则也是“多一个变量”。

WP资源下载管理

如果你不是“资源站/频繁提供下载”，这个插件建议别常驻。下载类插件也容易引入权限/安全/盗链处理等复杂度。

4）反垃圾评论：Akismet vs 其他

Akismet

它能用、也很省心，但对中文站点有时候“误杀/漏杀”体验一般（各站差异很大）。

如果你评论不多，我的策略是：

  • 先用最简单方案（比如关闭匿名、必须登录/审核首评、限制链接数）
  • 垃圾多到受不了，再上Akismet或更适合国内的方案

一句话：别为了“可能的垃圾”提前背一个常驻插件的成本。

5）我给你的小站“插件策略”（最实用的一条）

你现在这套，我会目标控制在：常驻插件 8 个以内。

你已经具备的“底座”是：缓存 + 图片 + 备份 + 2FA + SMTP + SEO。

剩下的（Jetpack、评论增强、嵌入增强、百度提交、下载管理）都属于“可选项”，按你的内容形态决定，不要全都常驻。