写一个原生 JS 分享插件时，我会先限制它对全局的影响

写前端小插件最容易带来的错觉，就是“东西很小，怎么写都行”。尤其做分享按钮、浮层、复制链接这类轻量功能时，很多实现一开始都很快：挂几个全局变量、塞一段样式、暴露一个初始化函数，页面立刻就能用。

可 2019 年前后我自己做这类插件越来越多之后，反而最先关心的不是功能，而是它会不会把宿主页面搞脏。

我最先约束的是全局命名

一个小插件如果默认就往 window 上挂很多对象，短期很方便，长期就很危险。
宿主页面可能已经有同名变量，也可能同时加载多个脚本。这个时候“我只是随手挂一下”就会变成污染来源。

所以我现在更偏向只暴露一个尽量稳定、语义明确的入口，甚至能不暴露就不暴露，把内部状态都收在闭包或者实例里。

第二个边界是样式

插件写出来之后最容易忽略的不是逻辑，而是样式渗透。
如果按钮类名太普通、弹层样式选择器太宽，宿主页面原本的 CSS 就可能被意外影响，反过来也一样，页面自身样式也会把插件弄得面目全非。

这就是为什么我后来越来越愿意给插件样式做前缀隔离，哪怕多写一点名字，也比后续冲突轻松。

第三个边界是事件

分享插件看似简单，但常常会监听点击、关闭、滚动、复制等行为。
如果事件绑定和解绑不干净，页面切换几次之后，很容易出现重复触发、状态残留、弹层莫名其妙多开的问题。

所以我更愿意把事件生命周期当成插件设计的一部分，而不是补丁。

为什么我现在不再觉得“小插件可以随便写”

因为插件的价值，本来就是“在别人的页面里安全工作”。
一旦它只能在作者自己熟悉的那张页面上稳定运行，就不能算成熟插件，只能算局部脚本。

约束全局影响，本质上是在尊重宿主环境。

小结

原生 JS 插件真正难的，从来不是按钮能不能点，而是它在任何页面里能不能礼貌地存在。
2019 年之后我对前端插件的要求越来越简单：功能可以轻，但对全局的影响必须小。做到这一点，插件才真的可复用。