EP223. “Interactivity API 是什么：填补了 WordPress 六年的空白”
🔒 登录后可标记已读新一章的开场，介绍 Interactivity API——WordPress 6.5（2024 年 4 月）新加入核心的官方标准机制，专门解决「Block 的前台（访客看到的公开页面）该怎么加交互式 JavaScript」这个问题。用一段简短的历史梳理说明它为什么重要：WordPress 从 2003 年发布到 2018 年底之间完全没有 Block 概念；2018 年底 Gutenberg/Block 正式进入核心后，编辑器那一侧的交互体验（拖拽、排列、实时预览）一直有完善的官方工具支持，但前台访客能看到的这一侧，官方始终没有提供标准做法——开发者只能各自发明一套方案（选 React 还是 Vue、怎么让前台 JS 拿到 Block 属性数据），这门课在插件/Block Theme 章节里手写的各种「PHP 编码 JSON 藏进隐藏 <pre> 标签」正是这类自创方案的代表。Interactivity API 补上了这最后一块拼图。这一章要做的练习：把 Block Theme 阶段用自定义方案实现的「Are You Paying Attention」多选题 Quiz Block，重新用官方标准的 Interactivity API 实现一遍前台交互。
📌 2026 现状：Interactivity API 从 WordPress 6.5 稳定至今核心概念没变，但 WordPress 7.0（2026 年 4 月发布）给 @wordpress/interactivity 包加了新的 watch() 函数，且底层从 effect 改成了从 @preact/signals 导出 watch——如果照着这门课（早于 7.0 录制）的写法引入旧的 effect API，在新版 WordPress 上可能会失效，跟着做的时候留意一下 @wordpress/interactivity 官方文档当前的 import 写法。
涉及文件
本讲是纯概念/历史背景介绍，不涉及代码改动。
核心概念
- 时间线：WordPress 2003 年发布 → 2018 年 12 月 6 日 Gutenberg/Block 正式进入核心（此前 15 年完全没有 Block 概念）→ 2024 年 4 月，WordPress 6.5 加入 Interactivity API
- 编辑器 vs 前台的落差：Block 诞生后的这 5、6 年里，编辑器内部的交互体验一直很成熟（拖拽排序、实时预览、丰富的组件库），但前台（访客看到的公开页面）如果想要任何客户端交互（点击、状态切换等），官方从来没有一套标准做法——选用什么框架、怎么把 PHP 端的 Block 属性数据传给前台 JS，这些决策全部要靠开发者自己想办法
- 这门课之前踩过的「自创方案」痕迹：插件开发章节的「Are You Paying Attention」Quiz Block，就是这种「没有官方标准、只能自己发明」局面下的产物——用
wp_json_encode()把属性编码藏进隐藏的<pre>标签，前台 JS 再手动JSON.parse()解析出来,这一整套手工搭桥的流程,正是 Interactivity API 想要标准化取代的东西 - Interactivity API 的定位：WordPress 官方标准化的「给前台 Block 添加客户端交互性」的机制,不需要开发者再自己决定用什么框架、怎么传递数据——这些基础决策现在由 WordPress 核心统一负责
- 作者的个人感慨（背景语境，非技术内容）：作者认为 Block/Gutenberg 革命本该等这块拼图齐备了再推出，这几年一直觉得 WordPress 在前台交互这件事上「放任开发者自生自灭」；Interactivity API 的出现让他重新找回了对 WordPress 这个圈子的信心
- 这一章的实践任务：不是从零学新概念,而是「重做一遍已经很熟悉的东西」——把 Quiz Block 用 Interactivity API 重新实现前台交互部分,借助一个已知功能需求来理解这套新 API 具体怎么用
延伸 / 后续讲座会用到
下一讲开始动手，用官方脚手架工具 @wordpress/create-block 生成一个基于 Interactivity API 模板的全新插件,并把 Quiz Block 已有的编辑器端代码迁移进来。
Sources
Udemy：
- Become a WordPress Developer: Unlocking Power With Code — Section 30, EP223