客户有个岗位，每天要在三个后台系统之间复制粘贴数据。一天两百次。他们最初的方案是做一个中台系统对接，预算几十万，周期半年。我们说先做个插件试试，两周做完。
什么场景适合插件
插件最适合的场景是：在别人家的网页上做重复操作、并且对方不提供接口。比如批量录入与格式转换以及页面信息提取跟跨系统对账。这类需求做系统成本高，做插件刚刚好。反过来，如果要处理的数据量大、要长期存储以及多人协作，那还是得做系统。
插件适合做前端那一层，不适合承载核心业务逻辑。一是页面结构会变。对方改版，你的插件选择器就失效了。所以要写得容错一些，关键节点找不到时给出提示，而不是崩掉。这一条比功能多少重要。
开发上要注意三件事
二是权限要申请得克制。插件申请的权限越多，安装时的提示越吓人，用户越不敢装。只申请真正需要的，能显著提升安装率。三是数据不要外传。涉及业务数据的插件，最好做成纯本地处理，不上传服务器。这既是合规要求，也是让客户放心的前提。能不能先看效果？谁来当裁判？
上应用商店审核周期长，而且政策变化频繁。内部使用的插件可以不发布，用开发者模式加载，或者打包成企业内部分发。这两种方式各有各的限制，要提前确认。那个客户末尾用的是内部分发，装了二十台机器。
分发比开发更麻烦
原来一天两百次的复制粘贴，现在点一下按钮就完成。省下的时间不算多惊人。但人不用再对着屏幕搬数据了。再点一句：不是所有问题都要用系统解决。有时候一个小插件，成本低、见效快，反而更合适。
浏览器插件开发的常见疑问
什么需求适合做插件
在第三方网页上做重复操作且对方无接口的场景，如批量录入、信息提取和格式转换。
插件容易失效吗
对方页面改版可能导致选择器失效，开发时应做容错处理并在异常时给出提示。
插件怎么分发
可上应用商店审核发布，也可内部打包分发或开发者模式加载，各有政策限制需提前确认。
维护上建议留个开关。插件出问题时能一键停用，业务不至于卡死。这个小设计在出故障那天会显得特别有用，成本几乎为零。
总结：插件适合解决小而烦的重复劳动。成本低、见效快，但要写好容错与权限。