GitHub作为协作操作系统：JavaScript工程的CI/CD与代码治理实战-二趣网

简介：本资源是一份面向JavaScript初学者与Web开发入门者的GitHub平台实践入门包，聚焦代码托管、协作开发与开源项目参与的核心能力培养。压缩包共12个文件，含4个HTML页面（用于本地预览GitHub Pages效果）、2个JS脚本（演示基础交互逻辑）、2个PNG图像（可能为界面示意或流程图）、2个.DS_Store系统文件（Mac目录元数据，可忽略），以及.gitattributes和.gitignore配置文件，完整呈现典型GitHub仓库的初始化结构，总大小仅229KB，轻量易解压即用。已有2084人学习下载，适合边学边练：通过实际文件结构理解仓库初始化规范，借助HTML+JS组合快速验证前端效果，结合.gitignore等配置文件掌握版本控制最佳实践，是打通“写代码→建仓库→提PR→参与开源”全链路的实用起点。

1. GitHub 不是代码托管网站那么简单：它是一套可落地的协作操作系统，专治「改完本地跑得通，推上去 CI 直接红」的工程顽疾

你有没有遇到过这种场景：A 同学在本地用 Node.js 18 跑通了整个前端构建流程，提交前还手动npm run build验证过；B 同学拉取后npm install报错，提示peer dependency conflict；CI 流水线更离谱——同一份package.json，GitHub Actions 里yarn install卡死在node-gyp rebuild，日志里连具体失败模块都刷不出来。这不是玄学，是协作链路断层。GitHub 的核心价值，从来不是“把代码存网上”，而是通过 Issues、Pull Requests、Actions、Packages、Code Scanning 这五根支柱，把开发、测试、集成、交付、审计全部钉死在同一个上下文里。它不替代你的技术栈，但强制你暴露所有隐性假设：Node 版本、依赖树拓扑、环境变量注入方式、构建产物路径……这份实战笔记，就从一个真实复现过的 JavaScript 工程出发，带你把 GitHub 当成操作系统来用——不是上传代码，而是部署协作契约。适合正在维护中型以上 JS 项目、被跨环境问题反复折磨、想把 CI/CD 从“能跑”推进到“可信”的一线开发者。

2. GitHub Actions 实战：用 workflow 文件定义可复现的 JavaScript 构建环境，而非“本地能跑就行”

GitHub Actions 的本质，是把本地开发环境的隐式状态（Node 版本、全局工具、PATH 路径）显式声明为 YAML 配置。很多团队卡在第一步：以为写个npm ci && npm test就算 CI，结果每次失败都要人工 SSH 登服务器查日志。真正的落地，是从环境初始化开始抠细节。

2.1 为什么必须用`actions/setup-node@v4`而非系统自带 Node

GitHub 托管运行器（ubuntu-latest / windows-latest）预装多个 Node 版本，但默认 PATH 指向的是系统级 Node，其npm全局安装路径与actions/setup-node管理的路径不一致。这会导致两个致命问题：一是npm install -g安装的 CLI 工具（如typescript,prettier）在后续步骤中不可见；二是npm ci使用的node_modules缓存机制失效，每次都是全量重装。actions/setup-node不仅设置NODE_VERSION，更关键的是它会：

注册node_modules/.bin到 PATH
为npm配置cache目录到 runner 的缓存区（支持actions/cache复用）
绑定corepack版本（若项目使用 pnpm/yarn 3）

# .github/workflows/ci.yml name: JavaScript CI on: [push, pull_request] jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 # 关键：显式声明 Node 版本，并启用 cache - uses: actions/setup-node@v4 with: node-version: '18.19.0' # 强制指定 patch 版本，避免 minor 升级引入 breaking change cache: 'npm' # 启用 npm 缓存，加速 install - run: npm ci # 必须用 ci，而非 install，确保 lockfile 严格一致 - run: npm test

提示：node-version: '18.19.0'中的 patch 版本不能省略。Node.js 18.x 的不同 patch 版本对 V8 引擎、TLS 协议栈有细微差异，曾有项目因18.17.0升级到18.18.0导致fetch()在 mock server 下超时，而本地未复现。

2.2 如何让`npm run build`的产物路径与本地开发完全一致

