Cypress前端自动化测试：从架构原理到工程实践全解析

1. 项目概述：为什么是Cypress？

如果你正在为Web应用的自动化测试头疼，尤其是那些依赖复杂交互、动态数据或需要模拟真实用户行为的场景，那么Cypress的出现，很可能就是你的“解药”。我最初接触Cypress，是因为一个老项目里用Selenium写的测试用例维护成本高得吓人，一个简单的UI改动就能让一堆测试“红”掉，排查起来像大海捞针。后来团队决定技术选型，我花了大量时间对比了Selenium、Puppeteer、Playwright等主流方案，最终Cypress以其独特的设计哲学和极致的开发体验脱颖而出。

简单来说，Cypress是一个现代化的、基于JavaScript的前端端到端（E2E）测试框架。它和我们熟知的Selenium有本质区别。Selenium是通过WebDriver协议远程控制浏览器，像一个“外部遥控器”；而Cypress则直接运行在与应用相同的运行循环中，像一个“内部观察员”。这意味着Cypress能直接访问和控制前端应用的一切，包括网络请求、DOM状态、甚至本地存储，从而实现了超快的执行速度和近乎实时的调试能力。

它的核心价值在于，让编写、运行和调试自动化测试变得像开发功能一样直观和高效。你不再需要为等待元素、处理异步操作、管理浏览器驱动而烦恼。对于前端开发者、测试工程师或全栈工程师而言，Cypress极大地降低了自动化测试的门槛，将测试从一项繁琐的“验证任务”，转变为提升开发质量和效率的“开发实践”。

2. 核心架构与设计哲学拆解

要真正用好Cypress，不能只停留在API调用层面，必须理解其底层设计思想。这决定了你写测试用例的思维模式，也能帮你避开很多“坑”。

2.1 与众不同的运行机制

Cypress最颠覆性的设计，就是它的架构。传统的E2E测试工具（如Selenium）采用客户端-服务器架构。你的测试代码（客户端）通过HTTP请求向一个独立的WebDriver服务器发送指令（如“点击这个按钮”），服务器再驱动浏览器执行。这个过程中存在大量的网络延迟和序列化/反序列化开销。

Cypress则采用了完全不同的方式。它将测试运行器（Test Runner）直接注入到浏览器中，与你的应用程序运行在同一个上下文中。你可以把它想象成浏览器的一个“超级插件”。这种架构带来了几个革命性的优势：

1. 同步执行，告别等待：因为测试代码和应用代码在同一个事件循环里，Cypress能自动等待命令和断言执行完毕。你几乎不需要写cy.wait()或处理复杂的Promise链。当你说cy.get(‘.submit-btn’).click()时，Cypress会一直等到这个按钮确实存在于DOM且可点击时，才执行点击操作。
2. 实时重新加载与时间旅行：Cypress的Test Runner提供了一个强大的GUI界面。当你修改测试代码并保存时，所有测试会立刻重新运行。更重要的是，它记录了每一个命令执行时的快照。你可以像使用调试器一样，在命令日志中点击任意一个历史命令，查看当时整个应用的状态（DOM、网络请求、控制台日志），这极大地简化了调试过程。
3. 完整的网络流量控制：Cypress可以轻松地拦截、存根（Stub）或修改任何进出浏览器的HTTP请求。这意味着你可以在不依赖后端服务的情况下，完全控制测试数据，实现稳定、快速的测试。

注意：正因为Cypress运行在浏览器内部，它无法直接驱动多个浏览器标签页或测试跨域场景（除非进行特殊配置）。这是其架构带来的一个天然限制，在设计测试策略时需要提前考虑。

2.2 核心概念：命令队列与重试机制

Cypress的命令（如cy.get(),cy.click(),cy.type()）不是立即执行的。它们会被推入一个命令队列。Cypress会异步地、按顺序执行这个队列中的每一个命令。每个命令都有内置的、智能的重试机制。

