HTML 铭文为什么在沙箱里打开：递归引用的边界

在资源管理器里点开一件 HTML 铭文作品，浏览器地址栏那一串路径和一层嵌套框架，其实执行着 Ordinals 官方文档里的沙箱规则。它决定了作品能引用什么、不能引用什么。本文讲这套机制的构成与动机。

数据模型借用了网页

官方文档把铭文的内容模型定义为网页的样子：一条铭文有一个 MIME 类型加一段字节内容，因此铭文内容可以由网页服务器返回。HTML 与 SVG 铭文正是靠这一点成为可编程的作品：一段 HTML 里写脚本，就能引用其他铭文的内容来渲染，这就是递归与委托生成艺术的基础。但可编程带来一个危险问题：如果铭文 HTML 能自由访问任意网络地址，作品的外观就可以随外部资源变化，链上刻下的就不再是作品的全部。

沙箱的两道锁

Ordinals 文档对沙箱（Sandboxing）的说明很短：HTML 与 SVG 铭文一律在带 sandbox 属性的 iframe 里加载，同时服务器对铭文内容返回内容安全策略（CSP）头。iframe 的 sandbox 属性限制内嵌文档的能力，CSP 则直接限定页面能连接哪些来源——实践中就是只允许同源的铭文服务。两道锁叠加的效果：铭文作品打不开外部网站、拉不到 CDN 字体、刷不了远端接口。任何声称链上作品却引用了站外图片或脚本的铭文，在浏览器层面就会被拦住，作品因此只可能由链上内容构成。

自引用路径：递归机制的地基

沙箱内还有一个关键约定：某条铭文的代码如果访问 /content/ 加自己铭文 ID 的路径，服务器返回的就是它自己的内容，页面也能从路径尾部读出自身 ID。委托铭文同样按这一规则服务——委托方的内容从自己的 ID 路径返回，而不是被委托方的路径。这个设计允许委托铭文拿自己的 ID 当生成种子渲染被委托的内容：两件作品共享同一段算法，却因种子不同各算各的图，全部可复现。

对持有者和创作者意味着什么

持有者角度：一件在沙箱里正常运行的 HTML 铭文，其视觉结果的原材料确实都在链上，这比“tokenURI 指向某台服务器”的结构更接近永久可渲染。但要记住浏览器只是其中一种读取方式，其他索引器可能用不同方式渲染，看到的效果差异属于工具层而非链上事实变化。创作者角度：沙箱意味着作品不能依赖外部 API、字体或库文件，一切素材必须内联或以铭文形式先刻上链；对性能敏感的作品还要掂量数据体积对应的费用。任何鼓励你在作品页面里连接外部服务、授权外部操作的设计，都与这套机制的初衷相悖，遇到时提高警惕。

判断一件 HTML 作品是否真在链上

普通读者也有简单的鉴别法：用官方 ord 服务的地址打开铭文内容，看渲染是否完整；再断网刷新同一页面，作品若依赖外部资源，断网时外观会立刻变化。另一招是查内容体积——纯链上 HTML 作品的内容大小通常与其脚本体量一致，几十 KB 的自包含页面很常见，而声称高清大图却只有几 KB 的，多半藏着外链。两种方法都不需要专业知识，却能过滤掉大部分“伪上链”作品。 从协议演进角度看，沙箱与自引用路径共同回答了生成艺术最难的问题：如何让一件作品的每次呈现都可复现。沙箱堵住外部变量，自引用给算法提供稳定种子，两者配合后，同一件作品在任何时间、任何节点渲染出同一结果，这正是链上生成艺术区别于普通网页作品的关键工程前提。

风险提示：本文仅介绍铭文展示机制，不构成任何投资建议。