一个 NEAR 账户几把钥匙：全访问密钥与功能调用密钥的边界

一个账户可以挂几把钥匙

比特币和以太坊的直觉是”一个地址配一把私钥”。NEAR 把这件事反了过来：账户本身就是一张钥匙清单，可以同时挂多把公钥，钥匙可以随时增加或撤销。官方文档把清单上的钥匙分成两类——全访问密钥（Full-Access Key）和功能调用密钥（Function-Call Key），两类的安全边界完全不同，值得每个在 NEAR 上放过资产的人逐项核对。

全访问密钥顾名思义：能替你在这个账户里做任何事——转走 NEAR、删除账户或建子账户、增删其他密钥、部署合约、调用任意合约的方法。文档的态度也很直接：全访问密钥永远不要分享出去，交出去就等于交出账户的全部控制权。

功能调用密钥则被设计成”可以放心交给应用”的那一类。它有三个属性圈定边界：receiver_id 规定这把钥匙唯一可以调用的合约，其他合约一概调不动；method_names 可选，进一步把权限收到指定方法，省略则允许该合约全部方法；allowance 可选，规定这把钥匙最多能花多少燃气预算，省略则不限。另外它不能在调用时附带 NEAR 转账，也就是说，一个只拿功能调用密钥的程序，原则上花不走你账户里的本金，能烧掉的只有预算内的手续费。

预算怎么扣、钥匙怎么没

allowance 的扣费方式有个容易踩的细节：官方文档写明，allowance 按”买价”预扣，等链上燃气退款到账时再把多扣的部分记回钥匙余额，所以预算面值要大于你预估的实际成本，留足余量，否则调用会因为预算不足而失败。钥匙的燃气从它自己的预付余额里付，退款也回到钥匙本身——这正是文档”Gas Key 如何通过 nonce lanes 付账”一节解释的结构：不同钥匙各自有交易序号车道，互不排队堵塞，应用可以放心地为后台任务自动签交易。

由此引出一个真正危险的状态：如果一个账户只剩下功能调用密钥，而预算又被花光，账户就从内部锁死——没有全访问密钥在手，谁也无法主动发起任何交易把它”救活”，包括转走残值。文档专门列了”账户与锁定”的章节讨论这类受限访问密钥的注意事项。日常的操作口径因此是清晰的：全访问密钥留在钱包或硬件里，功能调用密钥授权给应用，撤销授权就是把那把钥匙从清单上删掉，而删除动作本身必须动用一把全访问密钥完成。

两把钥匙弄丢的后果也完全不对称，值得在授权前多想一步。丢的若是全访问密钥，账户的处置权随之旁落，拿到它的人能转走余额、删掉你其余的钥匙；丢的若只是一把功能调用密钥，损失上限被 receiver_id 与 allowance 两重圈笼住——对方只能对那个指定合约发起调用，最多烧掉预算内的手续费。授权的对象越可信，预算可以给得越松；对没审计过的小应用，宁可留一把”小额、限方法、随时删”的钥匙，也不要图省事把全访问密钥交出去。

授权之前查什么

把这套模型翻译成可复核的检查清单：在钱包或资源管理器里查看账户的完整密钥列表，看清每一把的类型；功能调用密钥逐一核对 receiver_id 是否是你认识的合约、method_names 有没有省略、allowance 剩余额度与你的预期是否一致；对长期挂着的授权钥匙，考虑补一把小额预算的新钥匙替代大预算旧钥匙。要区分三种状态——链上密钥列表是真的、应用当前报价是旧的、以及钱包界面显示的”已连接”，都不等于”这把钥匙花了多少、还能花多少”的答案，后两者要在链上查。

提示：本文按 NEAR 官方文档口径描述密钥模型，具体字段与行为可能随版本演进，以最新官方文档为准；密钥授权本身不消除合约漏洞与私钥泄露风险，文中内容不构成投资建议。