第一次给扩展加权限，两种做法该怎么选

“这个按钮点下去没反应，第次是扩该选不是权限没给？”同事把笔记本转过来，屏幕上是展加做法一个刚装好的浏览器扩展，设置页里一排开关全是权限灰的。我问他：你是两种打算自己装来用，还是第次要发给部门十几个人一起用？他愣了一下，说这有区别吗。扩该选区别很大，展加做法而且从零开始做扩展权限，权限第一件事不是两种去查某个 API 怎么调，而是第次先判断自己站在哪条路上。

下面把两条常见路线并排摆出来：一条是扩该选个人自用、手动加载的展加做法路线；另一条是要发布、要给别人装的权限路线。两者的两种权限写法、申请时机、出问题的后果都不一样，选错了往往不是“多改几行代码”，而是整份清单要重做。

先分清是“本机加载”还是“要发布给别人装”

本机加载的做法，通常是在浏览器的扩展管理页打开开发者模式，选择“加载已解压的扩展”，指向本地文件夹。这条路线的特点是：清单文件里声明什么权限，加载时浏览器就认什么，改动后点一下刷新即可生效。适合自己写脚本、内部小工具、临时验证想法。

发布路线则要经过商店审核或企业统一分发。此时权限声明不只是给浏览器看的，也是给审核方和安装者看的。声明了却没用到的权限，可能被要求说明理由；该声明却没声明的权限，功能会直接失效，甚至在审核阶段被打回。所以从零开始做扩展权限看什么，第一条不是看文档里的权限列表有多长，而是看你的分发方式决定了你能“随手加”还是必须“逐条论证”。

选错的后果很具体：按自用思路写出来的清单，权限给得很宽，发到商店会被质疑；按发布思路过度精简，自己调试时又处处受限，反复改清单、反复重新加载，时间全耗在开关上。

权限写进清单，还是运行时再申请

第二条分岔在申请时机。一种是把权限直接写进清单的权限字段，安装时就一次性拿到；另一种是先在清单里留一个可选权限的占位，等用户真正触发某个功能时，再调用申请接口弹窗询问。

安装时声明的做法，胜在简单：代码里直接调用接口，不用处理“用户拒绝”的分支。适合权限与核心功能强绑定、且权限范围很窄的场景，比如只是读写自己扩展的存储。缺点是安装页会把权限列给用户看，范围一大就容易劝退。

运行时申请的做法，胜在克制：用户点“同步到表格”时才问要不要访问某个站点，拒绝也不影响其他功能。代价是每一处调用前都要检查授权状态，还要处理拒绝后的降级提示。写的时候多一层判断，用的时候少一分抵触。

这里的反例很典型：有人在自用阶段把主机权限写成通配，调试一路顺畅；等到要给别人装，才发现安装提示写着“可读取并更改你在所有网站上的数据”，测试同事直接不敢点。回头改成运行时申请，代码里十几处调用都要补上状态检查，工作量比最初老老实实按需申请大得多。

一张对照核对表，落笔前先过一遍

把两条路线的判断点整理成可以逐项打勾的清单，动手前花五分钟过一遍，比写完再返工划算：

一、分发对象是谁。只有自己，走本机加载；有第二个人要装，就按发布路线准备。
二、权限是否与核心功能强绑定。是，考虑安装时声明；否，优先运行时申请。
三、权限范围能否再收窄。把“所有网站”换成具体域名，把宽泛的接口换成更小的那一档，能收就收。
四、拒绝路径是否想过。运行时申请必须回答“用户点了拒绝，界面显示什么”。
五、清单改动后是否重新加载并复核安装提示。安装页展示的权限文案，就是别人对你的第一印象。
六、有没有留下说明。给团队用的扩展，在说明文档里写清每条权限对应哪个功能，后续维护的人不必靠猜。

这张表不解决具体接口怎么写，但能挡住最常见的返工。真正涉及账号、支付、企业内网分发的场景，权限策略往往还要走单位的软件管理流程，这时应找负责终端的同事或对应平台的官方文档确认，不要凭一篇教程拍板。

改不动的时候，先回到分发方式这一层

如果已经在两条路线之间来回改了几轮，越改越乱，建议停下来问一句：这个扩展最终是谁在用。答案若是“就我一个”，就别再为审核友好度牺牲调试效率；答案若是“要发出去”，就把安装时声明的那部分压到最小，其余全部改成触发时申请，并逐条补上拒绝后的提示。

从零开始做扩展权限，难点不在记住多少个权限名，而在先给自己的项目定性。定性清楚了，清单里写什么、什么时候弹窗、被拒绝后怎么收场，都是顺下来的事。反过来，定性含糊，权限就会一会儿给多、一会儿给少，最后既不好用，也不好看。