Selenium在Chrome中自动化仅IE兼容网页的可行性咨询

能不能成根本不看页面视觉上是不是布局乱，核心看两点：你要操作的DOM节点能不能正常访问、网页核心逻辑是不是强依赖IE专属特性，实际可以按下面的情况判断：

• 完全可以用Chrome headless+Selenium的场景：如果布局错乱只是CSS兼容问题导致的——比如写了旧IE专属的盒模型hack、用了只有IE支持的CSS滤镜、非标准的浮动/定位写法Chrome不认——但你要操作的输入框、按钮、表单这些目标元素，在Chrome的DOM树里能正常搜到，元素没被设成禁用、也没被全局透明遮罩挡住点击，那直接用就行。

  别把视觉布局正常和功能可交互划等号。Selenium常规的元素交互底层是直接调浏览器DOM接口的，和页面长什么样没关系。哪怕元素视觉上飞到屏幕外面、样式歪到认不出来，只要DOM节点存在、状态正常，click()、send_keys()这些标准方法都能正常跑，根本不需要页面“看起来没问题”。

• 用不了Chrome headless的场景：如果网页核心功能绑死了IE独有的API，比如要调ActiveXObject控件、嵌了VBScript脚本、依赖旧版IE的非标准事件模型或者DOM属性，那Chrome打开不光布局乱，核心业务逻辑直接就报错，这种情况肯定没法用Chrome驱动跑自动化。
• 实操避坑：
  1. 别上来就写完整脚本，先开普通版Chrome打开目标页，按F12开开发者工具，用元素选择器搜你要操作的节点，确认节点存在、没有禁用、没有遮罩拦截之后，写几行测试代码跑下点击、输入，能跑通就直接上headless模式写全量逻辑，不用管布局歪不歪。
  2. 写脚本的时候绝对别用基于屏幕坐标的点击、拖拽逻辑，这种完全靠视觉位置找元素，布局一乱百分百失效，统一用id、name、XPath这类DOM定位方式找元素就稳。
  3. 要是测下来发现核心逻辑在Chrome里直接跑不通，就换支持IE内核的headless驱动对接Selenium，没必要死磕Chrome。

内容的提问来源于stack exchange，提问作者LSTanaka