首页 / 资讯中心 / 文章详情

IE浏览器加载项实战:选型、32位陷阱与排查维护

IE浏览器加载项实战:选型、32位陷阱与排查维护 ★ FEATURED ARTICLE
“IE浏览器”这四个字现在提起来多半人先笑一声都什么年代了还用它。但只要你待过需要跑内网业务系统的岗位就明白这不是情怀是绕不过去的现实——某个审批系统只认它某个证书控件只在它里面跑得动某个打印模板换个内核就错位。这篇就聊插件更准确的说法是加载项分享几类我这些年真正留在机器上、确实省过事的插件也把装完之后容易翻车的地方一并交代清楚。适合两类人看被老系统绑在 IE 上的一线用户以及要给一批机器做统一配置的运维。不聊虚的只讲每类加载项解决什么问题、装在哪、怎么管、出问题怎么一步步查。1. 还在开IE的人到底在等什么先把使用场景说清楚因为场景决定了你该装什么、不该装什么。很多人对 IE 插件的第一印象还停留在十几年前那种铺满工具栏的搜索条和天气条那批东西确实是历史包袱。但今天仍然需要加载项的场合基本都是硬需求跟怀旧毫无关系。理解这一点后面挑选加载项时你就不会乱装。1.1 三个绕不开的现实场景第一类是内网业务系统。不少单位的管理系统开发年份早前端用了大量 ActiveX 控件比如身份证读卡器、高拍仪、票据打印机、指纹仪这些硬件厂商提供的驱动和控件基本只提供 32 位 IE 的调用接口。这类系统换内核不是改个配置的事是整个前端要重写所以短期内只能继续用 IE 跑。第二类是证书与密钥类操作。各种 UKey、数字证书中间件在安装后会往系统里注册一个或多个浏览器辅助对象用来和硬件做通信。这类加载项的特点是装完之后你在浏览器里看不到任何图标但它一旦没起来页面就会卡在正在检测证书环境那一步转圈。第三类是老旧页面的渲染兼容。有些页面用了大量只在 IE 里成立的非标准写法比如document.all、VML 图形、条件注释、filter滤镜。换到新内核不是显示错位就是脚本直接报错。这类场景下需要的不是修页面而是一个能把页面塞回旧渲染引擎的通道。注意这三类场景对加载项的要求完全不同。第一类要的是控件权限放行第二类要的是中间件正确注册第三类要的是渲染通道。搞混了方向你会一直在错误的地方折腾。1.2 加载项、BHO、ActiveX术语先对齐IE 里的插件在官方语境下统称加载项但它底下分好几种机制差别很大管理方式也不一样。搞清楚分类你排查问题时才知道该去哪个入口看。类型官方叫法典型用途出问题的表现浏览器辅助对象Browser Helper Object证书通信、页面注入、行为拦截页面卡在检测环节、浏览器启动变慢工具栏与扩展Toolbar and Extensions增加按钮、菜单、侧边栏工具栏空白、按钮点不动ActiveX 控件ActiveX Control调用本地硬件、打印、读写本地文件页面提示未安装控件、控件区域空白搜索提供程序Search Provider地址栏搜索地址栏跳转到奇怪页面加速器Accelerator选中文字后右键调用外部服务右键菜单多出无用条目BHO 本质上是一个实现了特定接口的 DLL浏览器启动时会把它加载进自己的进程空间所以它和浏览器是同一生死。这也解释了一个常见现象某个证书控件没装好表现出来不是控件不可用而是整个浏览器启动慢好几秒甚至直接闪退因为 DLL 在加载阶段就出错了。ActiveX 控件则是页面通过object标签按需拉起的它有自己的注册表登记和版本号权限受安全区域控制。所以你会发现同一个控件在 A 网站能用、在 B 网站不能用多半不是控件的问题是 B 网站没被加进可信站点。1.3 为什么老加载项会让浏览器越用越慢这一点值得单独说因为它直接决定了后面我怎么给加载项做取舍。IE 从 8 之后采用了松散耦合的进程模型一个标签页大致对应一个进程但加载项默认是每个进程都要加载一遍的。也就是说你装了 10 个 BHO开 5 个标签理论上就有 50 次加载动作。单个 BHO 初始化花 100 毫秒不算多叠起来就是半秒起步而这还只是初始化不含后续的钩子开销。我在一台老机器上做过对照纯净状态下冷启动到一个空白页约 1.2 秒装完一套业务必需的证书中间件加打印控件后升到 2.6 秒左右再多挂两个来路不明的工具栏直接飙到 4 秒以上而且切换标签时有明显顿挫。这个量级的变化用户是能明确感知到的反馈到运维那里就变成电脑太卡了。所以我的原则很明确加载项按业务必需和顺手好用两档管理第一档无条件保留第二档严格控制数量来路不明的坚决不装。下面推荐的都属于这两档之内的东西而且我给的都是类别和判断标准具体厂商你得按自己单位的采购和授权情况来选。2. 按活儿挑五类值得留在机器上的加载项我不打算报一串名字让你照抄因为同名插件版本差异极大而且很多老插件的维护状态早就停了。更有用的是告诉你哪一类活儿该找哪一类加载项以及每类在装的时候要盯住什么。这样即便换了单位、换了系统你照样能自己判断。2.1 文档直读类把跳出浏览器的动作收回页面里内网系统里最高频的操作之一就是看附件PDF、Word、Excel、扫描件图片。默认情况下点击附件要么弹下载框要么调用本地阅读器另开一个窗口一来一回切换窗口非常影响效率尤其是要连续核对十几份材料的时候。文档直读类加载项的作用就是把阅读器嵌进页面点开就在当前标签里翻页。选这类加载项有三个硬指标一是必须支持页面内连续滚动而不是一页一个弹窗二是要能正确处理中文文件名和超长路径很多老控件在这里翻车文件名一长就报文件不存在三是要看它是否会预读整份文件如果是几十兆的扫描件预读会让页面卡住好几秒好的实现是分页拉取。这里有个我踩过的坑某次装完一个直读控件后所有 PDF 都能在页面里开了但打印出来页码顺序是乱的。查了半天发现是控件自带的打印模块和系统打印驱动的纸张设置冲突把控件设置里的使用浏览器打印勾上就正常了。所以装完这类控件别只看能不能打开一定要实际打一份出来核对页序和页边距这是最容易漏掉的验证环节。2.2 证书与UKey中间件看不见但最要命的一类这类加载项是内网办公的命门。它平时完全不可见一旦出问题整个业务流程就断在那里。中间件通常由硬件厂商提供安装时会做三件事装驱动、注册一个或多个 BHO、在系统证书存储区写入根证书。判断它是否装好我一般按这个顺序看先看设备管理器里有没有未识别设备再看系统服务里对应服务是否在运行然后打开 IE 的管理加载项列表确认 BHO 处于已启用状态最后才是打开业务页面实测。这个顺序的好处是能快速定位问题出在哪一层——很多人一上来就重装中间件其实问题只是服务没起来。还有一点是多版本共存。单位里往往同时存在好几家厂商的密钥设备各自的中间件都往浏览器里塞 BHO。这时候常见现象是单独插任何一个都能用两个同时插就都读不出来。原因是它们抢同一个通信端口或者互相覆盖了同名的组件注册。我的处理办法是给不同业务配不同的浏览器快捷方式用启动参数隔离配置或者干脆分成两个虚拟机环境。这个方案听起来笨但比反复折腾兼容性要省时间得多。注意中间件装完后建议立刻做一次系统还原点或镜像快照。这类软件写注册表非常深卸载经常卸不干净出问题时回滚比修复快得多。2.3 渲染切换类给老页面留一条后路这类加载项解决的是页面必须用旧引擎渲染但我不想专门开一个浏览器的矛盾。它有两种形态一种装在新内核浏览器里遇到指定域名时自动切换到旧引擎渲染另一种装在 IE 里反过来用新引擎渲染某些现代页面。前一种更常用。配置方式通常是维护一份域名清单命中清单的地址走旧引擎其余走新引擎。这份清单要写得很具体别图省事写整个内网域名段否则会把本来能正常显示的新系统也拖回旧引擎反而更慢。判断某个页面到底需不需要切我的方法是先在新内核里打开按 F12 看控制台有没有脚本报错、看布局有没有明显错位。如果只是个别样式错乱多半是 CSS 写法问题不值得为它切引擎如果报错涉及document.all、attachEvent这类老接口或者页面用了 VML 画图那就老老实实加进清单。这套方案有个前提条件目标系统不能依赖硬件控件。因为切到新引擎后ActiveX 是被禁用的。所以第 2.1 到 2.2 节讲的那类场景渲染切换救不了只能老老实实用 IE。2.4 调试与抓包类出问题时能自救的工具严格说这不算日常好用但属于关键时刻救命。内网系统出问题时业务方只会说打不开你得自己找证据。IE 自带的开发者工具F12已经够用一大半网络面板看请求状态码和耗时控制台看脚本报错DOM 面板看控件有没有真的被创建出来。F12 之外我还常备一个本地代理类工具用来抓完整的请求响应。它的价值在于能看到 IE 发出去了什么、服务端回了什么尤其是那些页面提示很含糊的场景。举个典型例子页面一直提示请检查控件是否安装抓包一看请求根本没发出去说明是前端脚本在检测阶段就中断了跟服务端一点关系没有。这个判断能把排查范围从全链路缩到本地环境省下大量沟通成本。配置这类工具要注意两点一是要给它装上自己的根证书否则 HTTPS 请求全是加密的看不懂二是抓完记得关掉代理设置忘了关就会表现为整台机器都上不了网这个乌龙我见过不止一次。2.5 表单与打印类琐碎但高频的效率点内网系统里录入量大、字段多、还要打各种固定格式单据的场景非常多。这类加载项主要干三件事记住常用字段值做快速填充、把页面上零散的信息一键复制成规整格式、以及把页面内容按模板套打成指定版式的单据。打印控件这里要多说一句因为它是最容易出兼容问题的。业务系统通常要求按固定纸张和固定边距输出而浏览器自带的打印会受页边距、缩放比例、页眉页脚开关影响。老式打印控件一般通过直接调用系统打印接口来绕过这些好处是版式稳定坏处是它的纸张设置和打印机驱动设置容易打架。我遇到过打印出来整体偏移两毫米的情况最后是打印机驱动里的无边距选项和控件里的纸张定义冲突关掉驱动那边的缩放就好了。装了打印控件之后我的验收清单是连续打三张检查第一张和第三张的版式是否一致换一台不同型号的打印机再打一次最后把页面缩放调到 100%、125%、150% 各打一次。三关都过这个控件才算能交付给业务方用。3. 装上不等于生效加载项的三处开关与位数陷阱这一段是我最想强调的。装完插件不能用八成不是插件坏了而是某个开关没打开或者选错了浏览器版本。这两件事占了这类问题的绝大多数而且都有明确的检查路径根本不用重装。3.1 三处入口的分工别只认一个IE 里管加载项的地方不止一处各自管的东西不一样混着找会浪费很多时间。第一处是工具菜单里的管理加载项这是最直观的入口能看到已启用的列表、发行者、加载用时还能直接禁用。排查性能问题优先看这里因为它会显示每个加载项的加载耗时谁的耗时长一目了然。第二处是Internet 选项里的安全设置这里管的是 ActiveX 能不能运行、能不能下载、能不能执行脚本。前面说过同一个控件在不同网站表现不同本质就是这里的区域策略在起作用。第三处是注册表这里是真相所在。管理加载项列表里看到的是登记过的而注册表里能看到 CLSID 到 DLL 路径的映射关系。有时候列表里显示已启用但实际 DLL 文件已经被删了这时候浏览器启动就会报错或者静默失败只有去注册表核对路径才能发现。用命令行快速核对 BHO 注册情况我一般这么查reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects /s reg query HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects /s两条都要查因为有些中间件装到当前用户下有些装到全局。查出来是一串 CLSID再逐个去HKCR\CLSID\{GUID}\InprocServer32下面看对应的 DLL 路径是否存在。这个动作看着笨但它是唯一能确认注册了但文件没了这种状态的方法。3.2 32位与64位这条分水岭很多人栽在上面在 64 位系统上默认点开的 IE 其实是 32 位版本路径在Program Files (x86)下面。原因是绝大多数 ActiveX 控件只编译了 32 位版本为了兼容性系统默认走 32 位。问题在于如果某天你从所有程序里手动找到并打开了 64 位那个 iexplore.exe那么所有 32 位控件全部失效页面会齐刷刷提示控件未安装。这时候你会以为是控件坏了其实只是打开方式不对。反过来也有坑有些单位为了跑某个大型页面特意要求用 64 位浏览器那对应的控件就必须是 64 位版本而厂商很可能只提供了 32 位。这种情况下没有技巧只能去找厂商要 64 位版本或者退回 32 位使用。我的固定做法是给业务系统建一个固定的快捷方式目标明确写死为 32 位那个可执行文件路径并在备注里写清楚业务专用勿改。批量部署时也是统一发这个快捷方式避免用户自己从开始菜单乱点。3.3 安全区与ActiveX放行的正确姿势ActiveX 被拦是最高频的报障。默认的安全级别下控件下载和运行基本都被禁。放行有几种做法安全性差别很大我按推荐程度排一下。最稳妥的是把业务系统域名加进受信任的站点然后只在受信任站点区域里放宽 ActiveX 相关设置。这样影响范围被限定在这几个域名内其他网站还是默认的严格策略。次一等是全局降低 Internet 区域的安全级别。这个做法在很多单位流传很广因为一次设置全部搞定但它等于把整台机器的浏览安全都拉低了我不推荐尤其是在还需要用这台机器处理其他事务的情况下。最不推荐的是在页面提示时点允许并勾选不再询问。这样确实能过但用户根本不知道自己放行了什么而且这种放行和具体控件绑定换个控件又要重来维护起来一团乱。设置路径是 Internet 选项里的安全选项卡选中受信任的站点点站点按钮添加域名。这里有个细节添加时要不要勾选要求服务器验证取决于内网服务器用的是不是正式证书。如果内网是自己签发的证书勾上这个选项会导致站点加不进去或者加了也生效不了这时候只能取消勾选。注意改完安全设置后最好关掉所有 IE 窗口再重开让策略重新加载。有些设置在已打开的标签页里不会立即生效会出现改了没用的错觉。4. 装完变慢、白屏、崩溃一条能复现的排查链加载项相关的问题最怕的是没有排查次序东试一下西试一下最后靠重装系统收场。我整理了一条自己一直在用的链路核心思路是先确定是不是加载项的问题再确定是哪一个最后确定是它的哪一部分。这条链路的好处是每一步都有明确的判断依据不靠猜。4.1 冷启动变慢先把变量摘干净第一步是确认慢跟加载项有关。做法很简单用不带加载项的启动方式开一次浏览器对比启动耗时。如果差异明显方向就定了。确认有关之后用二分法缩小范围。不要一个个试太慢。先禁用一半看是否恢复恢复了说明问题在禁用那一半里再对半切。十个加载项最多四轮就能锁定比逐个试快得多。锁定之后别急着卸载先看它的加载耗时数据。管理加载项列表里会显示每个项的加载时间如果某个项单独就吃掉三百毫秒以上那它本身就值得质疑可以去找有没有轻量替代方案。还有一种情况是单个都不慢加起来才慢。这时候要看是不是有多个加载项在启动阶段都去读同一个资源比如都去枚举系统证书、都去检测同一批硬件设备。这种撞车在多个厂商中间件共存时特别常见。处理方式还是隔离把不同业务分到不同的浏览器配置或不同的虚拟环境里让它们不必同时加载。4.2 白屏与脚本错误的定位顺序白屏比变慢更难查因为没有任何提示。我的顺序是这样的先按 F12 打开控制台刷新页面看有没有红色报错。如果有报错信息里的文件名和行号往往直接指向某个加载项注入的脚本。这是最快的一条路能省掉后面所有步骤。如果没有报错就去网络面板看主文档请求是否成功。状态码 200 但内容为空说明是服务端返回了空页状态码 500 以上问题在服务端请求根本没发出去说明卡在本地。如果请求正常、内容也正常页面还是白的那就去看 DOM 结构确认body里到底有没有内容以及控件对应的object标签有没有被创建。有些控件在初始化失败时会静默吞掉异常页面结构在但内容全空这时候禁用该控件再刷新页面立刻恢复就锁定它了。还有一种白屏是只在特定操作后出现比如点了某个按钮之后白掉。这种情况多半是页面脚本和加载项注入的脚本冲突用 F12 的断点功能在按钮点击处停一下单步走过去能直接看到冲突发生在哪一行。4.3 卸载残留清不干净比不装还麻烦加载项卸载不干净是常态尤其是老控件。表现是程序列表里已经没了但浏览器启动还是会去加载那个 DLL于是每次都报一次错或者拖慢启动。清理分三层。第一层是管理加载项列表里把它禁用这一层只是不加载注册信息还在。第二层是注册表里删掉对应的 CLSID 项包括 BHO 列表里的条目和 CLSID 下的 InprocServer32。第三层是确认那个 DLL 文件本身是否还在以及是否有其他程序依赖它。动手前必须做备份reg export HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects bho_backup.reg删注册表这件事我的原则是只删能对应到具体 DLL 路径的项路径指向的文件已经不存在的优先删路径还在、文件也在的先查清楚是谁在用再决定。有些控件是多个业务共用的删了会影响别的系统。另外提醒一句用第三方清理工具批量扫注册表残留要谨慎。这类工具对 CLSID 的判断经常过于激进把还在用的组件当成残留清掉结果是修好了一个问题、引出三个新问题。手工核对虽然慢但可控。5. 老平台续命的组合拳与维护习惯到这一节把前面散落的东西收成一个可执行的整体方案。不同的使用强度配置思路差别挺大我按三种典型情况给方案另外说几条我自己的长期维护习惯。5.1 三种典型配置的取舍对比配置方案适用场景优点代价纯 IE 单环境只跑一个业务系统控件单一配置最简单问题最少无法应对多系统冲突安全性最低IE 加渲染切换清单既有老系统又有新系统一个浏览器覆盖两类页面需维护域名清单切换有学习成本多配置隔离快照或独立环境多个厂商控件必须共存彻底规避冲突可随时回滚占用资源多切换不够顺滑我的实际选择是第二种为主、第三种兜底。日常工作用带切换清单的浏览器遇到必须在同一台机器上跑多个互相冲突的控件时才开独立环境。这样大部分时间体验是顺的只在少数硬场景下付出额外成本。5.2 我自己的维护清单几条一直在用的习惯看着琐碎但确实少踩了很多坑。装任何加载项之前先建一个还原点。这一步花不了一分钟但能让你在出问题时敢于果断回滚而不是硬着头皮修。每装一个新加载项单独测一次启动耗时。我的标准是单个加载项带来的启动增量超过三百毫秒就要重新考虑超过五百毫秒基本就不装了除非业务强依赖。记录一份加载项清单写清楚每一项对应哪个业务、哪个厂商、什么版本、装在哪台机器上。这份清单在换机器、升级系统、排查冲突时价值极高比事后翻注册表猜要快得多。定期检查文件路径的有效性。前面提过注册了但文件没了这种状态它在浏览器里表现为莫名其妙的启动报错。每隔一段时间用前面那条命令扫一遍把路径失效的项清掉。升级前先在单台机器上验证。IE 相关的补丁和系统更新偶尔会改变安全区域策略的默认值一次更新之后所有 ActiveX 全被拦的情况我遇到过不止一次。批量推之前先找一台机器试能避免大面积返工。5.3 什么时候该放弃插件路线最后说个反向的判断。插件路线不是永远的答案有些信号出现时继续往里投入就是在浪费人力。信号一是厂商停止维护。如果你要装的控件厂商已经不再更新而且在新系统版本上装不上或者装上有明显异常那就该考虑改业务系统了越拖成本越高。信号二是为了兼容要不断降低整体安全设置。当放行一个控件需要把一大片区域的策略都放开时风险已经超出了控件本身带来的便利。信号三是同一台机器上冲突频繁。如果每周都要处理一次控件冲突说明这套方案的组织方式已经到极限了。这时候与其继续加隔离层不如推动业务方走一次前端改造把控件依赖换成标准的浏览器接口。这件事推起来慢但方向是对的。我个人的体会是插件这东西在 IE 上从来都是够用就好。真正让人省心的不是装了多少个而是装完之后你能清楚说出每一项的用途、来源和卸载方式。说不清楚的那就不该留在机器上。
阅读完成 · 觉得有帮助?
咨询建站