Git钩子脚本如何检查交互设计

wen 实用脚本 2026-07-15 1

本文目录导读：

Git钩子脚本如何检查交互设计

📚 目录导读
为什么需要Git钩子检查交互设计？
Git钩子基础与交互设计检查的切入点
常见交互设计违规场景与钩子脚本示例
实战：pre-commit钩子自动校验设计Token
高频问题解答（FAQ）
注意事项与团队落地建议

📚 目录导读

为什么需要Git钩子检查交互设计？
Git钩子基础与交互设计检查的切入点
常见交互设计违规场景与钩子脚本示例
实战：pre-commit钩子自动校验设计Token
高频问题解答（FAQ）
注意事项与团队落地建议

为什么需要Git钩子检查交互设计？

很多团队在开发过程中发现：功能实现了，但交互细节频频出问题——比如按钮间距错误、颜色值偏离设计系统、字体字号与设计稿不符，传统的“开发-测试-返工”流程，往往在代码合并到主分支后才暴露问题,修复成本极高。

Git钩子脚本可以在commit或push之前，自动扫描代码中与交互设计相关的代码片段，拦截不符合设计规范的提交，这种 “左移” 质量管控思路，将交互检查从人工评审阶段提前到编码提交的一瞬间，实现“无感但有效”的防线。

Git钩子基础与交互设计检查的切入点

1 Git钩子是什么？

Git钩子是Git版本库在特定事件（如commit、push、merge）发生时自动触发的脚本,常用的是：

pre-commit：在输入提交信息前运行,适合检查新增或修改的文件。
pre-push：在推送前运行,适合检查整个仓库的完整状态。
post-commit：提交后运行,通常用于通知或记录。

2 交互设计检查的切入点

我们可以在pre-commit阶段扫描被变更的文件,匹配设计系统中的关键约束：

检查项	对应代码特征	检测方式
颜色值是否在设计系统内	`color: #...`、`background: ...`	正则匹配+白名单
间距是否使用设计Token	`margin: 8px`、`padding: 12px`	检查是否出现硬编码数字
字体字号是否合规	`font-size: 16px`、`font-weight: 700`	比对设计系统变量集
圆角、阴影、边框厚度	`border-radius: 4px`、`box-shadow: ...`	正则+Token映射表

✅ 核心思想：硬编码数值是交互设计的敌人，任何直接写在CSS/JSX中的16px、#3b82f6，都应该被替换为设计系统中的语义变量（如--spacing-md、--color-primary）。

常见交互设计违规场景与钩子脚本示例

1 场景一：硬编码颜色值

/* 违规示例 */
.btn { background: #3b82f6; }

钩子脚本逻辑：读取项目中已定义的颜色变量集合（如从tokens.json读取），扫描新增的CSS/JSX文件，如果发现颜色值不在集合内,则阻止提交。

2 场景二：非标准间距

// 违规示例
<div style={{ marginLeft: 12 }}>...</div>

钩子脚本逻辑：检查行内样式或样式对象中的margin、padding数字是否为设计系统定义的倍率（如4px的倍数：4、8、12、16、20……）。

3 场景三：字体字号脱离设计系统

// 违规示例{ font-size: 22px; }

钩子脚本逻辑：扫描所有font-size声明，如果值不在$font-sizes: (12, 14, 16, 20, 24, 32)中,则输出警告并终止提交。

实战：`pre-commit`钩子自动校验设计Token

1 创建钩子文件

在项目根目录的.git/hooks/下新建pre-commit文件（无后缀）,并赋予可执行权限：

chmod +x .git/hooks/pre-commit

2 编写核心脚本（Node.js版本）

因为交互设计检查需要对CSS/JSX进行语义解析，推荐用Node.js编写,示例脚本逻辑：

#!/usr/bin/env node
const { execSync } = require('child_process');
const fs = require('fs');
const path = require('path');
// 1. 获取本次变更的文件列表（仅包含CSS/JSX/TSX）
const changedFiles = execSync('git diff --cached --name-only --diff-filter=ACM')
  .toString()
  .split('\n')
  .filter(f => f.match(/\.(css|scss|jsx|tsx)$/));
// 2. 加载设计系统Token
const designTokens = JSON.parse(fs.readFileSync('./tokens.json', 'utf-8'));
const validColors = designTokens.colors;    // ["#1a1a2e", "#16213e", ...]
const validSpacings = designTokens.spacings; // [4, 8, 12, 16, 24, 32]
// 3. 逐文件检查
let errors = [];
changedFiles.forEach(file => {
  const content = fs.readFileSync(file, 'utf-8');
  // 检查颜色值：hex或rgba格式
  const colorRegex = /#([0-9a-fA-F]{3}|[0-9a-fA-F]{6})\b/g;
  let match;
  while ((match = colorRegex.exec(content)) !== null) {
    if (!validColors.includes(match[0])) {
      errors.push(`${file}: 发现未授权的颜色值 ${match[0]}`);
    }
  }
  // 检查硬编码间距（非Token方式）
  const spacingRegex = /(margin|padding)[\s:]+(\d+)px/g;
  while ((match = spacingRegex.exec(content)) !== null) {
    const value = parseInt(match[2], 10);
    if (!validSpacings.includes(value)) {
      errors.push(`${file}: 间距值 ${value}px 不符合设计系统，建议使用 designToken`);
    }
  }
});
// 4. 如有错误则中止提交
if (errors.length > 0) {
  console.error('❌ 交互设计检查失败：\n' + errors.join('\n'));
  process.exit(1);
} else {
  console.log('✅ 交互设计检查通过');
}

3 集成到团队工作流

不要手动复制钩子文件——推荐使用Husky或lefthook这些工具统一管理Git钩子,例如用Husky：

// package.json
{
  "husky": {
    "hooks": {
      "pre-commit": "node scripts/check-interaction.js"
    }
  }
}

高频问题解答（FAQ）

Q1：钩子脚本会不会拖慢提交速度？
A：只扫描本次变更的文件（不是全量扫描），且检查逻辑通常只需几百毫秒，如果团队有数千个文件，可以进一步限流（比如只检查CSS/JSX文件，跳过图片和配置文件）。

Q2：交互设计标准经常变化怎么办？
A：将设计Token单独存储为JSON或YAML文件（如tokens.json），并纳入Git版本管理，设计师和前端开发者共同维护此文件，钩子脚本只读取该文件,无需硬编码规则。

Q3：如果某些硬编码是故意的（如第三方组件样式）怎么跳过？
A：在脚本中加入“忽略文件路径”白名单（例如node_modules/、vendor/），或者在代码中用特殊注释标记：/* skip-interaction-check */

Q4：钩子脚本一定要用Node.js吗？
A：不强制，可以用Python、Shell甚至Go，但Node.js常用于前端项目，因为可以直接复用package.json依赖（如stylelint、eslint-plugin-design-tokens）。

Q5：除了颜色和间距，还能检查什么？
A：可以检查border-radius是否非标准化、font-weight是否使用数字而非关键词（如700而非bold）、line-height是否与字体大小成对应比例，更进阶的可以结合视觉回归工具（如Percy、Chromatic）在pre-push阶段截图对比。