前端项目常踩的坑是：本地npm run build输出到dist/，但 CI 中因工作目录或--prefix参数不同，产物跑到build/或根目录下。解决方案是在 package.json 中统一声明build脚本的输出路径，并在 workflow 中用--prefix显式覆盖：

// package.json { "scripts": { "build": "webpack --mode production --output-path ./dist" } }

# workflow 中追加构建步骤 - name: Build frontend run: npm run build # 关键：确保 webpack.config.js 中的 output.path 是相对路径，且不依赖 process.cwd() # 若 config 中写了绝对路径，此处需先 cd 到项目根目录 - name: Verify dist directory run: | ls -la dist/ if [ ! -f "dist/index.html" ]; then echo "ERROR: dist/index.html not found!" exit 1 fi

2.3 用`actions/cache`复用 node_modules，把 CI 时间从 6 分钟压到 1 分钟内

npm ci本身已比npm install快，但首次仍需下载所有 tarball。actions/cache可将node_modules目录哈希后缓存，命中率取决于key的设计。错误做法是用npm --version或node --version作 key——它们变化太频繁。正确 key 应包含三要素：锁文件内容哈希、Node 版本、操作系统标识：

- uses: actions/cache@v4 id: cache-npm with: path: | **/node_modules key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}-${{ env.NODE_VERSION }} # 注意：env.NODE_VERSION 需在 setup-node 后通过 env 传递 - uses: actions/setup-node@v4 with: node-version: '18.19.0' env: NODE_VERSION: '18.19.0' # 为 cache key 提供稳定变量

逻辑说明：hashFiles('**/package-lock.json')计算所有 lockfile 的 SHA-256，确保依赖树变更时 key 必然不同；runner.os防止 Linux 缓存被 Windows 步骤误用；NODE_VERSION避免 Node 升级导致二进制模块（如 bcrypt）不兼容。实测某中型 React 项目，缓存命中后npm ci从 210s 降至 18s。

3. Pull Request 协作规范：用 GitHub 原生功能替代口头约定，把 Code Review 变成可追溯的决策链

PR 不是“等别人点 Merge”的待办事项，而是工程决策的原子单元。很多团队 PR 描述空洞（只写“修复 bug”），Review 评论散落在聊天工具里，最终谁批准、基于什么理由、是否验证过回归用例，全部丢失。GitHub 提供了原生机制固化这些信息。

3.1 PR Template：用必填字段强制暴露关键上下文

.github/pull_request_template.md不是装饰品，是防止信息黑洞的第一道闸门。必须包含以下字段，且设为required（通过 GitHub Settings > Branches > Require pull request templates 启用）：

## 本次变更解决的问题 - [ ] 修复了哪个 Issue？（链接到 #issue-number） - [ ] 是否影响 API 接口？若是，请说明变更点及兼容性（BREAKING CHANGE / 兼容升级） - [ ] 是否修改了构建配置？若是，请说明对 CI/CD 流程的影响 ## 本地验证步骤 1. `git checkout main && npm ci` 2. `git checkout <branch-name> && npm ci` 3. `npm run dev` 启动本地服务，访问 http://localhost:3000/test-page 验证 XXX 功能 4. `npm test` 全部通过，新增测试覆盖率 ≥ 85% ## 截图/录屏（前端必填） - [ ] 修改前界面截图 - [ ] 修改后界面截图（标注改动区域） - [ ] 关键交互录屏（如表单提交、异步加载）

参数说明：required字段由 GitHub 原生校验，未勾选则无法提交 PR 描述；npm run dev步骤强制要求验证端到端流程，而非仅跑单元测试；截图要求直击“视觉回归”风险点——这是前端 CR 最易遗漏的盲区。

3.2 Review 评论必须绑定到具体代码行，并关联测试用例

空泛评论如“这里可读性差”毫无价值。有效 Review 必须满足：
①定位到行：点击代码行号左侧+添加评论，确保上下文锁定；
②引用测试：在评论中直接贴出对应测试用例的文件路径和行号，例如见 tests/unit/utils/formatDate.test.ts:42-45；
③给出可执行建议：不说“重构一下”，而说“建议提取为独立函数formatDateForDisplay(date: Date)，参数类型与返回值已在 JSDoc 中声明”。

