Frame 是面向 EVM 生态的开源桌面钱包，定位偏向专业用户。关于「Frame 被黑过吗」这个问题，需要从两个层面回答：项目方有没有发生过协议级安全事件；以及使用 Frame 的用户曾经因为哪些原因发生过资产损失。两者性质完全不同，本文逐一拆解。
项目方层面：是否有重大事故
截至本文写作时，Frame 项目方没有发生过钱包应用本体造成大规模用户资产损失的重大安全事件。这与它的开源透明、代码审计可见、社区高度参与有直接关系。所有版本的源码都在 GitHub 公开，签名核心逻辑被多家安全机构与社区独立审计过，公开的 issue 跟踪让漏洞响应过程足够透明。
这种开放态度，相对于一些「闭源 + 不公开审计」的钱包项目要可靠得多。习惯了 Binance 这类持牌交易所定期接受第三方审计的玩家，对 Frame 的透明度可以保持比较积极的判断，但「过去没出事」不等于「未来不会出事」，仍需保持基本警惕。
历史漏洞披露与响应
Frame 项目方在过去几年间披露过若干中低风险漏洞，包括早期版本的 IPC 通信认证不严、特定 DApp 注入字段被劫持、以及某次 Companion 扩展更新里 CSP 策略不严等问题。所有这些漏洞都在发现后短时间内修复，并在 GitHub Security Advisory 中公开了 CVE 编号与影响范围。
相比之下，行业里许多钱包项目对漏洞采取「内部修复不公开」的态度，反而让用户无法判断自己用的是不是已被攻击过的版本。Frame 的「公开 + 快速响应」模式是更负责任的做法。和 B安 公开披露 API 异常事件的做法逻辑一致：透明本身就是安全的一部分。
用户层面：常见的资产损失原因
Frame 用户公开报告过的资产损失，几乎全部不是钱包本体被黑，而是以下几类问题：第一，从仿冒 frame.sh 域名下载到了带木马的安装包；第二，把助记词写在了云笔记或聊天软件草稿里被同步泄露；第三，签名时没看清合约方法，授权了恶意的 setApprovalForAll；第四，使用了被劫持的 DApp 网页，把资金签给了攻击者地址。
这些事故的共同点是「人的环节出问题」，而不是「应用代码有 bug」。对从 必安 大额提现的玩家来说，意识到链上世界的核心风险在于自己每一次签名的判断质量，比纠结钱包本身被不被黑要重要得多。
攻击面分析
Frame 桌面端的攻击面主要包括：本地 Keystore 加密强度、Companion 扩展与桌面端的 IPC 通信认证、对外接的 RPC 节点的信任假设、硬件设备驱动层。Frame 在每一层都做了相对充分的工程实践，但任何一环都可以是潜在被攻击点。
从用户角度，能做的事情是：永远只从 frame.sh 下载并校验签名；使用硬件钱包做关键账户；尽量自建或使用可信 RPC 节点；保持桌面操作系统与浏览器的安全更新。和 BN交易所 上做大额操作时同时启用所有 2FA 一样，多一层防御就少一分概率。
与中心化交易所被盗的对比
中心化交易所历史上有过大量被盗事件（Mt.Gox、Coincheck、FTX 等），损失动辄几亿美元。自托管钱包应用本体被黑的案例则非常罕见，绝大多数事故都发生在用户操作层面。这并不是说自托管更安全，而是说「风险位置」不同：交易所是集中风险，自托管是分布在每个用户身上的风险。
长期看待 Frame 的安全性
Frame 至今没有「钱包本身被黑」的重大事故，但这不能成为放松警惕的理由。链上世界没有「绝对安全」的工具，只有「相对负责」的实践。把 Frame 与硬件钱包、可信节点、严格的签名审查习惯组合在一起，才是真正可靠的自托管之道。