接受 Signal 用户名请求可能会将你看到的标签改为发送者的个人资料名称，并且可能将该用户名聊天合并到你此前已通过手机号与同一人进行的聊天中。用户名是联系人键，不是匿名身份，也不是对话之间的屏障。在接受之前，请决定你是否能接受这种合并以及该名称在你的聊天列表中变为可见。
通过我们的 TraceSeek 应用查找公开社交资料的线索。
接受请求实际改变了什么
用户名是他人分享的地址，用于开始新聊天。它不是接受连接后显示的名称。在 Signal 的文档中，接受用户名请求会将显示的标签改为个人资料名称。这是你自己聊天列表内的标签变化，不是查询，也不是公开的个人资料页面。实际要点是，接受后你看到的名称可能与收到的用户名文本不同。这里没有任何内容能确定发送者是谁；用户名和个人资料名称都是标签，不是凭证。 [Signal 支持：用户名链接、消息请求与变更]
- 先读一遍请求中的共享用户名文本，然后在接受前暂停。
为何早先的手机号聊天很重要
Signal 的文档指出，现有的手机号聊天可以与用户名聊天合并，并显示两者属于同一账户。因此，如果你已经与该手机号有过对话，接受用户名请求不会创建一个独立、干净的线程。它可能将两者连接起来。这对连续性很有用，但如果你期望的是分离，就会感到不适。用户名不会将你与已经知道你的号码的联系人隔离，也不会为你创建一个全新的匿名身份。 [Signal 支持：用户名链接、消息请求与变更]
将你看到的内容与其含义分开
保持观察的狭窄范围：收到一个请求，它带有一个用户名，接受后可能显示个人资料名称并加入现有线程。限制同样重要。这些都不能证明身份、意图或可信度，也不能说明发送者的账户是安全还是不安全的。将名称与你联系人中已有的号码匹配，是记录之间的关联，不是证明该人就是标签所暗示的那个人。按你自己的条件决定：你是否希望该对话被合并，以及你是否想要这个请求。
| 观察 | 局限 | 下一步 |
|---|---|---|
| 有一个用户名请求正在等待 | 用户名文本不是显示的名称 | 接受、拒绝或按你自己的时间线让它保持待处理 |
| 你已有手机号聊天 | 接受可能合并线程 | 在决定前检查该聊天的历史记录 |
当你作为所有者预期收到请求时
如果你计划分享用户名，请预期对方在接受后看到你的个人资料名称，并预期先前的手机号线程会加入新线程。这是文档记录的行为，不是缺陷，这也是在分享用户名之前决定你的个人资料名称显示什么内容的理由。还要记住，之后更改用户名不会通知现有聊天，旧用户名链接也无法再用来与你的账户开始新聊天。这些事实影响你如何分享地址，不影响合并是否发生。 [Signal 支持：用户名链接、消息请求与变更]
- 在分享用户名之前审查你的个人资料名称，而不是在请求被接受之后。
如果文档与你看到的不一致
可用性和界面措辞可能有所不同，本指南不主张特定的菜单路径。如果你在应用中找不到所描述的行为，请记录该控件或措辞不可用，并就此停止，而不是猜测。使用官方当前帮助页面，或请账户所有者自愿分享当前截图或链接。不要将缺失的选项视为合并不会发生的证据，也不要将可见的选项视为合并会发生的证明。 [Signal 支持：用户名链接、消息请求与变更]
还有几个问题
Signal 用户名会对已经拥有我手机号的人隐藏我的手机号吗？
不会。用户名是一个独立地址，但文档记录的与现有手机号聊天的合并可能揭示两者之间的关联。已经知道你的号码的人不会因用户名而被隔离。
发送者会在我接受其请求之前看到我的个人资料名称吗？
在文档记录的流程中，接受请求才会将显示的标签改为个人资料名称。本指南不对接受之前显示什么作出主张；请将接受前的视图视为不确定，并根据你能记录在接受后发生的行为来做决定。
用户名是全新的匿名身份吗？
不是。它是用于开始聊天的地址，并且可以与现有的手机号线程合并。它不保证匿名或隔离，接受后显示的名称是标签，不是谁在写作的证明。
来源与编辑说明
官方参考资料核查于 2026年10月23日。清单、对比表和示例措辞是 DateClues 的编辑工具，不是官方测试或经过验证的风险评分。
一般信息。任何指南或工具都无法证明一个人的身份、意图或安全。 阅读我们的编辑标准。