例如，当你执行cy.get(‘#dynamic-element’)去获取一个可能由异步操作（如API调用）后渲染的元素时，Cypress不会立刻失败。它会在接下来的几秒内（默认4秒）不断重试这个查询，直到元素出现，或者超时。这几乎消除了测试中因时序问题导致的“脆性测试”（Flaky Tests）。

这种“重试-直到”的逻辑也应用在断言上。cy.get(‘button’).should(‘have.class’, ‘active’)这条语句中，.should()断言也会自动重试，直到按钮拥有active类，或者超时。这意味着你的断言描述的是应用的“最终稳定状态”，而不是某个瞬间的快照，这让测试更加健壮。

3. 环境搭建与项目初始化实战

理论说再多，不如动手搭一个。这里我会带你从零开始，搭建一个完整的Cypress测试环境，并分享一些初始化配置的“黄金法则”。

3.1 安装与项目结构

假设你有一个现有的前端项目（比如基于Vue/React的），或者新建一个空目录。

首先，通过npm或yarn安装Cypress。我强烈建议将其作为开发依赖安装在项目本地，而不是全局安装，这样可以保证团队所有成员使用相同版本。

# 使用 npm npm install cypress --save-dev # 或使用 yarn yarn add cypress --dev

安装完成后，打开Cypress。第一次运行会初始化项目结构。

npx cypress open

执行这个命令后，Cypress会做两件事：1. 在你的项目根目录下创建一个cypress文件夹；2. 启动Cypress Test Runner图形界面。第一次运行还会在cypress/e2e下生成一系列示例测试文件，强烈建议新手浏览一遍，里面有很多最佳实践。

一个典型的Cypress项目结构如下：

your-project/ ├── cypress/ │ ├── e2e/ # 测试用例文件存放目录 │ │ ├── login.cy.js # 登录测试用例 │ │ └── dashboard.cy.js # 仪表盘测试用例 │ ├── fixtures/ # 静态测试数据文件（如JSON） │ │ └── users.json │ ├── support/ # 支持文件 │ │ ├── commands.js # 自定义命令 │ │ └── e2e.js # 测试运行前的全局配置和导入 │ └── downloads/ # 测试中下载的文件（可配置） │ └── screenshots/ # 测试失败时的截图 │ └── videos/ # 测试录制视频（如果开启） ├── cypress.config.js # Cypress主配置文件 └── package.json

3.2 关键配置文件详解

cypress.config.js是核心配置文件。一个基础但功能齐全的配置如下：

const { defineConfig } = require('cypress') module.exports = defineConfig({ e2e: { // 设置测试文件匹配模式 specPattern: 'cypress/e2e/**/*.cy.{js,jsx,ts,tsx}', // 设置基础URL，你的测试中可以使用相对路径，Cypress会自动拼接 baseUrl: 'http://localhost:3000', // 视口大小 viewportWidth: 1280, viewportHeight: 720, // 每个测试用例失败时自动截图 screenshotOnRunFailure: true, // 录制测试视频（默认关闭，因为可能影响性能） video: false, // 实验性功能：组件测试（如果项目是组件化框架） // experimentalStudio: true, // 全局设置，在所有测试文件运行前执行 setupNodeEvents(on, config) { // 可以在这里集成插件，例如读取环境变量、预处理文件等 // 例如，根据环境变量切换baseUrl if (config.env.environment === 'staging') { config.baseUrl = 'https://staging.your-app.com' } return config }, }, })

在cypress/support/e2e.js文件中，你可以进行每次测试前的全局设置，比如导入自定义命令、设置全局的beforeEach钩子。

// cypress/support/e2e.js // 导入自定义命令，这样在所有测试文件中都可以使用 import './commands' // 全局的 beforeEach 钩子 beforeEach(() => { // 例如：每次测试前都清空 localStorage，保证测试隔离 cy.clearLocalStorage() // 或者，拦截一些通用的API请求，返回固定数据 cy.intercept('GET', '/api/user/profile', { fixture: 'profile.json' }).as('getProfile') })

实操心得：baseUrl一定要配！这是最重要的配置之一。配置后，在测试中写cy.visit(‘/login’)就等于访问http://localhost:3000/login，大大简化了代码。另外，我习惯在support/e2e.js里做两件事：1. 设置一个全局的API请求拦截，防止测试因无关的后端波动而失败；2. 对于需要登录的测试，可以在这里写一个Cypress.Commands.add(‘login’, …)自定义命令，后面会详细讲。

4. 编写第一个健壮的测试用例

让我们从一个最常见的场景开始：用户登录。我将带你一步步编写一个不仅“能用”，而且“健壮”的测试。

4.1 测试用例结构与语法

在cypress/e2e目录下新建一个文件login.cy.js。Cypress使用Mocha的语法风格（describe,it,beforeEach等）和Chai的断言库（expect,should）。

// cypress/e2e/login.cy.js describe('登录功能', () => { // 在每个测试用例(it)之前运行 beforeEach(() => { // 访问登录页面。因为配置了baseUrl，这里用相对路径即可。 cy.visit('/login') }) it('使用正确的用户名和密码应该登录成功，并跳转到仪表盘', () => { // 1. 定位用户名输入框并输入文本 cy.get('[data-testid="username-input"]') .type('testuser') .should('have.value', 'testuser') // 断言输入的值正确 // 2. 定位密码输入框并输入文本 cy.get('[data-testid="password-input"]') .type('securepassword123') // 3. 点击登录按钮 cy.get('[data-testid="login-submit-btn"]').click() // 4. 验证登录成功后的行为 // 4.1 验证页面URL跳转到了仪表盘 cy.url().should('include', '/dashboard') // 4.2 验证页面中出现了欢迎用户的元素 cy.get('[data-testid="welcome-message"]') .should('be.visible') .and('contain.text', '欢迎回来，testuser') // 4.3 验证登录后，登录按钮应该消失 cy.get('[data-testid="login-submit-btn"]').should('not.exist') }) it('使用错误的密码应该显示错误提示信息', () => { cy.get('[data-testid="username-input"]').type('testuser') cy.get('[data-testid="password-input"]').type('wrongpassword') cy.get('[data-testid="login-submit-btn"]').click() // 验证错误提示出现 cy.get('[data-testid="error-message"]') .should('be.visible') .and('have.css', 'color', 'rgb(255, 0, 0)') // 甚至可以断言样式 .and('contain.text', '密码错误') // 验证页面没有跳转，仍然在登录页 cy.url().should('eq', Cypress.config().baseUrl + '/login') }) })

关键点解析：

• >{ "validUser": { "username": "testuser", "password": "securepassword123", "name": "测试用户" }, "invalidUser": { "username": "testuser", "password": "wrong" } }

  然后在测试中引入：

  it('使用fixture数据登录成功', () => { // 加载fixture文件 cy.fixture('users').then((userData) => { const user = userData.validUser cy.get('[data-testid="username-input"]').type(user.username) cy.get('[data-testid="password-input"]').type(user.password) cy.get('[data-testid="login-submit-btn"]').click() cy.get('[data-testid="welcome-message"]').should('contain.text', user.name) }) })

  实操心得：对于更复杂的场景，比如需要先通过API创建测试数据，我更喜欢在beforeEach钩子中使用cy.request()调用后端API来准备数据，测试完再用afterEach清理。这样数据更动态、更真实。Fixtures更适合那些不变的、作为请求响应存根（Stub）的数据。

  5. 高级技巧：网络请求控制与自定义命令

  当你的应用与后端API深度交互时，控制网络请求是写出稳定、快速测试的关键。

  5.1 拦截与存根（Intercept and Stub）

  假设登录操作会向/api/login发送一个POST请求。我们不希望测试依赖真实的后端，或者想测试特定的响应（如网络错误）。

  it('拦截登录API并模拟成功响应', () => { // 在访问页面和触发请求前，先设置拦截 cy.intercept('POST', '/api/login', { statusCode: 200, body: { success: true, token: 'fake-jwt-token', user: { id: 1, name: 'Mocked User' } } }).as('loginRequest') // 给这个拦截起个别名，方便后续引用 cy.visit('/login') cy.get('[data-testid="username-input"]').type('user') cy.get('[data-testid="password-input"]').type('pass') cy.get('[data-testid="login-submit-btn"]').click() // 等待特定的拦截请求完成，并对其断言 cy.wait('@loginRequest').its('request.body').should('deep.equal', { username: 'user', password: 'pass' }) // 等待请求完成后，再断言页面跳转 cy.url().should('include', '/dashboard') }) it('拦截登录API并模拟失败响应', () => { cy.intercept('POST', '/api/login', { statusCode: 401, body: { success: false, message: '认证失败' } }).as('failedLogin') cy.visit('/login') // ... 输入信息并点击 cy.get('[data-testid="login-submit-btn"]').click() cy.wait('@failedLogin') cy.get('[data-testid="error-message"]').should('contain.text', '认证失败') })

  cy.intercept()功能极其强大，你还可以用它来：

  • 修改真实响应：req.reply((res) => { res.body.modified = true; return res; })
  • 动态路由：根据请求内容返回不同响应。
  • 延迟响应：测试加载状态。req.reply({ delay: 2000, body: {...} })

  5.2 创建自定义命令

  如果你发现某些操作在多个测试中重复出现（比如登录），就应该把它抽象成自定义命令。这能提升代码复用性和可读性。

  在cypress/support/commands.js中：

  // cypress/support/commands.js // 定义一个名为‘login’的自定义命令 Cypress.Commands.add('login', (username, password) => { // 如果没传参数，使用默认的测试用户 const u = username || Cypress.env('TEST_USERNAME') || 'testuser' const p = password || Cypress.env('TEST_PASSWORD') || 'testpass' // 使用cy.session可以缓存登录状态，极大加速需要登录的测试套件（Cypress 12+） cy.session([u, p], () => { cy.visit('/login') cy.get('[data-testid="username-input"]').type(u) cy.get('[data-testid="password-input"]').type(p, { log: false }) // {log: false} 隐藏敏感信息在命令日志中 cy.get('[data-testid="login-submit-btn"]').click() // 确保登录成功 cy.url().should('include', '/dashboard') }) }) // 定义一个命令来快速创建测试数据（通过API） Cypress.Commands.add('createTodo', (todoText) => { // 假设后端需要一个认证头 const authToken = window.localStorage.getItem('authToken') cy.request({ method: 'POST', url: `${Cypress.config().baseUrl}/api/todos`, headers: { Authorization: `Bearer ${authToken}` }, body: { text: todoText } }).then((response) => { // 将创建的todo数据返回，方便测试用例中使用 return response.body }) })

  然后在任何测试文件中，你就可以像使用原生命令一样使用它们：

  describe('待办事项列表', () => { beforeEach(() => { // 一行命令完成登录！ cy.login() cy.visit('/todos') }) it('应该能创建新的待办事项', () => { const newTodo = '学习Cypress高级技巧' // 使用自定义命令创建数据 cy.createTodo(newTodo).then((createdTodo) => { // 创建后，前端列表应该更新 cy.get('[data-testid="todo-list"] li') .should('have.length', 1) .first() .should('contain.text', newTodo) // 甚至可以断言ID等来自响应的属性 .and('have.attr', 'data-todo-id', createdTodo.id.toString()) }) }) })

  实操心得：cy.session()是Cypress的一个革命性功能。它允许你缓存一个“会话”（包括cookies, localStorage等），在同一个测试套件中，只有第一次cy.login()会真正走登录流程，后续的beforeEach中的cy.login()会直接复用缓存，测试速度能有数量级的提升。一定要用起来。

  6. 测试组织、运行与调试策略

  写了很多测试用例后，如何高效地组织、运行和调试它们，就成了新的挑战。

  6.1 测试组织与标签化

  Cypress默认会运行cypress/e2e下所有的*.cy.*文件。你可以通过文件夹来组织测试，例如：

  • cypress/e2e/authentication/- 所有认证相关测试
  • cypress/e2e/dashboard/- 仪表盘相关测试
  • cypress/e2e/api/- 专门测试API（结合cy.request）

  更灵活的方式是使用标签。你可以在describe或it后面加上.only或.skip，或者在配置文件中使用excludeSpecPattern。但我推荐使用自定义标签，并通过环境变量来过滤运行。

  在cypress.config.js中配置：

  module.exports = defineConfig({ e2e: { setupNodeEvents(on, config) { const specPattern = config.specPattern // 如果设置了环境变量 TEST_TAG，则只运行包含该标签的测试 if (config.env.TEST_TAG) { const tag = config.env.TEST_TAG // 这里需要安装一个如 cypress-tags 的插件来实现，或者自己写过滤逻辑 // 例如，假设我们的测试描述写成 describe('登录 @smoke', ...) // 我们可以过滤出包含 `@${tag}` 的测试文件 } return config } } })

  在命令行中运行：npx cypress run --env TEST_TAG=smoke

  个人体会：我习惯给测试打上@smoke（冒烟测试）、@regression（回归测试）、@slow（运行慢的测试）等标签。在CI/CD流水线中，每次代码推送都运行@smoke测试，每晚定时运行完整的@regression套件。对于@slow的测试（比如涉及文件上传下载），可能会单独安排运行频率。

  6.2 命令行运行与CI集成

  虽然cypress open的GUI很棒，但在持续集成（CI）环境中，我们需要无头（headless）运行。使用cypress run命令。

  # 运行所有测试（无头模式，使用Electron浏览器） npx cypress run # 指定浏览器运行 npx cypress run --browser chrome # 运行某个特定测试文件 npx cypress run --spec "cypress/e2e/login.cy.js" # 运行某个文件夹下的所有测试 npx cypress run --spec "cypress/e2e/dashboard/**/*" # 指定配置，如环境变量 npx cypress run --env baseUrl=https://staging.example.com,apiHost=staging-api.example.com

  在CI（如GitHub Actions, GitLab CI, Jenkins）中集成Cypress非常普遍。核心步骤通常包括：

  1. 安装依赖。
  2. 启动你的开发服务器（如果测试需要）。
  3. 运行Cypress测试。
  4. 上传测试结果、截图和视频（如果失败）。

  一个简单的GitHub Actions配置示例：

  name: E2E Tests on: [push] jobs: cypress-run: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v3 - name: Install dependencies run: npm ci - name: Start dev server run: npm start & # 通常需要等待服务器就绪 - name: Wait for server run: npx wait-on http://localhost:3000 - name: Run Cypress tests uses: cypress-io/github-action@v5 with: start: npm start wait-on: 'http://localhost:3000' # 可以在这里指定浏览器、spec等 - name: Upload artifacts (on failure) if: failure() uses: actions/upload-artifact@v3 with: name: cypress-screenshots-videos path: | cypress/screenshots cypress/videos

  6.3 调试技巧实录

  即使Cypress的调试体验已经一流，但复杂测试出问题时，掌握一些技巧还是能事半功倍。

  1. 利用Time Travel（时间旅行）：这是Cypress Test Runner最强大的功能。测试运行时，左侧的命令日志是一个可点击的时间轴。点击任意一个过去的命令（如GET，CLICK），右侧的预览窗口就会精确地回放到那个时间点的应用状态。你可以检查当时的DOM、Console、Network请求。这是定位“元素为什么没找到？”或“页面状态为什么不对？”的首选方法。

  2. 使用cy.pause()和cy.debug()：

     • cy.pause()：在代码中插入此命令，测试运行到此处会暂停。你可以在命令日志中手动点击“下一步”来继续执行，同时观察应用变化。
     • cy.debug()：暂停测试，并进入一个类似浏览器开发者工具的调试状态。你可以直接在Console中执行JavaScript来检查当前作用域内的变量（如Cypress.$选中的元素）。输入resume继续执行。

     it('调试示例', () => { cy.visit('/') cy.get('input').type('something') cy.pause() // 测试暂停，检查输入框是否已输入 cy.get('button').click() cy.debug() // 进入调试器，可以检查网络请求或DOM状态 cy.get('.result').should('contain', 'success') })

  3. 查看快照（Snapshot）：每个命令在命令日志中都有一个快照图标。悬停可以快速查看该命令执行前后的DOM差异。对于断言失败，快照尤其有用，它能告诉你断言失败那一刻页面到底是什么样子。

  4. 善用.then()进行命令式调试：虽然Cypress推荐链式命令，但有时你需要获取某个命令的返回值并进行复杂操作。这时可以用.then()。

     cy.get('[data-testid="user-list"] li') .should('have.length.gt', 0) // 确保列表有元素 .then(($listItems) => { // $listItems 是一个jQuery对象 console.log(`找到了 ${$listItems.length} 个用户`) // 可以进行一些自定义的JS断言或操作 const firstUserName = $listItems.first().find('.name').text() expect(firstUserName).to.match(/^[A-Z]/) // 使用Chai的expect })

  常见问题排查清单：

  问题现象	可能原因	排查步骤
  cy.get(...)超时失败	1. 元素选择器写错。 2. 元素是动态加载的，出现太慢。 3. 元素在iframe或shadow DOM内。 4. 页面跳转或重定向导致元素不存在。	1. 使用Cypress Selector Playground验证选择器。 2. 增加默认命令超时时间{ timeout: 10000 }。 3. 检查元素是否真的被渲染（用.pause()和开发者工具）。 4. 对于iframe，使用cy.frameLoaded()和cy.iframe()。
  测试在CI上失败，本地却成功	1. CI环境与本地环境差异（数据、网络、配置）。 2. CI机器性能差，异步操作更慢。 3. 测试本身是“脆性测试”，依赖不稳定的时序。	1. 检查CI日志中的截图和视频，看失败时的页面状态。 2. 在CI配置中增加命令超时和页面加载超时。 3. 使用cy.intercept()存根不稳定的API。 4. 确保测试数据在每次运行前是干净的。
  cy.click()报错元素不可点击	1. 元素被遮挡（如弹窗、加载层）。 2. 元素有pointer-events: none样式。 3. 元素尚未处于可交互状态（如禁用）。	1. 使用.click({ force: true })强制点击（慎用，可能掩盖真实bug）。 2. 检查并关闭可能遮挡的元素。 3. 使用.should(‘be.visible’).and(‘not.be.disabled’)确保状态。
  自定义命令不生效	1. 命令文件commands.js未在support/e2e.js中导入。 2. 命令定义语法错误。 3. 作用域问题，在错误的地方调用。	1. 检查support/e2e.js是否有import ‘./commands’。 2. 检查命令名是否冲突。 3. 确保在测试用例或beforeEach等钩子中调用。

  7. 从“能用”到“优秀”：最佳实践与性能优化

  当你熟悉了Cypress的基本操作后，下一个目标就是写出可维护、高性能的测试套件。

  7.1 测试数据管理策略

  糟糕的数据管理是测试套件脆弱的首要原因。我的策略是分层管理：

  1. 静态数据（Fixtures）：用于存根（Stub）API响应。例如，固定的用户信息、配置数据。它们应该小而专注，一个fixture文件只服务一个具体场景。
  2. 动态数据（API创建）：在beforeEach或before钩子中，使用cy.request()调用后端API来创建测试所需的数据（用户、订单、文章等）。在afterEach或after钩子中清理这些数据。这保证了测试的独立性和可重复性。
  3. 环境变量：将敏感信息（如测试账号密码、API密钥）和与环境相关的配置（如不同环境的baseUrl）放在环境变量中。Cypress支持通过cypress.config.js的env字段、命令行--env参数或cypress.env.json文件来管理。

  // cypress.config.js module.exports = defineConfig({ e2e: { env: { apiUrl: 'http://localhost:3001/api', // 可以从系统环境变量中读取，避免硬编码 testEmail: process.env.CYPRESS_TEST_EMAIL, testPassword: process.env.CYPRESS_TEST_PASSWORD } } })

  7.2 选择器策略：稳定性的基石

  我见过太多因为前端重构一个CSS类名而导致整个测试套件崩溃的案例。选择器的稳定性至关重要。

  • 首选：><button>cy.get('[data-testid="submit-login"]').click()

  • 次选：语义化选择器：如果无法添加测试属性，优先使用name、aria-label等具有语义的HTML属性。

    cy.get('input[name="username"]') cy.get('[aria-label="搜索按钮"]')

  • 避免：实现细节选择器：尽量避免使用与样式或布局紧密耦合的选择器，如.btn-primary、#main > div > form > button。这些是最脆弱的。

  实操心得：我们团队在代码审查中有一条硬性规定：新增或修改关键交互元素时，必须同时添加或更新对应的>const { defineConfig } = require('cypress') module.exports = defineConfig({ reporter: 'mochawesome', reporterOptions: { reportDir: 'cypress/reports', overwrite: false, html: true, json: true, }, e2e: { // ... 其他配置 } })

  运行测试时使用：npx cypress run --reporter mochawesome。运行后会生成一个包含详细结果的HTML文件。

  最后，我想分享一个最深的体会：Cypress不仅仅是一个测试工具，它更是一种促使你写出更好、更可测试的前端代码的催化剂。当你开始用Cypress的思维去思考——如何让元素更容易被定位、如何让状态更可控、如何让交互流程更清晰——你会发现，这不仅让测试变得简单，也让你的应用代码质量得到了提升。从“测试驱动开发”（TDD）的角度看，先写Cypress测试，再去实现功能，是一种非常高效且能保证质量的工作流。不妨从下一个新功能开始尝试。