GitHub 会自动将此类评论归档到 PR 的 “Files changed” 标签页，形成带时间戳、可搜索、可追踪的决策日志。当半年后有人质疑“为什么这里用Math.floor而非Math.round”，直接搜索formatDate+Math.floor即可定位当年 Review 讨论。

3.3 用 Required Reviews 和 CODEOWNERS 实现责任闭环

仅靠自觉无法保证 Review 质量。必须在 Settings > Branches 中配置：

Require pull request reviews before merging：至少 1 名 reviewer 批准；
Require status checks to pass before merging：必须通过 CI（如ci/test）、代码扫描（如codeql-analysis）；
Include administrators：管理员也受约束，避免“特权跳过”；
CODEOWNERS 文件：按路径指定责任人，例如：

# .github/CODEOWNERS /src/api/** @backend-team /src/components/** @frontend-team /tests/** @qa-team /package.json @devops-lead

当 PR 修改/src/api/userService.ts时，GitHub 自动通知@backend-team，且只有该组成员的 approve 才计入 Required Reviews。这杜绝了“没人看”或“乱批”的情况——责任精确到路径，而非模糊的“找个人看看”。

4. GitHub Issues 管理：把需求、Bug、技术债变成可量化、可追踪、可归因的工作单元

Issues 常被当成临时便签，导致需求淹没、Bug 重复提交、技术债越积越多。真正落地的做法，是把它作为唯一真相源（Single Source of Truth），所有工作流都从中派生。

4.1 Issue Template：用结构化字段替代自由文本，为自动化铺路

.github/ISSUE_TEMPLATE/bug_report.md必须强制填写可程序化字段：

--- name: Bug Report about: 提交一个可复现的缺陷 title: '' labels: 'bug, needs-triage' assignees: '' --- ## 描述 请清晰描述问题现象（非预期行为） ## 复现步骤 1. 访问 https://example.com/login 2. 输入用户名 `test`，密码 `123` 3. 点击登录按钮 4. 页面跳转至 404 ## 预期行为 应跳转至用户仪表盘（/dashboard） ## 实际行为 返回 HTTP 404，控制台报错 `Uncaught ReferenceError: dashboardUrl is not defined` ## 环境信息 - 浏览器：Chrome 122.0.6261.94 - 操作系统：macOS Sonoma 14.3 - 应用版本：v2.4.1（见页面底部 footer） - Node 版本：v18.19.0（CI 日志第 12 行）

逻辑说明：labels: 'bug, needs-triage'为后续自动化提供分类依据；环境信息字段明确要求提供应用版本和 Node 版本，避免“我这边好的”式无效沟通；控制台报错直接定位到 JS 执行上下文，跳过网络层排查。

4.2 用 GitHub Projects 看板实现需求流转可视化

创建名为Sprint Backlog的 Project（Beta），列设置为：To Do→In Progress→Review→Testing→Done。每个 Issue 拖入对应列时，自动触发状态更新。关键技巧：

在In Progress列添加自动化规则：当 Issue 进入此列，自动 assign 给拖入者，并添加 labelin-progress；
在Review列添加检查项：Issue 进入此列时，自动检查是否关联了 PR（通过is:pr linked:issue查询），若无则发 comment 提醒；
在Done列设置归档条件：Issue 关闭后 7 天自动移出看板，避免堆积。

这样，每日站会只需看 Project 看板，无需口头同步“我在做什么”，状态一目了然。

4.3 用 Issue 关联技术债，让“以后重构”变成可追踪任务

技术债常以“TODO”注释形式散落在代码中，极易遗忘。正确做法是：
① 在代码中写// TODO(@devops-lead): extract validation logic to shared lib — see #1234；
② 创建 Issue #1234，标题为Extract input validation logic from LoginForm to shared utils，标签设为tech-debt；
③ 在 Issue 描述中粘贴原始代码片段及行号，并注明影响范围（如“当前影响 3 个表单组件”）。

GitHub 会自动将see #1234解析为链接，点击即可跳转。当某天决定处理此债时，直接打开 #1234，所有上下文（代码位置、影响面、提出人）都在。

5. GitHub Code Scanning：用 CodeQL 在 PR 阶段拦截 JavaScript 高危漏洞，而非等渗透测试报告

