我是一名自学成才的学习者，正在努力完成“午夜”（Midnight）的任务，而本周我与该任务链之间产生了一些小摩擦。我部署了一份合约，获得了一个地址，像一位在汇报演出中自豪的家长那样提交了它，结果却收到了 Web3 领域中最令人伤心的四个字：“链上未找到合约。”
我的代码没有问题。我只是尚未理解“午夜”的网络和代币体系，而我信任的一篇教程将我引导至一个已不再存在的网络。
所以在开始之前：午夜团队，我爱你们，你们确实在构建隐私的未来，但请别再戏弄我们这些正在学习的人了。正如歌中所唱——我的感情，别玩弄它们。
好了。现在是地图时间。这是我希望有人在第一天就交给我的东西。
“午夜”并非单一网络（剧情反转）
让我困惑的第一件事是：“午夜”并不是一个单一的地方。这里有几个网络，它们彼此之间并不互通：
本地网络。你在自己的机器上使用 Docker 运行一个节点、一个索引器和一个证明服务器（人们称之为“独立模式”或“未部署模式”）。这里的一切仅存在于你的计算机上。
预览网（Preview）。一个公共测试网络。
预生产网（Preprod）。另一个公共测试网络，也是当前许多任务和教程指向的网络。
主网（Mainnet）。真正的生产网络。
“在我的机器上能运行”是软件开发中最古老的借口，而在“午夜”平台上，这有时字面意义上就是事实。我的合约绝对在链上。只不过这条链就是我的笔记本电脑。
哦，曾经还有一个名为 testnet-02 的网络。它已被停用。它已消失。但许多较旧的教程和示例代码库都是为它编写的，并且仍然直接指向它的幽灵。
陷阱：旧教程指向一个已“退群”的网络
testnet-02 为更新网络的运行铺平了道路。然后它继续前行，直至彻底消失。跟随针对该网络的旧教程，就像按照去年的地址去参加派对：灯光熄灭，杯子已收，无人光临。
以下是真正困扰我的地方。我分叉了一个较旧的示例去中心化应用（dApp），严格遵循其说明进行部署，结果我的合约无处可寻。当我最终打开项目的配置文件时，发现所有地址都指向那个已死亡的网络：
indexer = 'https://indexer.testnet-02.midnight.network/api/v1/graphql'
node = 'https://rpc.testnet-02.midnight.network'
这些 URL 已是墓碑。因此，在运行任何较旧的“午夜”项目之前，请打开其配置文件并检查它指向哪个网络。一种快速探测的方法：
grep -rn "midnight.network" --include=*.ts .
如果你看到“testnet-02”或类似“/api/v1”的旧路径，请缓慢后退。如今的活跃网络通过较新 API 版本上的“indexer.preview.midnight.network”和“indexer.preprod.midnight.network”访问。如果一个代码库自 testnet-02 存活以来从未被更新过，那么无论你的代码多么整洁，它可能都无法部署到任何你可以验证的地方。
“链上未找到合约”：两种常见的伤心原因
一旦理清了网络关系，这个错误终于变得合理了。当任务检查器（或其他人）找不到你的合约时，几乎总是以下两种情况之一：
你部署到了本地网络。地址是真实的，但它仅存在于你的机器上，其他地方都没有。（参见：“在我的机器上能运行”。）
你部署到了一个已死亡或错误的网络，因此它从未出现在任何活跃浏览器可以查看的地方。
两者的解决方法相同：部署到活跃的公共网络（预览网或预生产网），然后在向任何地方提交地址之前，先在公共浏览器中确认它。如果你在浏览器中找不到它，检查器也找不到。信任，但需验证——
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
