1. 项目概述为什么我们需要一个替代 SeleniumLibrary 的方案如果你和我一样在自动化测试领域摸爬滚打了几年尤其是在 Robot Framework 这个生态里那么对 SeleniumLibrary 这个名字一定不会陌生。它几乎是 Robot Framework 做 Web 自动化测试的代名词稳定、成熟、社区庞大。但最近一两年我身边越来越多的团队开始把目光投向一个新的组合Robot Framework Browser Library其底层驱动正是微软开源的 Playwright。这绝不仅仅是为了追逐技术潮流而是我们在实际项目中尤其是在追求更高执行效率、更稳定测试环境和更现代化浏览器交互时真切地感受到了 SeleniumLibrary 在某些场景下的力不从心。SeleniumLibrary 基于 Selenium WebDriver这套架构已经服务了我们很多年。它的核心工作模式是通过浏览器厂商提供的驱动程序如 ChromeDriver、geckodriver与浏览器通信。这个模式本身没问题但问题出在“通信”这个环节。WebDriver 协议是标准但不同浏览器的驱动实现质量、与浏览器版本的兼容性常常成为我们维护测试脚本的噩梦。你是否也经历过因为 Chrome 自动更新了一个小版本导致整个测试套件大面积失败然后不得不花半天时间去找一个匹配的 ChromeDriver或者是在处理一些复杂的现代 Web 应用比如大量使用 Shadow DOM、WebSocket、Service Worker时发现某些操作就是无法稳定执行需要写大量丑陋的等待和重试逻辑Browser Library 的出现正是为了解决这些痛点。它基于 Playwright而 Playwright 采用了完全不同的思路它直接与浏览器的调试协议如 Chrome DevTools Protocol通信绕过了 WebDriver。这意味着它天生就与浏览器内核版本绑定得更紧密支持的功能也更底层、更强大。对于 Robot Framework 用户来说Browser Library 提供了一套全新的、更符合现代 Web 自动化需求的“方言”。它不仅仅是 SeleniumLibrary 的平替更像是一次全面的升级。在接下来的内容里我会结合我近期的迁移和实践经验详细拆解为什么它是更好的选择以及如何从零开始上手并避开那些我踩过的坑。2. 核心需求解析从 SeleniumLibrary 迁移到 Browser Library 的驱动力决定更换一个团队已经熟悉且稳定运行多年的技术栈绝不是一件小事。这背后一定有强烈的驱动力和明确的收益预期。从我主导的几次迁移经验来看推动我们转向 Browser Library 的需求主要集中在以下几个方面这些也是你在评估是否迁移时需要重点考量的。2.1 对稳定性和执行速度的极致追求这是最直接、也最普遍的诉求。Selenium 通过 WebDriver 与浏览器通信存在额外的进程间通信开销。而 Playwright 通过 CDP 等协议直接与浏览器内核对话通信路径更短指令执行更快。在实际的批量测试中这种速度差异会被放大可能带来 20%-50% 的整体执行时间缩短。更重要的是稳定性。WebDriver 的兼容性问题是个“玄学”特别是当测试环境需要同时支持 Chrome、Firefox、Edge 多个浏览器时维护不同版本的驱动成了持续性的负担。Playwright 在安装时会直接下载与其版本严格匹配的浏览器二进制文件形成了一个“已知良好”的捆绑环境。这意味着只要 Playwright 版本不变测试行为就是完全可复现的彻底消除了因浏览器或驱动自动更新带来的随机失败。2.2 应对现代 Web 技术的挑战如今的 Web 应用越来越复杂。单页应用SPA的异步加载、Shadow DOM 的封装组件、iframe 的嵌套、文件上传下载、网络请求拦截与模拟、地理位置和权限模拟……这些场景在 Selenium 中实现起来往往比较繁琐或者需要依赖第三方库和复杂脚本。Browser Library 基于 Playwright对这些现代特性提供了开箱即用的、优雅的支持。例如处理 Shadow DOM 不再需要执行复杂的 JavaScript 穿透Playwright 提供了专门的定位器如:light选择器或page.locator(‘’)语法在 Robot Framework 中通过 Browser Library 的关键字也能很方便地调用。这对于测试使用了 Web Components 技术栈如 LitElement, Stencil的应用至关重要。2.3 渴望更强大的内置能力与更简洁的代码SeleniumLibrary 专注于核心的浏览器操控很多高级功能需要你自己去扩展或引入其他库。而 Browser Library 将 Playwright 的众多强大功能直接暴露为关键字。举几个例子自动等待Playwright 的操作如点击、填充内置了智能等待它会等待元素可操作可见、启用、稳定后再执行这让我们可以大量减少显式的Wait Until关键字脚本更简洁健壮。网络拦截与模拟你可以轻松地拦截修改网络请求、模拟 API 响应、记录 HAR 文件这对于测试前端错误处理、性能基准测试或模拟后端不可用场景非常有用。多上下文与多页面原生支持无痕上下文、多页面场景更容易实现测试隔离和并行场景测试。设备模拟与截图一键模拟移动设备视图、地理位置、语言环境并支持对元素、页面进行像素级截图和对比。这些功能如果要用 Selenium 实现往往意味着更多的自定义代码和更脆弱的实现。Browser Library 将它们标准化、关键字化降低了使用门槛和维护成本。2.4 寻求更友好的定位器策略与调试体验Selenium 的定位器有时在面对动态ID、复杂类名时显得力不从心。Playwright 推崇使用面向用户的定位器如根据文本内容text、角色role来定位元素这更符合测试的本质——模拟用户行为。Browser Library 支持这些定位器使得测试脚本更易读、更不易受前端微小改动的影响。在调试方面Playwright 提供了强大的 Trace Viewer 工具可以录制测试执行的每一步包括网络请求、DOM 快照、操作日志等。当测试失败时你可以打开一个离线 HTML 报告像看视频一样回溯测试过程这比分析 Selenium 的日志和截图要直观高效得多。Browser Library 也集成了生成这种 Trace 的能力。注意迁移并非毫无成本。最大的挑战在于团队的学习成本和对现有大量测试脚本的改造。如果你的测试套件非常庞大且稳定而上述新特性并非刚需那么维持现状可能是更经济的选择。但对于新项目或者正受困于 Selenium 稳定性问题的团队我强烈建议从 Browser Library 开始。3. 环境搭建与核心配置详解理论说得再多不如动手搭一个环境来得实在。Browser Library 的安装和配置比传统的 Selenium 环境要简洁不少但其中也有一些关键的细节和选择直接影响到后续使用的顺畅度。3.1 安装依赖一步到位与镜像源加速Browser Library 是一个 Robot Framework 的库它依赖于 Playwright 的 Python 包。因此安装分为两步安装库本身以及安装 Playwright 所需的浏览器。基础安装命令pip install robotframework-browser rfbrowser init这条rfbrowser init命令是关键它会自动下载 Playwright 所需的浏览器二进制文件Chromium, Firefox, WebKit。这是与 Selenium 最大的不同之一浏览器是作为依赖被管理的而不是依赖系统安装的浏览器。针对网络环境的优化重要如果你在境内网络环境可能会发现rfbrowser init下载浏览器非常慢甚至失败。这是因为默认的下载源在国外。这里就是我踩过的第一个坑。Playwright 提供了环境变量来指定下载镜像源。对于 Linux/macOS# 设置 Playwright 使用国内镜像源下载浏览器 export PLAYWRIGHT_DOWNLOAD_HOSThttps://npmmirror.com/mirrors/playwright/ rfbrowser init或者你也可以在运行 init 命令时直接指定PLAYWRIGHT_DOWNLOAD_HOSThttps://npmmirror.com/mirrors/playwright/ rfbrowser init对于 Windows (PowerShell)$env:PLAYWRIGHT_DOWNLOAD_HOSThttps://npmmirror.com/mirrors/playwright/ rfbrowser init使用镜像源后下载速度会有质的提升。这是顺利搭建环境的第一步务必记住。安装特定版本的浏览器有时为了与线上环境严格一致你可能需要安装特定版本的 Chromium。rfbrowser init默认安装 Playwright 认为稳定的版本。要安装指定版本可以playwright install chromium版本号 # 例如chromium109.0.5414.0然后再进行rfbrowser init。3.2 项目结构设计与库导入安装完成后你需要在 Robot Framework 的测试套件中引入 Browser 库。我推荐在项目根目录创建一个resource.robot或common.robot资源文件来统一管理这些设置而不是在每个测试用例文件中重复导入。典型的资源文件内容 (common.robot)*** Settings *** Library Browser timeout30s enable_playwright_debug${False} # 导入Browser库并设置全局超时 # 其他全局设置比如Suite Setup/Teardown Suite Setup Open Browser To Start Page Suite Teardown Close All Browsers *** Keywords *** Open Browser To Start Page New Browser chromium headless${HEADLESS} # 使用变量控制是否无头模式 New Context viewport{width: 1920, height: 1080} New Page about:blank这里有几个配置点值得说明timeout30s设置库的默认超时时间。Playwright 的默认超时是 30 秒这里保持一致。enable_playwright_debug设置为True会输出更详细的 Playwright 内部日志调试时有用平时建议关闭。New Browser这里我使用了变量${HEADLESS}。我强烈建议通过命令行参数或外部变量文件来控制是否以无头模式运行方便在本地调试有头和 CI/CD 环境无头之间切换。New Context上下文Context是 Playwright 的一个重要概念它类似于一个独立的浏览器会话拥有独立的 cookies、localStorage 等。在这里设置视口大小可以确保测试的一致性。3.3 与 SeleniumLibrary 的共存策略在迁移过渡期你的项目中很可能需要同时存在 SeleniumLibrary 和 Browser Library 的测试用例。这完全可行但需要一些命名空间上的处理避免关键字冲突。方法一使用库别名推荐在导入库时使用WITH NAME关键字为其指定一个别名。*** Settings *** Library SeleniumLibrary WITH NAME SL Library Browser WITH NAME BR这样在使用关键字时就需要通过别名来调用例如SL.Click Element和BR.Click。虽然写起来稍长但意图非常清晰避免了任何可能的混淆。方法二直接导入注意优先级如果不使用别名后导入的库中的同名关键字会覆盖先导入的。你可以利用这一点但我不推荐因为这会使得代码的意图不明确容易引发错误。我的建议是在新写的用例中统一使用 Browser Library对于旧的、暂时不打算迁移的用例文件可以单独导入 SeleniumLibrary。在项目级的资源文件中可以先导入 Browser Library 作为默认选择。4. 关键字对比与迁移实战这是迁移的核心环节。SeleniumLibrary 和 Browser Library 的关键字设计哲学有显著不同。直接“查找替换”关键字名往往行不通需要理解其背后的差异并调整思维。下面我通过几个最常见的使用场景来对比两者的写法并分享迁移时的具体操作和心法。4.1 浏览器操控与页面导航SeleniumLibrary 风格Open Browser https://www.example.com chrome Maximize Browser Window Go To https://www.example.com/loginBrowser Library 风格# 假设已在Suite Setup中创建了Browser和Context New Page https://www.example.com # Playwright的New Page会自动跳转到该URL # 视口大小在New Context时已设定无需额外‘Maximize’ Go To https://www.example.com/login # 关键字名相同但底层对象是Page关键差异与迁移要点生命周期对象Selenium 的核心是WebDriver直接对应浏览器。Playwright 的核心模型是Browser-Context-Page三层。通常一个测试用例对应一个Page对象。New Page关键字既创建了页面对象也完成了导航。无头模式在New Browser时通过headless${True/False}参数控制比 Selenium 的Open Browser加optionsadd_argument(‘--headless’)更直观。窗口最大化Playwright 不鼓励直接最大化系统窗口而是通过创建上下文Context时指定viewport来设定一个固定的、可复现的视口尺寸。这更符合自动化测试对一致性的要求。4.2 元素定位与交互这是变化最大的部分也是提升脚本健壮性的关键。SeleniumLibrary 风格依赖CSS/XPathInput Text idusername myuser Click Element xpath//button[contains(text(),‘登录’)] Element Should Be Visible css.success-messageBrowser Library 风格推荐使用文本、角色等用户导向定位器Fill Text input[placeholder“请输入用户名”] myuser # 使用属性定位 Click “登录” # 直接使用按钮文本这是Playwright的强大之处 Get Text .success-message 登录成功 # 使用Get Text结合断言 # 或者更严谨的等待某个特定状态 Get Element States “登录成功” visible关键差异与迁移要点定位器策略Browser Library 极力推荐使用面向用户的定位器。“登录”点击包含此文本的元素。input[placeholder“用户名”]根据属性定位。[rolebutton]根据ARIA角色定位。#username传统的ID定位依然支持。 这大大减少了测试脚本对前端实现细节如复杂的CSS类名、脆弱的XPath的依赖。迁移时应重新审视原有定位器看是否能转换为更稳定的文本或角色定位。关键字名称与参数顺序有些关键字名称变了参数顺序也可能不同。例如输入文本从Input Text变成了Fill Text。需要对照 官方关键字文档 逐一适配。内置等待ClickFill Text等操作本身会等待元素可操作。这意味着你经常可以删除那些Wait Until Element Is Enabled或Wait Until Element Is Visible的语句让代码更简洁。这是一个非常棒的改进。4.3 断言与验证断言是测试的灵魂两家库都提供了丰富的断言方式但风格略有不同。SeleniumLibrary 风格Page Should Contain Element idwelcome-msg Element Text Should Be idwelcome-msg 欢迎回来myuser!Browser Library 风格Get Element idwelcome-msg Get Text 欢迎回来myuser! # 或者使用更链式的写法 ${text} Get Text idwelcome-msg Should Be Equal ${text} 欢迎回来myuser! # 或者使用‘Get Element States’进行状态断言 Get Element States idwelcome-msg visible enabled关键差异与迁移要点“Get” 断言模式Browser Library 更倾向于使用Get系列关键字如Get Text,Get Attribute获取值然后结合 Robot Framework 内置的Should Be Equal等关键字或使用、!等操作符在Get关键字后直接进行断言这是 Browser Library 扩展的语法。这种方式更灵活可以组合出复杂的断言逻辑。专用断言关键字Browser Library 也提供了一些类似 SeleniumLibrary 的专用断言关键字如Get TitleGet Url。迁移时可以逐步将旧的Page Should ...类断言改为新的Get ...模式后者通常更具表达力。4.4 处理下拉框、iframe 和 Shadow DOM对于这些复杂组件Browser Library 的优势更加明显。处理下拉框Select# SeleniumLibrary Select From List By Value idcountry CN # Browser Library Select Options By idcountry value CN处理 iframe# SeleniumLibrary Select Frame idpayment-iframe Input Text idcard-number 4111111111111111 Unselect Frame # Browser Library - 更清晰的作用域管理 ${frame} Get Frame idpayment-iframe Click ${frame} idcard-number # 在定位器前指定frame作用域 Fill Text ${frame} idcard-number 4111111111111111处理 Shadow DOM这是杀手级特性# SeleniumLibrary 需要执行JavaScript Execute Javascript return document.querySelector(‘my-component’).shadowRoot.querySelector(‘.inner-button’).click(); # Browser Library 使用特定的穿透语法 Click my-component .inner-button # 或者使用‘Get Element’结合穿透 ${elem} Get Element my-component .inner-button Click ${elem}这个语法糖极大地简化了 Shadow DOM 的操作让测试 Web Components 应用变得可行。5. 高级特性应用与性能优化当你熟悉了基本的关键字迁移后就可以开始探索 Browser Library 那些超越 SeleniumLibrary 的高级功能了。这些功能能帮你写出更强大、更高效、更贴近真实场景的测试。5.1 网络请求拦截与模拟这是进行集成测试、故障注入和性能监控的利器。你可以拦截所有请求或者只针对特定模式的 URL。*** Test Cases *** 模拟API返回错误 [Setup] Setup Network Intercept Go To https://myapp.com/dashboard # 页面请求用户数据API时会被拦截并返回模拟的错误 Wait For Elements State text“加载用户数据失败” visible [Teardown] Teardown Network Intercept *** Keywords *** Setup Network Intercept # 创建一个新的上下文并设置请求路由 ${context} Get Context ${route} Create Route ${context} **/api/user/* # 当匹配到该路由的请求时用自定义响应进行履行 Fulfill ${route} ... status500 ... body{error: Internal Server Error} ... contentTypeapplication/json Teardown Network Intercept # 清理路由恢复正常的网络请求 ${context} Get Context Unroute All ${context}这个例子展示了如何模拟后端 API 返回 500 错误从而测试前端应用的错误处理逻辑是否健壮。你还可以用它来修改请求给所有请求添加特定的请求头。延迟响应模拟网络延迟测试加载状态和超时处理。记录HAR文件自动生成网络性能档案用于分析。5.2 并行执行与上下文隔离Playwright 的Browser和Context模型天生支持并行和隔离。在 Robot Framework 中我们可以利用这一点来提升测试套件的执行速度。策略使用多个独立的 Context每个测试用例或一组相关的用例在自己的Context中运行。Context是轻量级的拥有独立的 cookies、localStorage 和会话状态但共享同一个Browser进程创建和销毁的成本远低于启动新的浏览器。*** Settings *** Test Setup Open Isolated Context Test Teardown Close Context *** Keywords *** Open Isolated Context ${browser} Get Browser # 获取全局已创建的浏览器实例 New Context browser${browser} viewport{‘width’: 1920, ‘height’: 1080} New Page about:blank # 这个新页面在一个干净的上下文中这样测试用例之间完全不会相互干扰比如一个用例登录了不会影响另一个用例同时又避免了反复启动/关闭浏览器内核的巨大开销。这是实现稳定、快速并行测试的基石。5.3 追踪与调试Trace Viewer 集成当测试失败时最头疼的是定位问题原因。Browser Library 可以轻松录制测试执行的追踪文件Trace。*** Settings *** Suite Setup Start Tracing Suite Teardown Stop Tracing And Save *** Keywords *** Start Tracing ${context} Get Context Start Tracing ${context} screenshots${True} snapshots${True} Stop Tracing And Save ${context} Get Context ${trace_path} Stop Tracing ${context} # trace_path 是生成的 .zip 文件路径 Log Trace file saved to: ${trace_path} levelINFO执行后你会得到一个.zip文件。使用 Playwright 的命令行工具即可打开一个图形化的查看器playwright show-trace path/to/trace.zip在这个查看器里你可以按时间线查看每一步操作、当时的 DOM 状态、网络请求、控制台日志甚至是每一步的截图。这比看传统的日志文件和几张截图的效率高出一个数量级是调试复杂异步问题的神器。5.4 与 CI/CD 集成的注意事项在 CI/CD 环境如 Jenkins, GitLab CI, GitHub Actions中运行 Browser Library 测试需要注意以下几点依赖安装确保 CI 镜像或环境中已安装所有系统依赖。Playwright 的 Python 包会尝试安装但某些 Linux 发行版可能需要额外字体库。可以使用 Playwright 提供的命令来安装依赖playwright install-deps无头模式与沙盒在 CI 的 Docker 容器中运行时务必使用headless${True}。另外某些容器环境如以非 root 用户运行可能需要禁用沙盒以启动 ChromiumNew Browser chromium headless${True} args[‘--no-sandbox’, ‘--disable-setuid-sandbox’]警告禁用沙盒会降低安全性仅应在受控的、隔离的 CI 容器环境中使用。绝对不要在个人电脑或服务器上禁用沙盒。视频与截图在 CI 中测试失败时自动截图或录制视频非常有用。Browser Library 支持在创建上下文时配置New Context viewport... recordVideo{‘dir’: ‘./video/’, ‘size’: {‘width’: 1920, ‘height’: 1080}}记得在 Teardown 中妥善保存或上传这些产物。资源清理确保 Suite Teardown 或 Test Teardown 中正确关闭所有 Context 和 Browser避免僵尸进程占用 CI 服务器的内存。6. 迁移路径规划与常见问题排坑从 SeleniumLibrary 全面转向 Browser Library 是一个系统工程尤其是对于已有成百上千个测试用例的项目。激进的全量替换风险很高我推荐采用渐进式、双轨并行的迁移策略。6.1 渐进式迁移策略阶段一探索与试点1-2周在一个新的、独立的测试目录或分支中用 Browser Library 编写几个核心业务流程的测试用例。目标是验证 Browser Library 在你的技术栈前端框架、浏览器版本下的兼容性和稳定性。同时让团队核心成员熟悉新的关键字和模式。阶段二新旧并行逐步替换1-2个月不修改旧用例原有的 SeleniumLibrary 用例继续在 CI 中运行保证主流程的回归。新用例用新库所有新开发的测试用例一律使用 Browser Library 编写。选择性重构当需要修改或扩展某个旧的 SeleniumLibrary 用例时将其作为一次“重构机会”在修改功能的同时将其迁移到 Browser Library。这样迁移成本被分摊到了日常工作中。阶段三全面迁移与收尾视项目规模而定当大部分核心用例都已迁移且团队对新库已经得心应手后可以集中处理剩下的“老旧”用例。此时可以建立专门的迁移任务利用之前积累的经验和工具如下文的辅助脚本批量处理。6.2 迁移辅助工具与脚本完全手动修改关键字效率低下且容易出错。可以编写一些简单的辅助脚本或利用 Robot Framework 自身的功能来加速。利用Libdoc生成关键字对比表为两个库分别生成关键字文档进行对比分析。python -m robot.libdoc SeleniumLibrary list selenium_keywords.txt python -m robot.libdoc Browser list browser_keywords.txt编写自定义的“适配层”关键字对于一些逻辑复杂、调用频繁的旧关键字可以先不修改原有用例而是创建一个资源文件用 Browser Library 重新实现这些关键字并保持其名称和接口不变。这样你只需要在用例中替换导入的库而不用修改大量用例代码。这是一种“偷懒”但有效的过渡手段。# legacy_adapter.robot *** Settings *** Library Browser *** Keywords *** Input Text # 重写SeleniumLibrary的同名关键字 [Arguments] ${locator} ${text} Fill Text ${locator} ${text} Click Element [Arguments] ${locator} Click ${locator}然后在旧用例中将Library SeleniumLibrary替换为Resource legacy_adapter.robot。这能让你快速获得 Browser Library 的部分优势如内置等待同时给代码迁移争取时间。6.3 常见问题与解决方案实录在实际迁移和使用的过程中我遇到了不少坑这里记录下最典型的几个及其解决方法。问题一rfbrowser init失败提示网络错误或超时。原因默认从国外官方源下载浏览器二进制文件网络不稳定。解决如前文所述设置PLAYWRIGHT_DOWNLOAD_HOST环境变量指向国内镜像源。这是成功安装的第一步也是最常见的问题。问题二元素明明存在但Click或Fill Text却报错 “Element is not visible” 或 “Element is detached”。原因1页面存在动画或动态加载元素虽然存在于 DOM但状态不稳定例如正在做 CSS 变换。Playwright 的默认等待虽然智能但有时需要更长的超时。解决1增加操作的关键字级别超时或使用Wait For Elements State确保元素达到稳定状态。Wait For Elements State ${locator} stable timeout10s Click ${locator}原因2页面有多个 iframe 或 Shadow DOM定位器没有指定正确的作用域。解决2仔细检查元素所在的框架使用Get Frame或语法确保定位器指向正确的上下文。问题三测试在本地运行成功但在 CI 服务器上失败。原因1CI 环境缺少必要的系统库或字体。解决1在 CI 脚本中运行playwright install-deps命令安装系统依赖。确保 CI 镜像包含基本的字体包如fonts-liberation。原因2CI 环境可能是无头模式且视口viewport与本地不同导致某些响应式布局的元素不可见或位置不对。解决2在New Context时明确指定一个固定的、足够大的视口尺寸如 1920x1080确保环境一致性。原因3CI 环境资源CPU/内存不足导致浏览器响应慢超时。解决3适当增加全局timeout设置或优化测试用例减少不必要的等待和操作。问题四如何复用 Selenium 时期积累的复杂 XPath 或 CSS 选择器原因直接迁移可能不稳定想利用现有资产。解决Browser Library 完全支持 CSS 和 XPath 定位器你可以继续使用它们。但强烈建议借此迁移机会评估这些复杂定位器是否能转换为更稳定的文本或角色定位器。可以将xpath或css前缀直接用于 Browser Library 的关键字中。# 旧的Selenium定位器 Click Element xpath//div[class‘container’]//button[contains(class, ‘btn-primary’)] # 在Browser Library中可以直接用但不推荐长期使用 Click xpath//div[class‘container’]//button[contains(class, ‘btn-primary’)] # 推荐的改进尝试找到更稳定的定位方式比如按钮文本 Click “提交订单” # 如果按钮文本是唯一的迁移到 Browser Library 不是简单的关键字替换而是一次测试框架的现代化升级。它要求测试开发人员更深入地理解现代浏览器的运作机制和 Playwright 的设计哲学。这个过程初期会有学习成本但一旦跨过这个门槛你将收获的是更快的执行速度、更高的稳定性、更强大的测试能力以及随之而来的更低的维护成本。从我团队的经验来看这笔投资是完全值得的。开始尝试在你的下一个新项目或者挑选一个受稳定性困扰的老模块入手吧实践是检验真理的唯一标准。