在 NEAR 上读一枚 NFT 的说明书，不用去抓任何外链 JSON——元数据接口本身就长在合约里。NEP-177 是 NEAR 官方 NFT 元数据标准，2022 年 3 月 3 日创建、状态 Final，它定义了两层元数据字段、一个版本声明字段，以及一套与 NEAR 存储押金模型配合的存放规则，思路和以太坊把 tokenURI 指向外部文件的做法有明显的结构差异。
先看版本声明。合约级元数据里有一个必填字段 spec，规范用强硬的措辞写着：它的值必须按 nft-1.0.0 的格式填写，表示这份合约遵循当前版本的元数据规范。NEP-177 文本解释了动机——让 NFT 的消费者（ marketplace、浏览器、钱包）在动手解析前先读一眼 spec，就能判断”我支持的功能这份合约用没用、我解析得了解析不了”。这个设计把兼容性协商做成了一个字符串比对，比”猜测对方字段含义”稳健得多；同一思路后来被多份以太坊草案借鉴。
合约级字段跟着是 name 与 symbol，都必填（示例里 name 写成 “Mochi Rising — Digital Edition” 或 “Metaverse 3” 这样的合集名，symbol 写成 “MOCHI” 这样的短代号）。单枚级元数据再列一枚一枚的属性：title 给这一枚起名字（文档示例 “Arch Nemesis: Mail Carrier”、“Parcel #5055”），以及描述、媒体、引用等字段，多数类型允许为 null。这套两级结构的作用是把”整个系列共用什么”与”每一枚特有啥”分开，市场渲染详情页时不必逐枚抓文件。
NEP-177 的 Rationale 部分专门讲了存放逻辑，这是它与以太坊标准分岔的地方。NEAR 的存储采用 storage staking 模型——往合约状态里写数据要按字节锁定押金，这使得在链上多存一些公共属性是可行且常规的；标准因此鼓励把常用属性直接放进合约，同时保留一条指向外部文档的标准通道（reference 类字段），给社区快速实验留出空间。文档随后处理了两种来源冲突的规则：“reference 指向的文档获胜”是原则，但规范同时打了隐私补丁——如果链上 icon 用了安全的 data URL 或干脆没设，而外部 reference 文档里放了一个侵犯隐私的 icon 链接，展示方不应该天真地采用外链版本，而应优先安全版本。一段罕见地把”外链不可信”写进标准正文的条款。
理解这套结构后，核对流程就清晰了。读合约级元数据用 nft_metadata 方法，单枚的元数据则挂在 nft_token 返回结果的 metadata 字段里；返回全是结构化 JSON，不需要再对外抓取——除非某字段本身就是个链接。押金的存在带来一个用户端细节：为”把一枚 NFT 转给你”这件事，接收方账户可能需要在该合约上寄存押金，历史上 NEAR 应用会提示这一点；标准文档在跨链段落里也提到，结构化的元数据正是 Rainbow Bridge 往以太坊搬代币时能对得上字段的基础。
再把两类字段的使用场景分边。链上字段适合放”必须长期成立的信息”：合约名称、代号、版本、逐枚的标题与属性——它们随节点数据一起被全网复制，只要链在就能读，代价是每个字段都占押金空间，所以体积要精打细算。外链字段适合放”大且可能演进的材料”：完整图像文件、长篇作品说明——标准允许 reference 类字段兜住这类需求，同时要求展示方在冲突时按隐私与安全优先取舍。审计一个 NEAR 藏品合约时，值得逐个入口实测一遍：nft_metadata 返回的 spec 是不是 nft-1.0.0、必填的 name 与 symbol 有没有空缺、token 级 title 是否真的逐枚不同——接口是标准方法，任何钱包都能替用户当场调用，不存在”要专用工具才看得见”的借口。
也要写清楚边界。spec 字段只是声明，不是验证——写了 nft-1.0.0 却缺字段的合约，链上不会自动报错，靠解析端逐字段核对；媒体文件若走外部链接，与以太坊的 IPFS 外链面临同样的耐久与篡改问题，标准没有替外链兜底。对展示方，逐字段容错、优先采用链上安全值、把 reference 来源标注给用户，是这份规范原文就支持的谨慎做法。对收藏者，在 NEAR 上看 NFT 详情页时多问一句”这个属性是合约里读的还是外链抓的”，答案决定了它有多可靠。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。