先区分术语所处的层次
JavaScript 区块链项目可能同时涉及浏览器接口和链上合约。阅读文档时，首先要判断术语描述的是密码学操作、密钥对象，还是某项功能的调用权限。这几类概念可以在同一应用中配合，但各自解决的问题不同。本文聚焦 Web Crypto API 与 OpenZeppelin 合约权限机制，相关解释不代表某个具体项目的实现。
Crypto、SubtleCrypto 与 CryptoKey
MDN 的 Web Crypto API 文档将 Crypto 描述为提供密码学随机数及底层密码学功能入口的接口；通过 crypto.subtle 可以访问 SubtleCrypto，进行密钥生成、加密、解密等操作。CryptoKey 则表示通过生成、导入或派生等方式获得的密钥对象。相关功能通常要求 HTTPS 等安全上下文，也可用于 Web Workers。
理解这些名称时，可以分别把它们看成能力入口、操作接口和操作所需的对象。看到 CryptoKey，并不能据此判断它对应哪个链上账户；看到应用调用密码学接口，也不能直接推断整个应用已经安全。接口调用、密钥管理和系统设计仍是不同的问题。
Ownable 与角色权限
OpenZeppelin 的访问控制文档介绍了两种机制：Ownable 用所有者身份限制管理操作，onlyOwner 表示相应函数受所有者检查保护；AccessControl 则以角色划分权限，onlyRole 用于检查调用者是否拥有指定角色。角色的持有者与角色的管理员可以不同，拥有某项操作权限并不自动意味着能够向别人授予该权限。
单一管理身份的场景较容易用所有权模型表达；需要区分多种职责时，角色模型更便于描述。理解权限时，应分别追问谁能执行功能、谁能改变授权关系。例如，能执行某项业务操作与能管理该操作的授权名单，是两种职责。
常见问题：前端能力等于合约权限吗
两者不能直接画等号。浏览器密码学接口提供计算能力，合约访问控制则依据合约规则判断调用资格。前端显示一个管理按钮，并不足以说明当前账户能够通过合约的权限检查。
另一个常见误区是把 Solidity 中的 onlyOwner、onlyRole 当作 JavaScript 语法。它们属于合约侧的权限机制；阅读 JavaScript 项目时，应同时辨认界面代码与合约规则的边界。分析具体功能，需要查看它实际采用的身份检查与授权关系，不能仅凭函数名称或页面提示得出结论。