我是在2019年才第一次碰Selenium。那时候项目组急着做自动化，一个从硅谷回来的架构师拍板选了Selenium，理由是团队里有人会Java。结果那个人跑路了，留给我一个连driver都起不来的代码库，我足足花了两天才知道是chromedriver版本不匹配。
客观说，Playwright那种内置自动等待、trace viewer、多标签页隔离确实比Selenium的webdriver好用一个时代。但你不能忽略一个事实：Selenium靠的是W3C的WebDriver协议，是一个公开标准，而Playwright以及Cypress全是把自己绑死在Chromium DevTools Protocol上。换句话说，哪天微软或Google把CDP私有化，这些工具就得跪着求人家。我这不是杞人忧天，你去看看Selenium 4花了多少年才把w3c的漏洞补齐。
我也不是老顽固。我在本地用Playwright写过一个爬虫，那叫一个爽，直接看瀑布图。但一放到公司那台只能跑IE11的虚拟机上，Playwright直接罢工。你能怎么办？你为了一个测试用例去给客户升级浏览器？人家采购部说，我们跟XX银行签了协议，只能IE。这时候只有Selenium能救你，因为WebDriver规范本身在设计上就考虑了这些老掉牙的浏览器。
说到等待，这是Selenium的世纪难题。显式等待和隐式等待混用会导致随机超时，我踩过不少坑。后来我干脆只用一个显式等待的封装函数，把sleep全部干掉。Playwright的自动等待看起来智能，但有时候它以为页面加载完了，其实某个按钮还没挂上事件。你就得用expect(locator).to_be_enabled()这种长链，反而把测试代码写成一篇散文。
所以我的观点是：如果从零开始，写一个新的Web项目，我建议你直接用Playwright或者Cypress，别折腾Selenium了。但如果你维护的是已经跑了五六年的老测试仓库，里面全是sleep(3)和该死的xpath跳转，那你千万别听人瞎鼓吹重构。重构的成本不是换API，而是重新理解业务逻辑。Selenium的API虽然笨，但它在设计上保留了最底层的控制力，那种糙的地方恰好是它的保险丝。
最后说一句，自动化测试的工具选择不是选美，而是选能让你在下班前跑完就跑的。Selenium就像那台老丰田，看着没牌面，但只要你肯花时间修，它就能一直开。那些笑它丑的人，往往连维护一套稳定测试的能力都没有。