Code Scanning 不是“再加一道扫描”，而是把安全左移到开发者敲下git push的瞬间。很多团队误以为它只查 SQL 注入，其实对 JS 生态的威胁覆盖极广：原型污染、不安全的eval、危险的innerHTML拼接、硬编码密钥、过期的依赖包。

5.1 配置 CodeQL 分析 JavaScript 项目的最小可行方案

.github/workflows/codeql.yml的核心是精准选择查询集。默认全量扫描耗时过长，应聚焦高危场景：

name: CodeQL Analysis on: push: branches: [main] pull_request: branches: [main] schedule: - cron: '0 0 * * 0' # 每周日零点全量扫描 jobs: analyze: name: Analyze runs-on: ubuntu-latest permissions: actions: read contents: read security-events: write # 必须开启，否则无法提交告警 strategy: fail-fast: false matrix: language: ['javascript'] steps: - name: Checkout repository uses: actions/checkout@v4 - name: Initialize CodeQL uses: github/codeql-action/init@v3 with: languages: ${{ matrix.language }} queries: +security-and-quality # 关键：只启用安全与质量类查询 # 排除低风险查询，如 'javascript/unused-function' - name: Perform CodeQL Analysis uses: github/codeql-action/analyze@v3 with: category: '/language:${{ matrix.language }}'

参数说明：queries: +security-and-quality启用 CodeQL 官方维护的安全规则集，覆盖 OWASP Top 10 中 JS 相关项；category确保分析结果按语言分组，避免 TypeScript 与 JavaScript 混淆；security-events: write权限是硬性要求，缺失则扫描成功但不报告。

5.2 解读三个典型 JavaScript 告警及其修复方案

CodeQL 报告的不是“可能有问题”，而是“确定存在漏洞路径”。以下是真实案例：

告警 ID	问题类型	触发代码示例	修复方案
`js/insecure-random`	使用`Math.random()`生成密码/Token	`const token = Math.random().toString(36).substr(2, 10);`	替换为`crypto.randomUUID()`（现代浏览器）或`crypto.randomBytes(10).toString('hex')`（Node.js）
`js/dom-xss`	`innerHTML`直接插入用户输入	`el.innerHTML = '<div>' + userInput + '</div>';`	改用`textContent`，或使用`DOMPurify.sanitize()`过滤 HTML
`js/hardcoded-secret`	字符串字面量含疑似密钥	`const API_KEY = 'sk_live_abc123...';`	移至环境变量，用`process.env.API_KEY`读取，并在`.gitignore`中排除`.env`

注意：js/hardcoded-secret会扫描所有字符串，包括注释。曾有项目因// TODO: fix hardcoded key in line 42被误报，此时应在该行添加// codeql[no-alert]注释禁用。

5.3 将 Code Scanning 结果接入 PR 检查，实现“不修复不合并”

在 Settings > Branches > Branch protection rules 中，为main分支启用：

Require status checks to pass before merging→ 勾选Code scanning results；
Dismiss stale pull request approvals when new commits are pushed：防止旧 Approval 绕过新扫描结果。

当 PR 引入新漏洞时，GitHub 会在 Checks 标签页显示红色Code scanning results，并列出具体文件、行号、漏洞等级。开发者必须点击 “View details” 进入 Security 标签页，点击 “Resolve in PR” 提交修复，否则 Merge 按钮置灰。这比任何流程文档都管用——它把安全要求变成了 Git 协议的一部分。

6. GitHub Packages 与私有 NPM Registry：用 GitHub 原生包管理替代 Nexus/JFrog，解决“内部组件无法被 CI 拉取”的终极困境

JavaScript 团队常陷入两难：把公共组件发布到 npmjs.org 涉及权限和命名冲突；自建 Nexus 又增加运维负担。GitHub Packages 提供了零配置的私有 Registry，且与仓库权限天然打通。

6.1 发布私有包：三步完成，无需额外配置文件

假设有一个内部工具库@myorg/utils，发布流程如下：

# 1. 在 package.json 中声明 registry { "name": "@myorg/utils", "version": "1.2.0", "publishConfig": { "registry": "https://npm.pkg.github.com" } } # 2. 登录 GitHub Packages（使用 Personal Access Token） npm login --scope=@myorg --registry=https://npm.pkg.github.com # 3. 发布（自动推送到同名 GitHub 仓库下的 Packages） npm publish

