EP231. “自动更新几乎是安全防线的全部”

课程收尾的「挑战」系列第一讲：不是编程练习，而是关于网站长期维护的方法论。核心论点——保持 WordPress 更新是安全防护里 99% 的工作，WordPress 本身并不是一个容易被黑的软件，前提是持续保持更新；一旦线上网站落后于最新版本,几乎可以确定「不是会不会被黑,而是什么时候被黑」。给出两套更新策略（方案 A：开启自动更新；方案 B：手动管理更新）的风险对比,并说明这个选择会如何影响 Git 仓库该纳入哪些文件。

涉及文件

本讲是纯方法论/运维策略介绍，不涉及具体代码改动。

核心概念

• 核心论点：保持 WordPress 更新几乎等于做好了安全防护的全部工作——WordPress 之所以有时被认为「不安全」，绝大多数真实案例的根本原因是网站本身版本过旧，而不是 WordPress 软件本身有漏洞；作者从业约 12 年,唯一几次网站被黑的经历都是自己疏于更新导致的
• 为什么 WordPress 更容易成为攻击目标：它是完全开源的软件，且驱动着全网约 28% 的网站——这意味着 7×24 小时都有人在研究它的源码（有些是为了改进安全性，有些则是为了找漏洞）；对黑客而言，找到一个 WordPress 的安全漏洞，等于找到了一扇能通向近三分之一互联网的后门
• 更新方案 A（作者推荐，适合 99% 的项目）：线上正式环境保持自动更新开启——WordPress 默认只会自动应用「小版本」更新（安全补丁等），大版本更新需要在后台手动点击；如果愿意承担一点风险，也可以通过官方文档给出的代码,把大版本更新也设成自动
• 更新方案 B（不推荐，仅适合特殊场景）：关闭自动更新，每次官方发布更新后先在本地开发环境测试、确认不会破坏任何功能,再手动推送到线上——只有当项目预算充足、且有专人能在官方发布安全更新的同一天就完成「本地测试 → 确认无恙 → 推送上线」这一整套流程时,才适合选择这条路；没有这种人力配置的话，网站哪怕只是「过期一天到一周」，被黑的概率就会大幅上升
• 两种方案的风险对比（作者的估算，非精确数据）：开启自动更新，「某次更新意外破坏某个功能」的风险大概是 1%~10%；关闭自动更新且疏于人工跟进，「网站被黑」的风险则接近 99%~100%——两权相害取其轻,作者认为宁愿承受「网站偶尔因为更新出点小问题」,也不愿承受「网站被黑、被植入广告软件/恶意程序,进而损害品牌形象」这种量级的后果
• 更新策略会反过来影响 Git 仓库该纳入哪些内容：
  • 如果选方案 A（线上自动更新），Git 仓库里通常只需要纳入主题文件夹（wp-content/themes/你的主题）——wp-admin、wp-includes 这些 WordPress 系统文件既然交给服务器自动维护，没必要也放进版本控制
  • 也可以选择把整个 WordPress 安装都纳入 Git，但配置部署工具时只推送/排除特定文件夹（比如排除 wp-admin/wp-includes，因为这些交给服务器自动维护）
  • 没有绝对「对」或「错」的做法，关键是让 Git 仓库结构和部署工具的行为跟自己选择的更新策略保持一致，不要出现「明明开着自动更新，却又把系统文件纳入版本控制、部署时把旧版本覆盖回去」这种自相矛盾的配置

常见坑

• 出于「怕更新弄坏某个功能」的顾虑而关闭自动更新，却没有配备能每天跟进补丁的人力——这种情况下被黑的风险远大于「更新偶尔弄坏点东西」的风险
• Git 仓库结构和实际采用的更新策略不匹配——比如线上开着自动更新，但部署流程又会把 Git 里存的旧版系统文件覆盖回服务器，导致更新形同虚设

[截图：wp-admin 后台"更新"页面，显示核心/插件/主题的自动更新开关状态和当前版本号]

延伸 / 后续讲座会用到

下一讲的挑战是关于「自定义 query var」，跟这一讲的运维话题是完全独立的两个主题。

Sources

Udemy：

• Become a WordPress Developer: Unlocking Power With Code — Section 31, EP231