回复可能等在另一个收件箱里
没看到回复很容易误判。如果你在等一个不在你好友列表中的人的消息，首先要检查的是 Discord 是否把它转到了消息请求，而不是你的主私信列表。那是一条投递路径，不是对那个人的评判。
Discord 可以将非好友发来的消息转入消息请求，而不是主私信列表。来源
在你发送第二条消息之前，这一点很重要。当第一条消息还停留在待处理请求中时，重复联系尝试可能看起来像施压，而且对让消息被读到毫无帮助。先检查请求区域，再做决定。
请求区域实际向你展示什么
请求不只是一串名字。消息请求中的垃圾信息标签页让你在允许对方联系你之前，先看看是谁在请求联系你。
消息请求中的垃圾信息标签页让收件人查看发送者的个人资料和共同服务器，并接受或举报该请求。来源
这个审查步骤才是关键。你可以查看发送者的个人资料和共同服务器，判断该请求是否在预期之内，然后接受或举报它。两种选择都不是自动的，也都不是必须的。
一个实际限制：你不能总假设该标签页存在。它的出现取决于是否有待处理内容，你看到的控制项也可能不同。
消息请求标签页仅在至少有一个待处理请求时出现；请求控制项的可用性也取决于年龄组设置。来源
所以，如果你看不到消息请求标签页，这本身并不能证明对方从未给你写过消息、拉黑了你或隐藏了账号。它可能只是表示该区域目前没有待处理内容，或者你的设置以不同方式呈现请求控制项。不要把空标签页变成关于对方的故事。
再次发送前先做决定
当预期的消息没有出现时，按以下顺序操作。
- 先检查主私信列表。 确认你不是只是看错了地方。
- 寻找消息请求标签页。 如果它不存在，注意那里可能没有待处理内容，而不是假设有隐藏消息。
- 打开任何待处理请求并审查发送者。 将个人资料和共同服务器与你所了解的预期联系人进行对比。
- 选择分支： 如果是预期联系人，接受请求；如果个人资料和上下文与你被告知的情况不符，举报它；如果不确定并想先通过其他渠道核实，则保持待处理。
- 然后才决定是否再发一条消息。 如果第一条消息仍在待处理，第二条并不能解决问题。
分支表
| 你看到的情况 | 它可能意味着什么 | 合理的下一步 |
|---|---|---|
| 没有消息请求标签页 | 那里没有待处理内容，或者你的设置下请求控制项不同 | 检查主私信列表；不要断定对方在隐藏或已拉黑你 |
| 来自预期联系人的待处理请求 | 消息被作为请求路由，而不是进入你的主列表 | 查看个人资料和共同服务器，如果匹配则接受 |
| 来自意外账号的待处理请求 | 发送者可能不是你以为的人 | 查看个人资料和共同服务器；如果对不上就举报 |
| 你无法归类的请求 | 信息不足以判断 | 在接受前通过你已信任的渠道核实 |
这项检查不能告诉你什么
一个请求不存在、待处理或被归入垃圾信息，并不是关于某人意图、账号状态或与你关系的证据。它是一种路由和审查状态。把它当作其他任何事情的证据会导致错误的下一步行动——通常是重复发消息，让情况更糟。
同样，接受请求并不验证身份。个人资料和共同服务器列表是上下文，不是确认。如果消息很重要，通过你已控制的途径确认对方身份。
而且不要试图绕过他人的联系控制。如果你的消息无法送达，诚实的选项是等待、使用对方已同意的渠道，或者放下。试图绕过他们的设置不是故障排除步骤。
当真正的问题是你拥有哪个账号时
有时困惑根本不在于请求。你可能不确定你发消息的用户名是否属于你想联系的人。那是另一项任务，值得在解读缺失的回复之前完成。
如果你仍在弄清楚哪个个人资料是正确的，请参阅如何找到某人的 Discord 账号了解账号定位方面的问题。公开用户名匹配是线索，不是所有权证明，所以把你找到的任何个人资料视为需要确认的东西，而不是已确定的事情。
简短回顾
在 Discord 上重复联系尝试之前，先检查私信列表，然后寻找消息请求。如果有待处理请求，查看发送者的个人资料和共同服务器，并选择接受、举报或等待。如果标签页不存在，将其视为路由状态，而不是关于对方的证据——并且永远不要试图绕过他们的联系控制。