逻辑说明：publishConfig.registry强制 npm 将包推送到 GitHub Packages；npm login时的 scope 必须与name前缀一致（@myorg）；发布后，包自动出现在https://github.com/myorg/utils/packages页面，且权限继承自仓库（private 仓库的包默认 private）。

6.2 在 CI 中安全拉取私有包：用 GITHUB_TOKEN 替代明文 Token

.github/workflows/ci.yml中拉取私有包的关键，是利用 GitHub 自动生成的GITHUB_TOKEN，无需手动管理 Token：

- name: Setup Node uses: actions/setup-node@v4 with: node-version: '18.19.0' registry-url: 'https://npm.pkg.github.com' # 关键：用 GITHUB_TOKEN 作为 auth token scope: '@myorg' - name: Install dependencies run: npm ci env: NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }} # GITHUB_TOKEN 由 GitHub 自动注入，无需手动配置

参数说明：scope: '@myorg'告诉 setup-node 为@myorg域名配置 registry；NODE_AUTH_TOKEN是 npm 的标准环境变量，setup-node 会将其写入.npmrc；secrets.GITHUB_TOKEN具有当前仓库的读取权限，且生命周期与 workflow 绑定，比 PAT 更安全。

6.3 避坑：常见问题与血泪排查记录

现象 → 原因 → 解决，每条均来自真实翻车现场：

现象：npm ci报错404 Not Found - GET https://npm.pkg.github.com/@myorg%2futils
原因：包名@myorg/utils中的myorg与 GitHub 组织名不一致（实际组织名为my-org），或仓库名不是utils（实际为utils-lib）
解决：GitHub Packages 要求包名严格匹配<organization>/<repository>，检查package.json.name和仓库 URL 是否完全一致
现象：本地npm install成功，但 CI 中npm ci失败，提示ETARGET版本不匹配
原因：package-lock.json中@myorg/utils的 resolved 字段指向https://registry.npmjs.org/，而非 GitHub Packages
解决：删除package-lock.json，重新运行npm ci（确保.npmrc中 registry 配置正确），或手动编辑 lockfile 将resolved改为https://npm.pkg.github.com/@myorg/utils/-/@myorg/utils-1.2.0.tgz
现象：PR 中修改了@myorg/utils的依赖，但 CI 未触发@myorg/utils的重新构建
原因：未配置 Dependabot 或手动触发，导致上游包变更未通知下游
解决：在.github/dependabot.yml中添加：
```
version: 2 updates: - package-ecosystem: "npm" directory: "/" schedule: interval: "daily" open-pull-requests-limit: 10
```
并为@myorg/utils仓库启用 Dependabot，使其自动检测下游依赖变更
现象：npm publish失败，提示403 Forbidden
原因：GITHUB_TOKEN权限不足，或仓库为 private 但未在 Settings > Packages 中启用 “Allow specified users and teams to access this package”
解决：进入https://github.com/orgs/<org>/settings/packages，找到对应包，点击 “Edit package settings”，勾选 “Allow all authenticated users” 或指定团队
现象：npm install @myorg/utils在本地成功，但构建 Docker 镜像时失败
原因：Docker 构建上下文未包含.npmrc，且未在 Dockerfile 中配置 registry
解决：在 Dockerfile 中添加：
```
COPY .npmrc /app/.npmrc RUN npm ci --only=production
```
并确保.npmrc内容为：
```
@myorg:registry=https://npm.pkg.github.com //npm.pkg.github.com/:_authToken=${NODE_AUTH_TOKEN}
```

从那以后我每次新建内部包，都强制走一遍npm login→npm publish→npm install本地验证 → CI 验证的全流程，哪怕只是发个1.0.0的空包。因为 GitHub Packages 的坑不在复杂，而在隐蔽——它完美复刻了 npmjs.org 的协议，却在权限、域名、缓存上埋了无数个“应该一样但其实不一样”的雷。希望帮到你。

本文还有配套的精品资源，点击获取

企业官网建设流程全解析

1. GitHub 不是代码托管网站那么简单：它是一套可落地的协作操作系统，专治「改完本地跑得通，推上去 CI 直接红」的工程顽疾

2. GitHub Actions 实战：用 workflow 文件定义可复现的 JavaScript 构建环境，而非“本地能跑就行”

