1
月
在社区成长 1 月
LEVEL 1
1 XP
一、背景
移动端加密货币钱包的安全，不只是“助记词有没有泄露”。一次资产损失往往同时涉及多个环节：私钥保存不当、签名页面展示不完整、恶意深链唤起、DApp 授权额度过大、RPC 返回被污染、用户误把授权交易当成转账，以及设备本身被调试、录屏或注入。
本文以 EVM 兼容链上的移动钱包为例，建立一套可以在本地实验环境和测试网中执行的检查流程。重点覆盖密钥生命周期、Android/iOS 客户端攻击面、交易数据解析、代币授权和链上风险识别。所有命令只应对自有应用、授权测试包、本地节点或公开测试网使用，不要导入真实助记词，也不要对第三方钱包绕过保护机制。
二、核心原理：钱包实际保护的是什么
非托管钱包的核心能力可以拆成四层：
1. 密钥层：生成、派生、保存和使用私钥。常见助记词遵循 BIP-39，随后通过 BIP-32/BIP-44 路径派生账户。助记词一旦泄露，修改应用密码并不能阻止攻击者在其他设备恢复账户。
2. 签名层：钱包对交易或消息生成数字签名。签名通常在本地完成，链上只看到签名结果，不应看到私钥。
3. 展示层：把 calldata、目标合约、金额、链 ID 和授权对象转化为用户能理解的确认页面。展示错误会导致“用户签的是 A，界面却描述成 B”。
4. 通信层：通过 RPC 查询余额、nonce、Gas、合约代码和交易回执。RPC 通常不能直接窃取私钥，但可以隐藏交易、伪造模拟结果或诱导钱包展示错误链状态，因此不能被当成绝对可信来源。
安全评估必须同时回答三个问题：密钥是否可能离开可信边界、用户是否真正理解签名内容、链上对象是否符合预期。
三、前置条件与实验边界
建议准备：
1. 一台不存放真实资产的 Android 测试机或模拟器；iOS 可使用测试设备或 Simulator，但 Secure Enclave 等能力在模拟器上并不等价。
2. 一个专门用于测试网的全新助记词，测试完成后废弃。
3. Android Platform Tools，用于 adb 和 logcat。
4. Foundry 的 cast 工具，用于解析 calldata 和查询链上状态；也可以使用 ethers.js 或 web3.py 替代。
5. 自建测试应用、开源演示钱包或明确获得授权的测试包。
6. 公开测试网 RPC 或本地 Anvil 节点。不要在命令历史、脚本或截图中放入主网私钥。
可启动本地 EVM 节点：
anvil --host 127.0.0.1 --port 8545
Anvil 输出的测试私钥只能用于这个临时本地链。切勿向这些地址转入真实资产，也不要把示例私钥复用于任何公网链。
四、分步骤实践
步骤一：先画清钱包的数据流和信任边界
至少列出以下对象：助记词、派生私钥、应用解锁口令、Keystore/Keychain 条目、WalletConnect 会话、DApp URL、RPC 地址、交易模拟服务和崩溃日志服务。
逐项标注数据出现的位置：内存、数据库、SharedPreferences、剪贴板、日志、截图、备份文件和网络请求。一个基本原则是：助记词和私钥不应出现在日志、分析事件、剪贴板持久记录、云备份及明文数据库中；签名请求必须绑定明确的链 ID、目标地址和原始数据。
步骤二：检查 Android 组件与本地存储边界
对自有测试包执行：
adb shell dumpsys package com.example.wallet
adb shell pm path com.example.wallet
adb logcat | grep -iE "mnemonic|private.?key|seed|signature"
检查 exported Activity、Service、Receiver 和 Provider 是否确有对外开放的业务需要。钱包常使用深链处理支付请求或 WalletConnect 回调，如果组件可被任意应用唤起，应验证 URI 的 scheme、host、path、chainId 和回调来源，不能仅判断字符串中是否包含某个域名。
日志检查时，执行创建测试钱包、切换账户、签名测试消息和发送测试交易等正常流程，观察是否打印助记词、私钥、完整签名请求或用户口令。生产构建应关闭敏感调试日志，并对崩溃上报字段做脱敏。
本地保存方面，Android 应优先使用硬件支持的 Keystore 保护加密密钥，再用该密钥加密钱包材料；不能把“经过 Base64 编码”误认为加密。iOS 应使用 Keychain，并根据产品需求选择合适的可访问级别，例如仅在设备解锁后可用、禁止迁移到其他设备等。生物识别更适合作为访问密钥的门槛，而不是直接替代密钥加密设计。
还应检查 AndroidManifest.xml 中的备份策略。包含钱包密文、会话令牌或账户元数据的文件，应明确排除在不必要的系统备份之外。即使私钥已加密，备份泄露也会扩大离线口令猜测和隐私关联风险。
步骤三：验证助记词与解锁口令的安全语义
应用密码通常只保护本机保存的密钥副本，不会改变链上私钥。测试确认以下行为：
1. 连续输错密码是否有递增延迟或合理的尝试限制。
2. 应用切入后台后是否遮挡任务快照，防止助记词或余额页面出现在最近任务列表。
3. 助记词展示页面是否默认禁止截图、录屏和不必要的剪贴板复制。
4. 修改应用密码后，旧备份是否仍可被旧密码解密；如果可以，界面必须明确说明风险。
5. 删除钱包时是否只删除界面记录，还是同时清理密文、缓存、派生地址和 WalletConnect 会话。
不要设计“上传助记词以便找回”的功能。若产品采用云端加密备份，应清晰说明密钥派生、加密位置、认证恢复和服务器可见信息，并对低强度口令导致的离线猜测风险进行专门评估。
步骤四：检查网络请求，但不要把抓包等同于破解
在自有测试包中，可将设备代理指向本地 mitmproxy，观察 RPC、价格服务和 DApp 元数据请求。测试 CA 只能安装在隔离设备上，完成后及时删除。若应用实现了证书固定，应通过专用 debug 构建提供测试开关，而不是尝试绕过第三方应用的固定策略。
重点关注：
1. 是否通过明文 HTTP 访问 RPC 或配置接口。
2. 请求中是否包含助记词、私钥、解锁密码或完整 Keystore 文件。
3. WalletConnect 配对信息、推送标识和设备标识是否被无必要地发送给统计服务。
4. RPC 切换时是否校验实际 chainId，防止界面显示网络与签名链不一致。
5. 余额和交易状态是否只依赖单一服务，服务异常时有没有明确告警。
RPC 是不可信输入。钱包应校验返回值格式，并对关键操作使用多个来源、轻客户端证明或可信模拟服务进行交叉验证。不能因为 eth_call 返回成功，就断定实际交易一定安全。
步骤五：在签名前解析交易，而不是只看按钮文字
以 ERC-20 授权为例，函数签名为：
approve(address,uint256)
可计算函数选择器：
cast sig "approve(address,uint256)"
常见结果是 4 字节选择器加编码后的 spender 和 amount。确认页至少应显示：目标代币合约、被授权地址、授权额度、链 ID、预计 Gas，以及该操作不是普通转账。
若 amount 等于 uint256 最大值，通常表示近似无限授权：
115792089237316195423570985008687907853269984665640564039457584007913129639935
无限授权不一定等同于恶意，因为部分协议会用它减少重复授权交易；但它把未来风险集中到了 spender 合约。一旦 spender 存在漏洞、升级权限被滥用或前端替换交易目标，用户余额可能受到影响。钱包应明确标出“无限额度”，而不是只显示“授权成功”。
对 EIP-712 类型化数据签名，应展示 domain.name、verifyingContract、chainId、primaryType 和关键字段。普通 personal_sign 可能包含难以理解的十六进制内容，不能简单标注成“登录”。尤其要警惕把 Permit、Permit2 或订单授权包装成无 Gas 登录签名的情况。
步骤六：在测试网查询并撤销代币授权
先查询 owner 对 spender 的当前 allowance：
cast call $TOKEN "allowance(address,address)(uint256)" $OWNER $SPENDER --rpc-url $RPC
如需在本地链或测试网撤销，可以将额度设为 0：
cast send $TOKEN "approve(address,uint256)" $SPENDER 0 --private-key $TEST_KEY --rpc-url $RPC
这里的 TEST_KEY 必须是专用测试私钥。生产环境更建议通过硬件钱包或受控签名器确认交易，不要把私钥直接放到终端参数，因为 shell 历史和进程列表可能泄露参数。
还要注意：撤销授权本身也是链上交易，需要 Gas；撤销前应再次核对 TOKEN、SPENDER、chainId 和 nonce。部分代币实现并不完全遵循标准，查询成功不代表写入行为必然一致。
步骤七：用链上数据核验交易结果
提交测试交易后，不应仅依据钱包界面的“已发送”状态。可以查询：
cast receipt $TX_HASH --rpc-url $RPC
cast transaction $TX_HASH --rpc-url $RPC
cast code $TARGET --rpc-url $RPC
重点核验：
1. receipt 的 status 是否成功。
2. 区块确认数是否达到业务要求。
3. to 地址是否与确认页一致。
4. input 的前 4 字节是否对应预期函数。
5. 日志中的 Transfer 或 Approval 事件是否与预期资产、from、to、spender、value 一致。
6. 目标地址是否存在合约代码。没有代码可能是外部账户，也可能是尚未部署或已发生特殊状态变化，不能只据此判定安全。
7. 合约是否为代理。若是代理，风险评估还要覆盖实现合约、管理员和升级权限，而不能只看代理地址多年未变。
链上事件是重要证据，但事件由合约产生，恶意合约可以发出具有迷惑性的同名事件。资产实际变化应结合合约状态、余额和交易执行结果判断。
步骤八：建立可落地的风险评分
可以为签名前提示设置简单规则：
高风险：助记词或私钥将离开设备；chainId 不匹配；授权对象与当前 DApp 域名无关联；无限授权给新部署或不可解释的 spender；签名内容无法解析；交易模拟显示可转走多种资产。
中风险：合约为可升级代理但管理员信息不透明；请求批量调用；授权额度显著超过当前操作需要；RPC 与浏览器查询结果冲突；DApp 域名为近似拼写。
提示风险：首次交互；Gas 显著偏离近期水平；Token 名称、符号与知名资产相同但合约地址不同。
评分不能替代人工判断。尤其不要仅根据“合约已验证”“代币有图标”或“交易曾被很多地址调用”就判定安全。
五、风险与注意事项
1. 测试助记词必须与真实资产完全隔离，测试后废弃。
2. 不要在主力手机安装测试 CA、来历不明的抓包插件或 Root 模块。
3. 地址在展示时应支持完整查看和复制后校验，首尾几位相同并不能证明地址正确，存在地址投毒风险。
4. 交易模拟可能因区块状态、MEV、代理升级、时间条件和调用者差异而与实际上链结果不同。
5. 多签钱包降低单点私钥风险，但签名人仍需独立核对交易数据；多人盲签不等于安全。
6. 硬件钱包可以隔离私钥，却无法自动识别所有恶意授权。设备屏幕上仍应核对目标、金额和网络。
7. 区块浏览器和第三方风险标签可作为辅助信息，不应作为唯一事实来源。
六、常见问题
问：钱包没有上传私钥，是不是就安全？
答：不是。恶意 DApp 不需要拿到私钥，只要诱导用户签署无限授权、Permit 或资产转移交易，就可能造成损失。
问：撤销 ERC-20 授权后，旧签名一定失效吗？
答：链上 allowance 设为 0 后，依赖该 allowance 的 transferFrom 通常无法继续使用，但离线签署的 Permit、订单或其他协议级授权可能有独立 nonce、截止时间和撤销机制，需要分别检查。
问：只连接钱包但不签名，会丢资产吗？
答：一般的地址连接主要暴露公开地址和链上画像，不会直接转走资产；但隐私关联、恶意跳转和后续诱导签名仍是风险。应及时清理不再使用的会话。
问：为什么更换 RPC 后余额不同？
答：可能是节点同步高度、链 ID、缓存、代币列表或索引服务不同。先核对链 ID、最新区块高度、代币合约地址和 decimals，再判断是否为异常。
问：应用检测到 Root 或越狱就足够了吗？
答：不够。环境检测只能增加攻击成本，也可能被绕过。真正关键的是私钥硬件保护、最小化敏感数据、可信确认界面、服务端风控和链上交易可解释性。
七、总结
移动钱包安全应围绕“密钥不外泄、签名可理解、链上可核验”建立闭环。客户端层面要控制组件暴露、深链输入、本地存储、日志、备份和网络信任；交易层面要解析 calldata、区分转账与授权、识别无限额度和 EIP-712 签名；链上层面要核对回执、事件、合约代码、代理关系和授权状态。
最有效的实践不是记住某个风险标签，而是每次操作都能回答：在哪条链上、与哪个合约交互、调用什么函数、谁获得什么权限、权限能持续多久、最终状态如何从链上独立验证。把这套流程固化到钱包界面、测试用例和日常使用习惯中，才能真正降低移动端加密资产的操作风险。
移动端加密货币钱包的安全，不只是“助记词有没有泄露”。一次资产损失往往同时涉及多个环节：私钥保存不当、签名页面展示不完整、恶意深链唤起、DApp 授权额度过大、RPC 返回被污染、用户误把授权交易当成转账，以及设备本身被调试、录屏或注入。
本文以 EVM 兼容链上的移动钱包为例，建立一套可以在本地实验环境和测试网中执行的检查流程。重点覆盖密钥生命周期、Android/iOS 客户端攻击面、交易数据解析、代币授权和链上风险识别。所有命令只应对自有应用、授权测试包、本地节点或公开测试网使用，不要导入真实助记词，也不要对第三方钱包绕过保护机制。
二、核心原理：钱包实际保护的是什么
非托管钱包的核心能力可以拆成四层：
1. 密钥层：生成、派生、保存和使用私钥。常见助记词遵循 BIP-39，随后通过 BIP-32/BIP-44 路径派生账户。助记词一旦泄露，修改应用密码并不能阻止攻击者在其他设备恢复账户。
2. 签名层：钱包对交易或消息生成数字签名。签名通常在本地完成，链上只看到签名结果，不应看到私钥。
3. 展示层：把 calldata、目标合约、金额、链 ID 和授权对象转化为用户能理解的确认页面。展示错误会导致“用户签的是 A，界面却描述成 B”。
4. 通信层：通过 RPC 查询余额、nonce、Gas、合约代码和交易回执。RPC 通常不能直接窃取私钥，但可以隐藏交易、伪造模拟结果或诱导钱包展示错误链状态，因此不能被当成绝对可信来源。
安全评估必须同时回答三个问题：密钥是否可能离开可信边界、用户是否真正理解签名内容、链上对象是否符合预期。
三、前置条件与实验边界
建议准备：
1. 一台不存放真实资产的 Android 测试机或模拟器；iOS 可使用测试设备或 Simulator，但 Secure Enclave 等能力在模拟器上并不等价。
2. 一个专门用于测试网的全新助记词，测试完成后废弃。
3. Android Platform Tools，用于 adb 和 logcat。
4. Foundry 的 cast 工具，用于解析 calldata 和查询链上状态；也可以使用 ethers.js 或 web3.py 替代。
5. 自建测试应用、开源演示钱包或明确获得授权的测试包。
6. 公开测试网 RPC 或本地 Anvil 节点。不要在命令历史、脚本或截图中放入主网私钥。
可启动本地 EVM 节点：
anvil --host 127.0.0.1 --port 8545
Anvil 输出的测试私钥只能用于这个临时本地链。切勿向这些地址转入真实资产，也不要把示例私钥复用于任何公网链。
四、分步骤实践
步骤一：先画清钱包的数据流和信任边界
至少列出以下对象：助记词、派生私钥、应用解锁口令、Keystore/Keychain 条目、WalletConnect 会话、DApp URL、RPC 地址、交易模拟服务和崩溃日志服务。
逐项标注数据出现的位置：内存、数据库、SharedPreferences、剪贴板、日志、截图、备份文件和网络请求。一个基本原则是：助记词和私钥不应出现在日志、分析事件、剪贴板持久记录、云备份及明文数据库中；签名请求必须绑定明确的链 ID、目标地址和原始数据。
步骤二：检查 Android 组件与本地存储边界
对自有测试包执行：
adb shell dumpsys package com.example.wallet
adb shell pm path com.example.wallet
adb logcat | grep -iE "mnemonic|private.?key|seed|signature"
检查 exported Activity、Service、Receiver 和 Provider 是否确有对外开放的业务需要。钱包常使用深链处理支付请求或 WalletConnect 回调，如果组件可被任意应用唤起，应验证 URI 的 scheme、host、path、chainId 和回调来源，不能仅判断字符串中是否包含某个域名。
日志检查时，执行创建测试钱包、切换账户、签名测试消息和发送测试交易等正常流程，观察是否打印助记词、私钥、完整签名请求或用户口令。生产构建应关闭敏感调试日志，并对崩溃上报字段做脱敏。
本地保存方面，Android 应优先使用硬件支持的 Keystore 保护加密密钥，再用该密钥加密钱包材料；不能把“经过 Base64 编码”误认为加密。iOS 应使用 Keychain，并根据产品需求选择合适的可访问级别，例如仅在设备解锁后可用、禁止迁移到其他设备等。生物识别更适合作为访问密钥的门槛，而不是直接替代密钥加密设计。
还应检查 AndroidManifest.xml 中的备份策略。包含钱包密文、会话令牌或账户元数据的文件，应明确排除在不必要的系统备份之外。即使私钥已加密，备份泄露也会扩大离线口令猜测和隐私关联风险。
步骤三：验证助记词与解锁口令的安全语义
应用密码通常只保护本机保存的密钥副本，不会改变链上私钥。测试确认以下行为：
1. 连续输错密码是否有递增延迟或合理的尝试限制。
2. 应用切入后台后是否遮挡任务快照，防止助记词或余额页面出现在最近任务列表。
3. 助记词展示页面是否默认禁止截图、录屏和不必要的剪贴板复制。
4. 修改应用密码后，旧备份是否仍可被旧密码解密；如果可以，界面必须明确说明风险。
5. 删除钱包时是否只删除界面记录，还是同时清理密文、缓存、派生地址和 WalletConnect 会话。
不要设计“上传助记词以便找回”的功能。若产品采用云端加密备份，应清晰说明密钥派生、加密位置、认证恢复和服务器可见信息，并对低强度口令导致的离线猜测风险进行专门评估。
步骤四：检查网络请求，但不要把抓包等同于破解
在自有测试包中，可将设备代理指向本地 mitmproxy，观察 RPC、价格服务和 DApp 元数据请求。测试 CA 只能安装在隔离设备上，完成后及时删除。若应用实现了证书固定，应通过专用 debug 构建提供测试开关，而不是尝试绕过第三方应用的固定策略。
重点关注：
1. 是否通过明文 HTTP 访问 RPC 或配置接口。
2. 请求中是否包含助记词、私钥、解锁密码或完整 Keystore 文件。
3. WalletConnect 配对信息、推送标识和设备标识是否被无必要地发送给统计服务。
4. RPC 切换时是否校验实际 chainId，防止界面显示网络与签名链不一致。
5. 余额和交易状态是否只依赖单一服务，服务异常时有没有明确告警。
RPC 是不可信输入。钱包应校验返回值格式，并对关键操作使用多个来源、轻客户端证明或可信模拟服务进行交叉验证。不能因为 eth_call 返回成功，就断定实际交易一定安全。
步骤五：在签名前解析交易，而不是只看按钮文字
以 ERC-20 授权为例，函数签名为：
approve(address,uint256)
可计算函数选择器：
cast sig "approve(address,uint256)"
常见结果是 4 字节选择器加编码后的 spender 和 amount。确认页至少应显示：目标代币合约、被授权地址、授权额度、链 ID、预计 Gas，以及该操作不是普通转账。
若 amount 等于 uint256 最大值，通常表示近似无限授权：
115792089237316195423570985008687907853269984665640564039457584007913129639935
无限授权不一定等同于恶意，因为部分协议会用它减少重复授权交易；但它把未来风险集中到了 spender 合约。一旦 spender 存在漏洞、升级权限被滥用或前端替换交易目标，用户余额可能受到影响。钱包应明确标出“无限额度”，而不是只显示“授权成功”。
对 EIP-712 类型化数据签名，应展示 domain.name、verifyingContract、chainId、primaryType 和关键字段。普通 personal_sign 可能包含难以理解的十六进制内容，不能简单标注成“登录”。尤其要警惕把 Permit、Permit2 或订单授权包装成无 Gas 登录签名的情况。
步骤六：在测试网查询并撤销代币授权
先查询 owner 对 spender 的当前 allowance：
cast call $TOKEN "allowance(address,address)(uint256)" $OWNER $SPENDER --rpc-url $RPC
如需在本地链或测试网撤销，可以将额度设为 0：
cast send $TOKEN "approve(address,uint256)" $SPENDER 0 --private-key $TEST_KEY --rpc-url $RPC
这里的 TEST_KEY 必须是专用测试私钥。生产环境更建议通过硬件钱包或受控签名器确认交易，不要把私钥直接放到终端参数，因为 shell 历史和进程列表可能泄露参数。
还要注意：撤销授权本身也是链上交易，需要 Gas；撤销前应再次核对 TOKEN、SPENDER、chainId 和 nonce。部分代币实现并不完全遵循标准，查询成功不代表写入行为必然一致。
步骤七：用链上数据核验交易结果
提交测试交易后，不应仅依据钱包界面的“已发送”状态。可以查询：
cast receipt $TX_HASH --rpc-url $RPC
cast transaction $TX_HASH --rpc-url $RPC
cast code $TARGET --rpc-url $RPC
重点核验：
1. receipt 的 status 是否成功。
2. 区块确认数是否达到业务要求。
3. to 地址是否与确认页一致。
4. input 的前 4 字节是否对应预期函数。
5. 日志中的 Transfer 或 Approval 事件是否与预期资产、from、to、spender、value 一致。
6. 目标地址是否存在合约代码。没有代码可能是外部账户，也可能是尚未部署或已发生特殊状态变化，不能只据此判定安全。
7. 合约是否为代理。若是代理，风险评估还要覆盖实现合约、管理员和升级权限，而不能只看代理地址多年未变。
链上事件是重要证据，但事件由合约产生，恶意合约可以发出具有迷惑性的同名事件。资产实际变化应结合合约状态、余额和交易执行结果判断。
步骤八：建立可落地的风险评分
可以为签名前提示设置简单规则：
高风险：助记词或私钥将离开设备；chainId 不匹配；授权对象与当前 DApp 域名无关联；无限授权给新部署或不可解释的 spender；签名内容无法解析；交易模拟显示可转走多种资产。
中风险：合约为可升级代理但管理员信息不透明；请求批量调用；授权额度显著超过当前操作需要；RPC 与浏览器查询结果冲突；DApp 域名为近似拼写。
提示风险：首次交互；Gas 显著偏离近期水平；Token 名称、符号与知名资产相同但合约地址不同。
评分不能替代人工判断。尤其不要仅根据“合约已验证”“代币有图标”或“交易曾被很多地址调用”就判定安全。
五、风险与注意事项
1. 测试助记词必须与真实资产完全隔离，测试后废弃。
2. 不要在主力手机安装测试 CA、来历不明的抓包插件或 Root 模块。
3. 地址在展示时应支持完整查看和复制后校验，首尾几位相同并不能证明地址正确，存在地址投毒风险。
4. 交易模拟可能因区块状态、MEV、代理升级、时间条件和调用者差异而与实际上链结果不同。
5. 多签钱包降低单点私钥风险，但签名人仍需独立核对交易数据；多人盲签不等于安全。
6. 硬件钱包可以隔离私钥，却无法自动识别所有恶意授权。设备屏幕上仍应核对目标、金额和网络。
7. 区块浏览器和第三方风险标签可作为辅助信息，不应作为唯一事实来源。
六、常见问题
问：钱包没有上传私钥，是不是就安全？
答：不是。恶意 DApp 不需要拿到私钥，只要诱导用户签署无限授权、Permit 或资产转移交易，就可能造成损失。
问：撤销 ERC-20 授权后，旧签名一定失效吗？
答：链上 allowance 设为 0 后，依赖该 allowance 的 transferFrom 通常无法继续使用，但离线签署的 Permit、订单或其他协议级授权可能有独立 nonce、截止时间和撤销机制，需要分别检查。
问：只连接钱包但不签名，会丢资产吗？
答：一般的地址连接主要暴露公开地址和链上画像，不会直接转走资产；但隐私关联、恶意跳转和后续诱导签名仍是风险。应及时清理不再使用的会话。
问：为什么更换 RPC 后余额不同？
答：可能是节点同步高度、链 ID、缓存、代币列表或索引服务不同。先核对链 ID、最新区块高度、代币合约地址和 decimals，再判断是否为异常。
问：应用检测到 Root 或越狱就足够了吗？
答：不够。环境检测只能增加攻击成本，也可能被绕过。真正关键的是私钥硬件保护、最小化敏感数据、可信确认界面、服务端风控和链上交易可解释性。
七、总结
移动钱包安全应围绕“密钥不外泄、签名可理解、链上可核验”建立闭环。客户端层面要控制组件暴露、深链输入、本地存储、日志、备份和网络信任；交易层面要解析 calldata、区分转账与授权、识别无限额度和 EIP-712 签名；链上层面要核对回执、事件、合约代码、代理关系和授权状态。
最有效的实践不是记住某个风险标签，而是每次操作都能回答：在哪条链上、与哪个合约交互、调用什么函数、谁获得什么权限、权限能持续多久、最终状态如何从链上独立验证。把这套流程固化到钱包界面、测试用例和日常使用习惯中，才能真正降低移动端加密资产的操作风险。
