<p>核心是跳过重复安装：用npm ci或yarn install --frozen-lockfile，配锁文件哈希缓存键（files: - package-lock.json），禁用引擎校验，并统一Linux runner镜像；进阶可结合Redis跳过整个安装阶段。</p>
在 Linux 环境下用 GitLab CI 的 cache 功能加速前端项目 node_modules 构建，核心是让每次流水线跳过重复下载和解压依赖的过程。关键不在“装得多快”，而在“不装或少装”——只要缓存命中，yarn install 或 npm ci 几乎秒过。
选对安装命令：必须用 npm ci 或 yarn install --frozen-lockfile
普通 npm install 会读取 package.json 并动态解析版本范围，可能生成新 package-lock.json，导致缓存失效；而 npm ci 强制按锁文件精确还原，自动清空旧 node_modules，避免残留干扰，也更易命中缓存。
- 确保项目已提交
package-lock.json（npm）或yarn.lock（yarn） - CI 脚本中统一替换为：
npm ci或yarn install --frozen-lockfile --no-progress - 禁用引擎校验可进一步提速（尤其跨 Node 版本时）：
yarn config set ignore-engines true
配置精准缓存键：基于锁文件哈希，而非分支名
只用 ${CI_COMMIT_REF_SLUG} 作缓存 key，会导致同一分支下锁文件变更也无法触发新缓存——这是常见误配。应优先采用 files: 方式，让 GitLab 自动计算锁文件内容哈希。
抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...
- 推荐写法（.gitlab-ci.yml 全局 cache 区）：
cache:<br> key:<br> files:<br> - package-lock.json<br> paths:<br> - node_modules/<br> - .yarn/cache/
- 若用 pnpm，加
- .pnpm-store/；若用 yarn v1，加- .yarn-cache/ - 避免把
node_modules/单独设为唯一 path——它体积大、文件多，GitLab 上传/下载耗时高；配合包管理器自身缓存目录（如.yarn/cache），能显著减少网络传输量
规避缓存污染与平台陷阱
node_modules 不是纯数据目录，含平台相关二进制（如 node-sass、sharp），Linux runner 上缓存的模块不能直接复用于 macOS 或 Windows。即使同为 Linux，不同 glibc 版本或 Node ABI 也可能导致崩溃。
立即学习“前端免费学习笔记（深入）”；
- 确保所有 runner 使用一致的基础镜像，例如统一用
node:20-alpine或node:20-bullseye - 禁止跨操作系统共享缓存——不要在 Linux job 中 restore macOS job 推送的缓存
- 原生模块较多时，可在
before_script中加检查：ls -la node_modules/.bin | head -5，确认关键二进制存在且可执行 - 遇到“Module not found”或“cannot open shared object file”，大概率是缓存混用或 Node 升级未清理，此时需手动清除对应分支缓存
进阶：跳过安装阶段（条件性执行）
当锁文件完全没变，连 npm ci 都可跳过——只需比对当前 package-lock.json 的 MD5 和上一次成功构建时的值。可用 Redis 记录历史哈希，脚本中判断后决定是否运行安装命令。
- 示例逻辑片段：
FILE_MD5=$(md5sum package-lock.json | cut -d' ' -f1)<br>REDIS_MD5=$(redis-cli -h $REDIS_HOST GET "lock-${CI_COMMIT_REF_SLUG}")<br>if [ "$FILE_MD5" != "$REDIS_MD5" ]; then npm ci; redis-cli -h $REDIS_HOST SET "lock-${CI_COMMIT_REF_SLUG}" "$FILE_MD5"; fi - 需要提前部署 Redis 服务并开放访问权限，适合中大型团队长期维护
- 相比纯 cache，该方式省去缓存拉取/校验开销，构建时间可压至仅剩
npm run build本身耗时