2.1 为什么必须用`actions/setup-node@v4`而非系统自带 Node

2.2 如何让`npm run build`的产物路径与本地开发完全一致

2.3 用`actions/cache`复用 node_modules，把 CI 时间从 6 分钟压到 1 分钟内

3. Pull Request 协作规范：用 GitHub 原生功能替代口头约定，把 Code Review 变成可追溯的决策链

3.1 PR Template：用必填字段强制暴露关键上下文

3.2 Review 评论必须绑定到具体代码行，并关联测试用例

3.3 用 Required Reviews 和 CODEOWNERS 实现责任闭环

4. GitHub Issues 管理：把需求、Bug、技术债变成可量化、可追踪、可归因的工作单元

4.1 Issue Template：用结构化字段替代自由文本，为自动化铺路

4.2 用 GitHub Projects 看板实现需求流转可视化

4.3 用 Issue 关联技术债，让“以后重构”变成可追踪任务

5. GitHub Code Scanning：用 CodeQL 在 PR 阶段拦截 JavaScript 高危漏洞，而非等渗透测试报告

5.1 配置 CodeQL 分析 JavaScript 项目的最小可行方案

5.2 解读三个典型 JavaScript 告警及其修复方案

5.3 将 Code Scanning 结果接入 PR 检查，实现“不修复不合并”

6. GitHub Packages 与私有 NPM Registry：用 GitHub 原生包管理替代 Nexus/JFrog，解决“内部组件无法被 CI 拉取”的终极困境

6.1 发布私有包：三步完成，无需额外配置文件

6.2 在 CI 中安全拉取私有包：用 GITHUB_TOKEN 替代明文 Token

6.3 避坑：常见问题与血泪排查记录

热门文章

文章分类

标签云

需要专业的网站建设服务？

企业官网建设流程全解析

1. GitHub 不是代码托管网站那么简单：它是一套可落地的协作操作系统，专治「改完本地跑得通，推上去 CI 直接红」的工程顽疾

2. GitHub Actions 实战：用 workflow 文件定义可复现的 JavaScript 构建环境，而非“本地能跑就行”

2.1 为什么必须用actions/setup-node@v4而非系统自带 Node

2.2 如何让npm run build的产物路径与本地开发完全一致

2.3 用actions/cache复用 node_modules，把 CI 时间从 6 分钟压到 1 分钟内

3. Pull Request 协作规范：用 GitHub 原生功能替代口头约定，把 Code Review 变成可追溯的决策链

3.1 PR Template：用必填字段强制暴露关键上下文

3.2 Review 评论必须绑定到具体代码行，并关联测试用例

3.3 用 Required Reviews 和 CODEOWNERS 实现责任闭环

4. GitHub Issues 管理：把需求、Bug、技术债变成可量化、可追踪、可归因的工作单元

4.1 Issue Template：用结构化字段替代自由文本，为自动化铺路

4.2 用 GitHub Projects 看板实现需求流转可视化

4.3 用 Issue 关联技术债，让“以后重构”变成可追踪任务

5. GitHub Code Scanning：用 CodeQL 在 PR 阶段拦截 JavaScript 高危漏洞，而非等渗透测试报告

5.1 配置 CodeQL 分析 JavaScript 项目的最小可行方案

5.2 解读三个典型 JavaScript 告警及其修复方案

5.3 将 Code Scanning 结果接入 PR 检查，实现“不修复不合并”

6. GitHub Packages 与私有 NPM Registry：用 GitHub 原生包管理替代 Nexus/JFrog，解决“内部组件无法被 CI 拉取”的终极困境

6.1 发布私有包：三步完成，无需额外配置文件

6.2 在 CI 中安全拉取私有包：用 GITHUB_TOKEN 替代明文 Token

6.3 避坑：常见问题与血泪排查记录

热门文章

文章分类

标签云

相关文章

去神秘化：额外维度投影为3D格点动力学自由度

财务自动化工具选型与落地实践指南

React合成事件机制与性能优化实践

需要专业的网站建设服务？

2.1 为什么必须用`actions/setup-node@v4`而非系统自带 Node

2.2 如何让`npm run build`的产物路径与本地开发完全一致

2.3 用`actions/cache`复用 node_modules，把 CI 时间从 6 分钟压到 1 分钟内