仅供教育参考，不构成投资建议；投资可能产生损失。
直接答案
已启用的模块是一条独立授权路径。在 Safe 风格的智能账户中，获准模块可调用 execTransactionFromModule，在不为该操作收集常规 M-of-N Owner 签名的情况下执行 CALL 或 DELEGATECALL。因此，界面显示的 Owner 阈值只描述一条执行路径，并非账户的完整安全边界。
模块可支持限额、定期付款、恢复和协议操作等实用自动化。但其权限可能很广：Safe 官方合约说明已启用模块可以执行任意交易，并警告恶意模块可能接管 Safe。审查时必须检查每个已启用模块，不能只看 Owner 和阈值。
工作机制
Owner 首先通过常规 Safe 交易授权 enableModule，账户随后将模块写入已启用模块注册表。之后，该模块自行验证调用者及规则，再调用 execTransactionFromModule；账户确认调用方确实已启用后执行请求的操作。此时，安全性还取决于模块代码、配置、管理员、升级密钥和外部依赖。
交易 Guard 和 Module Guard 是两种不同的控制。交易 Guard 检查常规 execTransaction 调用，Module Guard 则检查模块发起的调用。Guard 可以拒绝执行，但故障或过度限制的 Guard 也可能造成拒绝服务。应确认安装了哪种 Guard、它检查什么，以及如何恢复或移除。
Fallback Handler 是另一扩展点。当 calldata 与账户核心函数均不匹配时，账户会将调用转发给配置的 Handler，并在 calldata 后附加原始调用者地址。Handler 可增加签名验证和代币回调，但不安全的逻辑或配置也会新增权限与解析攻击面。
示例
某金库采用 3-of-5 Owner 阈值，并启用额度模块处理日常付款。该额度模块可以升级，而升级管理员是单个热钱包。如果该密钥被盗，攻击者可能升级模块、调用模块执行路径，并在未取得 3 个 Owner 签名时转走金库资产。3-of-5 阈值本身未被更改，但不约束这条路径。
审查应识别模块地址及已验证实现、代理与管理员、支出上限、允许的目标和函数选择器、是否允许 DELEGATECALL、已安装的 Module Guard、Fallback Handler，以及禁用模块所需的确切交易。每条部署链都应从账户合约和相关代理合约核验这些值，不能只依赖钱包界面。
风险
- 权限风险： 有漏洞或恶意模块可能转移资产、授权 spender、通过
DELEGATECALL改变账户状态，或调用其他特权合约。功能受限的界面并不能证明链上权限同样受限。 - 控制与升级风险： 模块代理、管理员、预言机、自动执行者或恢复密钥，可能让表面上的 3-of-5 安排实际只由更少主体控制。应追踪每条升级与配置路径，直到最终签名者和时间延迟。
- 可用性风险： 故障 Guard 可能阻止有效交易，而被攻陷模块的行动速度可能快于 Owner 协调移除的速度。应测试禁用与恢复流程，监控模块、Guard 和 Handler 变更，并保留不依赖待移除组件的响应路径。
常见误区
- 误区 1：“账户是 3-of-5，所以每笔转账都要 3 个签名。” 阈值适用于常规 Owner 授权路径；已启用模块可以使用不同的授权策略。
- 误区 2：“一个 Guard 会保护所有执行路径。” 常规交易 Guard 与 Module Guard 覆盖不同入口，实际覆盖范围取决于已安装合约及其规则。
- 误区 3：“在界面移除模块就消除了风险。” 应在账户存在的每条链上核对链上已启用模块注册表、Handler 和 Guard 存储、代理实现及已发出的变更交易。
相关主题
来源
- Safe 模块 - Safe Ecosystem Foundation（查阅日期：2026-08-21）
- Safe Guard - Safe Ecosystem Foundation（查阅日期：2026-08-21）
- Safe Fallback Handler - Safe Ecosystem Foundation（查阅日期：2026-08-21）
- ModuleManager.sol - Safe Ecosystem Foundation（查阅日期：2026-08-21）