聊 Solana 的 NFT 批量发行绕不开 Candy Machine，但很多中文内容讲的还是旧代形态。Metaplex 官方文档现在把产品线分成两条清晰的世界：Core 资产世界和 Token Metadata 世界。文档的产品状态表里，Core Candy Machine 负责”用守卫和规则铸造 Core 资产”，状态 Active、推荐；同表里的 Candy Machine 负责”铸造 Token Metadata NFT”，状态是 Deprecated——用官方原话，已弃用，改用 Core Candy Machine；被它服务的 Token Metadata 也降级为 Maintained、legacy。一次典型的搜索”Candy Machine 教程”，很可能把你带回一条官方已经不推荐的路径。
两代的分工差异要从资产模型说起。旧代 Candy Machine 绑定 Token Metadata 程序：先建一个 metadata 账户体系、上传一份配置好的缓存文件，NFT 走 Token Metadata 标准铸造。Core Candy Machine 则对准 Metaplex Core 资产模型——一套把创建、铸造、授权搬进单个程序、不再依赖外链 metadata 程序的资产结构。铸造逻辑本身在两代里承担同样的角色：按序消耗配置项（item）、按规则限制谁能铸、铸完关闸门；变的不是”批量铸造”这件事，而是铸出来的资产住在哪个程序里。
规则层两代共用一个名字：Candy Guard。谁能在什么时间铸、每个钱包限几枚、要不要付 SOL、要不要提供一个有效 token、要不要出示 Merkle 证明，全部由一组守卫（guard）组合声明，铸造交易必须同时通过这道检查。守卫以插件形态存在，地址门（限制单一地址）、空投指令、时间窗、每钱包限额都属于这一族。对买家来说，守卫清单就是铸造页上每一条”规则”的链上出处；对发行方来说，组合守卫相当于把发售条款写成程序可执行的形式，而不是白名单表格加一句口头承诺。
工具层是 Sugar——一条把”上传素材、建缓存、部署 Candy Machine、管理守卫”串起来的命令行。Sugar 覆盖 Core 与旧代两种工作流，airdrop 子命令可以直接给指定钱包列表空投（p）NFT 而不占公开铸造额度。上手顺序在文档里是固定的：装 Sugar、准备素材文件夹与配置、上传并部署，之后公开铸造入口和守卫状态都挂在部署出来的程序账户上。
对还挂在旧代上的存量项目，官方态度可以从状态表读出来：Deprecated 不等于失效，旧 Candy Machine 程序仍在链上可被调用，Token Metadata 资产仍在被钱包与市场支持（Maintained），但新功能和问题修复的重心在 Core 一侧。持有人自查旧代藏品时，流程仍然是老的：从 NFT 的元数据账户或缓存索引反查它出自哪台 Candy Machine 的哪个配置项；判断”我的那枚是否出自官方那台机器”，核对的是配置哈希（config 的 creator 与 uuid 等字段）与官方公布值是否一致，而不是页面设计。
把视角切回买家，两代形态下的自查动作几乎一样，但读取对象不同。公开铸造开始时，你要铸的那一行配置属于哪台 Candy Machine、当前已铸数量走到第几项、守卫还剩哪些生效，全部是链上账户的公开字段，铸造页只是渲染层。旧代路径下这些信息挂在 Candy Machine 程序账户与配置账户里；Core 路径下改读 Core Candy Machine 的程序状态。实操上最有效的验证只有一条：核对铸造交易的目标程序地址与配置地址是否来自项目官方渠道公布的值，两个地址对上，页面、推文、 Discord 公告说什么都不重要；对不上，哪怕视觉元素一模一样也应停止签名。
最后校准三个常见误区。其一，“Candy Store”这个词属于更老的早期设计草案，与现文档的 Candy Guard 不是同一物件，读旧教程时先对齐术语年代。其二，Candy Machine 在官方语义里始终是”铸造合约加配置”的组合，不是一个平台，不存在”去 Candy Machine 官网买币”的动作。其三，Guard 规则是铸造期规则，不影响二级转让；铸造完成后资产的流转回到资产模型本身（Core 或 Token Metadata）的转让规则，与守卫再无关系。引用状态词（Active、Deprecated、Maintained）时以 Metaplex 文档当前页面为准。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。