我第一次打开 https://playground.wordpress.net 的时候，以为就是个普通的在线演示站。那种 PHP 跑在远程服务器上、浏览器只负责显示的东西。
结果不是。
我习惯性地打开开发者工具，切到 Network 面板，发现一件离谱的事：这个 WordPress 没有在跟任何服务器通信。PHP 代码全部在我的浏览器里执行，index.php、wp-settings.php、wp-db.php，一个不落。数据库查询也在跑，但不是 MySQL，是 SQLite。Web 服务器也有，一个 JavaScript 写的 Service Worker。
PHP，一个服务端语言，在浏览器里跑。没有后端，没有云主机，没有 Docker。纯粹在我电脑的一个浏览器标签页里运行。
这不是魔术，是 WebAssembly。
怎么做到的
三块积木拼起来的，每一块单看都不算新鲜，但拼到一起就炸了。
第一块：PHP 变成了 .wasm 文件。 PHP 官方并不原生支持编译到 WebAssembly。Playground 团队基于社区的 php-wasm 项目，用 Emscripten 把 PHP 源码编译成了 .wasm 二进制文件。浏览器下载这个文件，就能直接执行 PHP 代码。从 PHP 7.0 到 8.4，每个版本都有对应的 WASM 编译产物。
第二块：SQLite 替代 MySQL。 WordPress 原生只认 MySQL，但社区的 sqlite-database-integration 插件把所有 MySQL 调用翻译成了 SQLite 操作。单用户场景下完全够用，性能损耗可以忽略。WordPress 不需要装数据库服务器这件事，本身就够爽了。
第三块：JavaScript 充当 Web 服务器。 一个 Service Worker 拦截所有请求，路由到对应的 PHP 文件执行，再把结果返回。你看到的那个"网站"，本质上就是一个运行在浏览器标签页里的完整技术栈，只是把 Apache 换成了 WASM，把 MySQL 换成了 SQLite。
三块拼完，打开页面三秒钟，后台、数据库、文件系统全部就绪。关掉页面，一切消失，连临时文件都不留。
这是我在本地启动的 Playground 实例。完整的 WordPress 前台，主题、文章、导航，跟你在任何一台服务器上部署的 WordPress 没有区别。
不是玩具，真能干活
有人会说"这不就是个 demo 吗"。还真不是。它解决的都是我踩过的真实坑。
插件和主题开发
以前测一个插件：本地起环境，导入测试数据，装插件，改代码，刷新。中间任何一步翻车就排查半天。
现在，项目目录下跑一行命令：
cd my-plugin-directory
npx @wp-playground/cli server --auto-mount
自动检测你的项目是插件还是主题，挂载到 WordPress 实例里。改代码，刷新，看效果。不用碰 Nginx，不用建数据库，不用改 wp-config.php。
终端跑起来长这样：
$ npx @wp-playground/cli server --auto-mount
WordPress Playground CLI
PHP 8.3 WordPress latest
Extensions intl, redis, memcached
Ready! WordPress is running on http://127.0.0.1:9400 (6 workers)
一行命令，PHP 8.3 加最新 WordPress 加 SQLite，全部就绪。六个 Worker 进程等着接活。
多版本切换
npx @wp-playground/cli server --php=8.0 --wp=6.0
PHP 7.4 到 8.5，WordPress 各版本，随便切。以前验证"我的插件在 PHP 7.4 和 8.1 下能不能跑"得配两套环境，现在改个数字的事。
嵌到任何网页里
一个 iframe：
<iframe src="https://playground.wordpress.net/?mode=seamless"></iframe>
Query API 还能控制初始状态，指定 PHP 版本、预装插件、跳到指定页面。做交互式 WordPress 教程的人应该懂这意味着什么：读者不需要自己装环境，直接在你的文章里操作一个真实的 WordPress。
Bug 复现
遇到 WordPress 的 Bug，用 Playground 生成一个包含当前环境配置的链接。别人点开就能复现一模一样的场景，比写十段复现步骤管用。
Blueprint API：这才是杀手级功能
上面那些都是"用着方便"，Blueprint 才是 Playground 区别于"又一个在线演示"的东西。
简单说，Blueprint 是一种声明式的 JSON 配置格式，描述一个 WordPress 环境的完整状态：装哪些插件、用什么主题、有哪些文章、用户权限怎么配。把整个环境序列化成一段 JSON，分享给别人，对方加载后得到一模一样的站点。
直接看代码：
const client = await startPlaygroundWeb({
iframe: document.getElementById('wp-playground'),
remoteUrl: `https://playground.wordpress.net/remote.html`,
blueprint: {
preferredVersions: {
php: '8.0',
wp: 'latest',
},
steps: [
{
step: 'login',
username: 'admin',
password: 'password',
},
{
step: 'installPlugin',
pluginData: {
resource: 'wordpress.org/plugins',
slug: 'gutenberg',
},
},
],
},
});
这段代码干的事：启动 PHP 8.0 加最新 WordPress，自动登录 admin 账号，然后从 WordPress.org 安装 Gutenberg 插件。全自动，用户看到的就是一个已经配好的 WordPress。
做个"一键部署 WordPress 教学环境"的按钮？没问题。写交互式文档，让读者直接在文章里操作真实的 WordPress？也行。Blueprint 把"给人一个 WordPress 环境"这件事的成本压到了接近零。
离线和 VS Code
两个加分项。
离线能跑。 加载过一次之后，断网照样用。Service Worker 把所有资源缓存了，SQLite 数据库在浏览器本地。高铁上写代码，会议室里演示（对，就是公司 WiFi 又挂了那种场景），都不影响。
VS Code 插件。 官方出了个 WordPressPlayground.wordpress-playground 扩展，装上之后 VS Code 里直接起 WordPress 实例。支持插件开发、主题开发，甚至直接打开一个 WordPress 站点目录自动挂载。在 VS Code 集成终端里跑 Playground CLI，改代码、刷新、看效果，不用离开编辑器。
这是实际登录后的管理面板。左侧完整的 WordPress 管理菜单，顶部显示当前 PHP 版本和 WordPress 版本。跟你见过的任何 WordPress 后台一样，只是它跑在浏览器里。
说点实话
Playground 还不是生产级工具。官方自己的定位是"活跃探索中的实验性项目"，三个字的含金量：别上生产。
性能。 WASM 毕竟不是原生执行，大量计算密集操作会明显慢于真正的服务器。几千篇文章的后台列表页，你能感觉到卡。
PHP 扩展不全。 编译到 WASM 的 PHP 只包含常用扩展，冷门的可能缺失或行为不一致。
API 不稳定。 项目在快速迭代，今天的接口明天可能就变了。
但这些不影响它在开发和演示场景里的价值。工具不需要完美，在对的时候解决对的问题就够了。
总结
WordPress Playground 让我想起 Docker 刚出来那会儿，不是什么从零到一的发明，但把已有技术组合出了一个极其顺滑的体验。以后有人问"怎么学 WordPress 开发"，甩一个链接过去就够了，不用再写十步环境搭建指南。
- 项目地址：https://github.com/WordPress/wordpress-playground
- 在线体验：https://playground.wordpress.net
- 文档：https://developer.wordpress.org/playground/
参考资料
- WordPress Playground 官方文档
- WordPress/wordpress-playground - GitHub（1.9K Stars）
- How WebAssembly is powering WordPress - Wasmer Blog
原文标题： WordPress Playground：把 PHP、数据库、Web 服务器全塞进浏览器，三秒启动 WordPress
原文地址： https://phpreturn.com/index/a6a05a68cbef7c.html
原文平台： PHP武器库
版权声明： 本文由phpreturn.com（PHP武器库官网）原创和首发，所有权利归phpreturn（PHP武器库）所有，本站允许任何形式的转载/引用文章，但必须同时注明出处。