Instatic 内容管理

传统 CMS 留给前端的三个麻烦事

• 发布页面总被编辑器运行时拖累：不少 CMS 为了支持可视化编辑，会在输出的 HTML/CSS 里混入大量与编辑相关的脚本或工具类，导致页面加载变慢，还容易出现 div 嵌套混乱的问题。
• 设计规范和内容逻辑绑得太死：改个品牌色要翻遍整个项目的样式表，设计 token 散落在各个组件里，没有统一的生成和管理机制，画布里调好的颜色、间距，到线上容易跑偏。
• 工具类冗余与权限混乱：要么生成一堆用不上的 CSS 类，要么不同模块的样式互相冲突；权限控制要么过于简单，要么配置起来极其复杂，插件运行还不安全。

它是怎么把这些麻烦拆掉的

这个技能走了「单一服务器 + 干净输出」的路子，核心能力可以拆成四块：

• 设计层：自带多断点帧的可视化画布编辑器，能并排编辑不同屏幕尺寸的页面；内置 Core Framework，可以通过颜色标记自动生成色阶、流体排版尺度和间距节奏，还能用工具类生成器输出统一的 framework.css，避免冗余。
• 构建层：用模块（比如容器、文本、按钮）和视觉组件快速搭建页面，通过模板定义布局和内容出口，还能用循环在集合上重复渲染布局；内置 AI Agent，提供 35 个站点作用域工具和 15 个内容作用域工具，能辅助生成页面结构或填充内容。
• 管理层：用 data_tables 和 data_rows 搭建统一内容模型，数据工作区支持电子表格式编辑和草稿到发布的流程，媒体工作区用 OS 风格的文件管理器管理素材，权限控制覆盖 38 种能力，还支持 TOTP 和账号锁定。
• 扩展层：插件跑在 QuickJS-WASM 沙箱里，默认没有文件系统、环境变量和网络权限，必须显式授权才能使用；SDK 能自定义 HTTP 路由、存储和后台任务，还能扩展画布模块。

什么时候别选它

• 要是项目连 Bun 都没用过，得先花时间熟悉 Bun 的部署和运维，毕竟整个服务都跑在 Bun 服务器上。
• 插件沙箱限制很严格，要是需要插件访问外部 API 或文件系统，得额外走授权流程，比普通 CMS 的插件配置麻烦。
• 设计 token 依赖 Core Framework，如果项目有自己成熟的设计系统，可能需要调整或映射现有规范，没法直接复用。
• 自托管意味着要自己负责服务器的备份、监控和更新，不像托管型 CMS 那样开箱即用。