签名请求
签名请求围绕真实操作中的判断顺序展开，不把术语孤立解释。本文把“消息签名可证明账户控制权但不一定发起交易”“交易签名会授权具体链上状态变化”和“结构化数据签名可能包含合约可解释的字段”放进可验证的使用流程，帮助用户在链上操作前后都知道应该检查什么。
- 使用自己可控的设备与网络
- 确认当前账户和网络
- 阅读完整请求后再决定是否签名
本页目录
开始前准备：消息签名可证明账户控制权但不一定发起交易执行第一阶段：结构化数据签名可能包含合约可解释的字段执行第二阶段：签名前先确认发起请求的网站域名完成后的验证：不应把“登录签名”默认理解为无风险常见错误与处理：拒绝不理解的签名不会损坏钱包开始前准备：消息签名可证明账户控制权但不一定发起交易
重点理解：交易签名会授权具体链上状态变化
理解“签名请求”时，可以先把“消息签名可证明账户控制权但不一定发起交易”与“交易签名会授权具体链上状态变化”放在同一个实际场景里看。前者说明当前对象或状态是什么，后者说明操作时还需要确认哪一层信息。只看界面名称容易忽略网络、合约或权限边界，因此更稳妥的做法是把能够公开验证的信息逐项对应起来，再决定是否继续。
实际操作中，“结构化数据签名可能包含合约可解释的字段”和“未知文本或十六进制内容需要谨慎”往往会连续出现，但它们并不是同一件事。可以先记录当前账户和网络，再查看地址、金额、合约或请求摘要；操作完成后使用交易哈希、区块状态或合约记录复核结果。这样能够把钱包中的提示与真实链上状态连接起来，而不是依赖单一画面作判断。
- 先确认消息签名可证明账户控制权但不一定发起交易。
- 再判断交易签名会授权具体链上状态变化与当前请求的关系。
- 把结构化数据签名可能包含合约可解释的字段作为独立核对点。
执行第一阶段：结构化数据签名可能包含合约可解释的字段
重点理解：未知文本或十六进制内容需要谨慎
围绕签名请求建立使用习惯时，重点不是记住按钮位置，而是理解“结构化数据签名可能包含合约可解释的字段”为什么影响下一步。“未知文本或十六进制内容需要谨慎”提供了另一个检查维度：当两个信息不一致时，应优先停止并重新核对来源。熟悉的名称、图标或页面样式都不能替代网络、地址、合约和交易记录等可验证信息。
把“签名前先确认发起请求的网站域名”放进操作流程后，可以采用“准备—确认—执行—验证”的顺序。准备阶段确认设备和入口，确认阶段检查账户、网络与对象，执行阶段阅读签名或交易内容，验证阶段再结合“签名时核对当前账户与网络”判断结果。若状态仍不清楚，不应通过连续重复提交来试探结果。
- 先确认结构化数据签名可能包含合约可解释的字段。
- 再判断未知文本或十六进制内容需要谨慎与当前请求的关系。
- 把签名前先确认发起请求的网站域名作为独立核对点。
执行第二阶段：签名前先确认发起请求的网站域名
重点理解：签名时核对当前账户与网络
签名请求涉及“签名前先确认发起请求的网站域名”时，用户最需要知道的是它会改变什么、不会改变什么。例如“签名时核对当前账户与网络”可能只是当前状态说明，也可能是后续操作的前提，因此应结合当前网络与账户上下文理解。对任何需要签名、授权或转账的动作，都要把最终请求内容作为独立检查对象。
验证结果时，可从“不应把“登录签名”默认理解为无风险”开始，再利用“某些签名可被第三方用于后续链上动作”补充判断。公开地址、网络、交易哈希和合约信息适合用于排查；助记词、私钥和验证码则不属于排查所需资料。第三方网页或所谓客服如果索取这些秘密信息，应停止操作并从可信入口重新确认。
- 先确认签名前先确认发起请求的网站域名。
- 再判断签名时核对当前账户与网络与当前请求的关系。
- 把不应把“登录签名”默认理解为无风险作为独立核对点。
完成后的验证：不应把“登录签名”默认理解为无风险
重点理解：某些签名可被第三方用于后续链上动作
在签名请求的实际使用中，“不应把“登录签名”默认理解为无风险”经常与“某些签名可被第三方用于后续链上动作”同时出现。两者需要分别确认，因为同一个账户可能在多个网络和多个 DApp 中使用，不能因为地址看起来相同就默认链上状态相同。把网络、资产对象与权限范围拆开检查，可以减少误把相似信息当成同一对象的情况。
完成操作后，“拒绝不理解的签名不会损坏钱包”可以帮助判断下一步，而“签名完成后仍应关注随后出现的授权或交易请求”则提供另一个可验证线索。链上交易通常无法由钱包单方面撤回，所以确认前多一次核对比事后补救更重要。第三方 DApp 与智能合约也可能存在技术或业务风险，应根据请求内容独立判断。
- 先确认不应把“登录签名”默认理解为无风险。
- 再判断某些签名可被第三方用于后续链上动作与当前请求的关系。
- 把拒绝不理解的签名不会损坏钱包作为独立核对点。
常见错误与处理：拒绝不理解的签名不会损坏钱包
重点理解：签名完成后仍应关注随后出现的授权或交易请求
长期使用签名请求时，可以围绕“拒绝不理解的签名不会损坏钱包”建立固定记录习惯，并定期回看“签名完成后仍应关注随后出现的授权或交易请求”是否仍符合当前目的。很多问题并不是功能失效，而是账户、网络、合约或权限上下文发生了变化。把这些上下文写清楚，能够更快区分显示问题、网络等待与真实链上状态变化。
当“消息签名可证明账户控制权但不一定发起交易”出现异常时，不要立刻用新的签名或交易覆盖原来的状态。先检查“交易签名会授权具体链上状态变化”，再通过公开链上信息确认已经发生的事实。需要求助时也只提供必要的公开信息；助记词和私钥始终由用户自行保管，imtoken 官方不会索取这些秘密信息。
- 先确认拒绝不理解的签名不会损坏钱包。
- 再判断签名完成后仍应关注随后出现的授权或交易请求与当前请求的关系。
- 把消息签名可证明账户控制权但不一定发起交易作为独立核对点。
操作核对清单
- 核对消息签名可证明账户控制权但不一定发起交易。
- 核对结构化数据签名可能包含合约可解释的字段。
- 核对签名前先确认发起请求的网站域名。
- 核对不应把“登录签名”默认理解为无风险。
- 核对拒绝不理解的签名不会损坏钱包。