如果你折腾过自建网站，大概知道这个困境：WordPress 太重，插件装多了性能一言难尽；Webflow 这类 SaaS 工具好用，但数据和站点绑在别人平台上，月费也不便宜；纯手写 HTML 又太慢，改个样式要重新构建。
最近 GitHub Trending 上出现了一个有意思的新项目——Instatic，一天之内涨了 500+ star。它把自己定位为”自托管可视化 CMS”，目标是让你拥有站点、也享受搭建过程。听起来有点像 WordPress + Elementor 的开源自托管版，但技术栈完全是新一代的：Bun + React 19 + QuickJS-WASM 沙箱。
我花时间翻了文档和源码，这篇文章说说它是什么、适合谁、以及现在上车有什么坑。
Instatic 是什么
Instatic 是一个自托管一体化 CMS，把可视化编辑器、内容引擎、发布器全部集成在一个 Bun 服务里。它出的页面是纯语义 HTML + 精简 CSS，没有任何框架运行时，访问速度很快。
核心特点：
- 数据和站点完全归你所有，MIT 协议，无功能限制
- 一个服务覆盖建站、内容管理、发布全流程
- 输出纯净静态页面，可托管在任何静态服务上，不绑定平台
- 内置 AI 建站助手，支持 Claude、OpenAI、Ollama 等模型
开发团队是 Motion.page 和 Core Framework 的原班人马，在 WordPress 生态有多年建站工具开发经验，所以这个项目不是拍脑袋写的，是有实战背景的。
技术栈：为什么用 Bun + React 19
Instatic 的技术选型相当激进，全栈 TypeScript，运行时用 Bun（同时用于服务端和工具链）：
- 管理端前端：React 19（启用 React Compiler）+ Vite + Zustand + Mutative + CodeMirror + dnd-kit
- 服务端：基于 Bun.serve 的手写路由，没有用 Express/Nest 这类框架
- 数据库：支持 SQLite / Postgres，通过统一 DbClient 接口切换
- 插件系统：QuickJS-WASM 沙箱，默认无文件系统和网络权限，只有用户主动授权才可访问指定主机
- AI 接入：供应商无关驱动，基于原生 HTTP/SSE 实现，无第三方 SDK 依赖
用 Bun 而不是 Node.js，主要好处是：启动快、内置 SQLite 支持、运行时体积小。对于跑在 NAS 上的自托管服务来说，资源占用低是个优势。
React 19 的 Compiler 是这个项目比较新的地方——编译期自动优化重新渲染，减少了手动写 memo/useMemo 的负担。管理端这种重交互的界面，这个优化是有实际意义的。
核心功能速览
可视化设计系统
内置的 Core Framework 设计系统已经被数千 WordPress 用户使用，不是临时凑的。功能包括：
- 品牌色自动生成完整的明暗 shade 色阶
- 流体排版比例，随视口自动缩放
- 间距系统保证所有页面保持统一节奏
- 工具类生成器只输出你用到的样式，无冗余 CSS
编辑器支持多端同步编辑——可以同时打开桌面/平板/移动三个断点的画布，修改一处全局同步。这和 Webflow 的断点编辑思路类似，但对自托管项目来说比较少见。
内置设计系统，品牌色、排版、间距全部可视化配置
组件和模板系统
支持创建带类型参数的可复用组件，参数支持字符串、数字、布尔、颜色、图片、URL、富文本等类型。修改组件后所有实例同步更新，且自动阻止循环引用。
模板系统支持全局布局、按内容类型自定义布局、自定义 404 页面。内容通过 outlet 自动注入通用页头页脚，这个设计和 Next.js 的 layout 思路接近。
可复用组件带类型参数，修改后所有实例同步更新
媒体资源库
类操作系统的文件管理器，支持文件夹、智能文件夹、批量操作、资源引用追踪、替换、可插拔存储适配器。这个比 WordPress 的媒体库好用——可以追踪一张图片被哪些页面引用了，删除时会有提示。
媒体库支持引用追踪，删除资源前会提示哪些页面在用
AI 建站助手
支持接入 Claude、OpenAI、OpenRouter、本地 Ollama 等模型。用自然语言描述需求，AI 直接在画布生成可编辑的真实节点。内置 28 个工具，所有密钥和费用均由用户自行管理，不会偷偷上传你的 API key。
这个功能现在还是早期阶段，但方向是对的——很多人建站最大的障碍是不知道怎么开始，有个 AI 助手帮着生成初始布局和组件，门槛会低很多。
插件沙箱
插件运行在 QuickJS-WASM 沙箱里，默认没有任何权限。只有你主动授权，插件才能访问指定主机或文件系统。从根源避免恶意插件窃取数据或外传信息。
这个设计比我见过的很多自托管项目的插件系统都严谨。很多所谓的”插件”其实就是跑一段 Node.js 代码，权限和主程序一样，一旦装了恶意插件就完蛋。Instatic 这个沙箱思路是对的。
在 NAS 上部署
Instatic 提供了官方 Docker 镜像 ghcr.io/corebunch/instatic:latest，可以用 docker compose 启动。
最简单的方式，SQLite 版本（适合个人使用）：
# docker-compose.yml
services:
instatic:
image: ghcr.io/corebunch/instatic:latest
ports:
- "3001:3001"
volumes:
- ./data:/data
environment:
- DATABASE_URL=sqlite:///data/instatic.db
- NODE_ENV=production
restart: unless-stopped
跑起来之后访问 http://你的NAS_IP:3001/admin，首次访问会引导你创建站点和所有者账号。
也可以用 Railway 一键部署（官方提供了 SQLite 和 Postgres 两个模板），全程无需终端操作，约 2 分钟上线。但既然有 NAS，自己跑 Docker 更自在。
资源占用方面，Bun 的运行时比 Node.js 轻，官方说动态运行时只有约 0.7kB 的懒加载代码。实际跑起来内存占用应该在 200-500MB 范围，对现代 NAS 来说完全没问题。
现在的坑
说实话，这个项目目前有几个需要注意的地方：
- 0.x 版本：API 和工作流在 1.0 正式版前仍可能调整。如果你打算用于生产环境，建议等 1.0 或者做好随时迁移的准备。作为折腾项目完全没问题。
- Bun 依赖：虽然 Bun 已经相当成熟，但某些 NAS 的 Docker 环境里可能拉镜像比较慢（尤其是 ghcr.io）。飞牛 NAS 或群晖跑 Docker 一般没问题。
- 功能还在快速迭代：文档里明确说了”分析模块是当前迭代最快的部分”，意味着有些功能还不稳定。如果你需要的是稳定的生产工具，可以再等几个月。
- 社区还小：相比 WordPress 几万个插件、几千个主题，Instatic 的插件生态现在几乎没有。如果你需要特定功能，大概率要自己写或者等社区贡献。
和 WordPress 比，有什么不同
谈谈的博客就是跑在 WordPress 上的，所以我对 WP 的优缺点有切身感受。简单对比一下：
| 维度 | WordPress | Instatic |
|---|---|---|
| 部署 | 需要 PHP + MySQL，步骤多 | 单个 Docker 容器，一键启动 |
| 可视化编辑 | 需要装 Elementor 等插件 | 内置，开箱即用 |
| 输出产物 | 动态 PHP 页面，需要服务器渲染 | 纯静态 HTML+CSS，可直接放 CDN |
| 插件生态 | 几万个插件，生态成熟 | 刚起步，插件很少 |
| 资源占用 | PHP+MySQL，占用较高 | Bun 单进程，占用较低 |
| 学习曲线 | 上手简单，深入难 | 上手简单，文档还在完善 |
如果你已经有 WordPress 站点，没必要迁移。但如果你准备新建一个个人站点、作品集、或者小企业官网，Instatic 值得考虑——尤其是你想要完全掌控数据、又不想手写太多代码的话。
适合谁
- 个人博客/作品集：生成的页面性能优异，利于 SEO，部署简单
- 小企业官网：可视化编辑降低维护成本，无月费
- 对隐私敏感的用户：自托管无第三方追踪，表单数据全存在自有数据库
- 开发者：插件系统基于 WASM 沙箱，安全性较好，输出的纯净 HTML 方便二次开发
不太适合：需要复杂电商功能、或者依赖大量现有 WordPress 插件的场景。
总结
Instatic 是一个有想法、技术栈现代的自托管 CMS。它解决了几个痛点：建站工具要么太重（WordPress），要么数据不在自己手里（Webflow、Framer 等 SaaS），要么可视化能力弱（Hugo + 主题）。
现在上车的主要风险是 0.x 版本，API 可能变。但如果你是用来折腾、学习、或者建一个不太复杂的站点，完全可以用。MIT 协议意味着你随时可以 fork 自己维护。
对我来说，最感兴趣的是它的插件沙箱设计——QuickJS-WASM 这个方案在自托管项目里很少见，但确实是未来方向。如果你的 NAS 正好有空闲资源，花半小时跑起来看看，说不定会想把自己的小项目迁移过去。
GitHub: CoreBunch/Instatic
可自定义的 admin 仪表盘，12列 widget 网格，支持拖拽布局