Git钩子脚本如何检查响应式设计

用Git钩子脚本自动化检查响应式设计：从入门到实战

目录导读

1. 为什么要在Git提交前检查响应式设计？
2. Git钩子脚本基础：pre-commit与post-commit
3. 响应式设计检查的核心维度
4. 实战脚本：用Puppeteer自动化检测视口
5. 集成CSS媒体查询验证
6. 常见问题与解答（FAQ）

为什么要在Git提交前检查响应式设计？

响应式设计已不是“可选项”，而是现代Web开发的强制性要求，根据Google的移动优先索引策略，若网站未适配不同屏幕尺寸，将直接导致搜索排名下降，在团队协作中，开发者时常会疏忽一些细节——比如忘记添加meta viewport标签、忽略断点覆盖，或者引入了破坏布局的CSS变更。

Git钩子脚本的价值在于：它能在代码提交（commit）或推送（push）之前自动执行响应式检测，将问题扼杀在本地，而非暴露到生产环境，这比人工代码审查或后续的QA测试效率更高，且成本更低。

Git钩子脚本基础：pre-commit与post-commit

Git钩子位于项目的.git/hooks/目录下，本质上是可执行的脚本文件，常用的两个钩子为：

• pre-commit：在提交信息输入前执行，如果脚本返回非零退出码，则提交被中止，适合用于质量门禁检查。
• post-commit：提交成功后执行，适合触发通知或辅助任务。

重点：脚本需具有执行权限（chmod +x .git/hooks/pre-commit），且文件第一行需声明解释器（如#!/bin/bash或#!/usr/bin/env node）。

响应式设计检查的核心维度

一个完善的响应式检测脚本应覆盖以下维度：

实战脚本：用Puppeteer自动化检测视口

以下是一个基于Node.js的pre-commit钩子示例，它利用Puppeteer（无头Chrome）在三个常用视口下抓取页面快照，并与基准图对比。

// .git/hooks/pre-commit
#!/usr/bin/env node
const puppeteer = require('puppeteer');
const pixelmatch = require('pixelmatch');
const { PNG } = require('pngjs');
const fs = require('fs');
const VIEWPORTS = [
  { width: 375, height: 812 },  // iPhone X
  { width: 768, height: 1024 }, // iPad
  { width: 1920, height: 1080 } // 桌面
];
async function capturePage(url, viewport) {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.setViewport(viewport);
  await page.goto(url, { waitUntil: 'networkidle0' });
  await page.screenshot({ path: `screenshot-${viewport.width}.png` });
  await browser.close();
}
// 检查差异
async function checkDiff(view) {
  const base = `base-${view.width}.png`;
  const newImage = `screenshot-${view.width}.png`;
  if (!fs.existsSync(base)) {
    fs.renameSync(newImage, base);
    return;
  }
  const img1 = PNG.sync.read(fs.readFileSync(base));
  const img2 = PNG.sync.read(fs.readFileSync(newImage));
  const diff = new PNG({ width: img1.width, height: img1.height });
  const diffPixels = pixelmatch(img1.data, img2.data, diff.data, img1.width, img1.height, { threshold: 0.1 });
  if (diffPixels > 50) {
    console.error(`响应式布局差异过大 (${view.width}x${view.height}): ${diffPixels} 像素不同`);
    process.exit(1);
  }
}
(async () => {
  for (const view of VIEWPORTS) {
    await capturePage('http://localhost:8000', view);
    await checkDiff(view);
  }
  console.log('响应式检查通过');
})();

说明：该脚本会自动对比当前构建的页面与基准截图，若像素差异超过50（排除微小变化），则中止提交，团队可定期更新基准图。

集成CSS媒体查询验证

除了视觉对比,我们还应在静态层面验证CSS是否正确，以下Bash脚本片段可检查项目中是否包含必要的媒体查询：

#!/bin/bash
# 检查是否存在响应式断点
if grep -rq "@media" src/styles/; then
    echo "✔ 已找到媒体查询"
else
    echo "✘ 未检测到任何媒体查询！请确保添加响应式断点。"
    exit 1
fi
# 检查主流断点
for bp in 768 1024 1200; do
    if grep -rq "$bp" src/styles/; then
        echo "  断点 $bp px 已定义"
    else
        echo "  ⚠ 断点 $bp px 缺失"
    fi
done
# 检查 viewport meta 标签
if grep -rq 'width=device-width' index.html; then
    echo "✔ Viewport meta 标签正确"
else
    echo "✘ 缺少 width=device-width！"
    exit 1
fi

执行时机：可将上述脚本放在.git/hooks/pre-commit的顶部，先快速检测静态规则，再执行较慢的Puppeteer检查。

常见问题与解答（FAQ）

Q1：钩子脚本可以在团队中共享吗？
A：可以，将脚本存放在项目根目录的hooks/文件夹中，然后在package.json中通过"prepare": "husky install"（若使用Husky）自动安装到.git/hooks，或者手动复制配置说明。

Q2：如果服务器不是本地localhost怎么办？
A：可以使用process.env.CI环境变量来动态决定URL，在CI/CD中设为实际部署预览地址，在本地开发则设为localhost，或者让脚本接受一个参数：node check-responsive.js --url=http://staging.mysite.com。

Q3：截图对比的基准图如何维护？
A：推荐将基准图存入Git仓库（放在test/screenshots/目录下），当故意更改设计时，先更新基准图再提交，可加入提示：“若这是预期变更，请运行npm run update-baselines”。

Q4：脚本运行太慢怎么办？
A：可优化策略：只检查有修改的文件（通过git diff --cached --name-only获取变更文件列表），而不是全站扫描，或者使用--only-changed模式。

Q5：是否需要考虑移动端触摸交互？
A：基础的布局检测不涉及交互，如需验证点击区域是否太小（<44px），可结合Puppeteer的page.click()方法并捕获console.error，但这会显著增加复杂度，建议作为单独的工作流。

Q6：Husky与原生命令行工具有何差异？
A：Husky简化了钩子的安装与版本管理，而原生脚本更轻量，团队无需安装额外依赖，推荐在Node项目中使用Husky，在纯前端或通用项目中用原生脚本。

最终建议：响应式检查应作为持续集成（CI）的一部分，但本地钩子可提供“第一道防线”，二者结合使用，能以最小成本维护高质量的移动端体验。