解读

在前端工程化面试中，这道题表面问“颜色”，实质考察构建层对设计约束的适配能力。品牌色不可变往往源于集团VI规范、法务审批或CEO拍板，不能改≠不能动，Grunt 的任务是“在不可改色的前提下，让页面依旧可用、可访问、可维护”。面试官想听你如何把“死”颜色变成“活”方案，同时体现工程化思维、性能意识、团队协作。

知识点

1. CSS 变量降级：PostCSS + grunt-postcss + postcss-custom-properties，自动输出 IE11 兼容的静态色值，同时保留变量版本供现代浏览器。
2. 主题切换不碰品牌色：用 grunt-sass / grunt-less 在编译期把“功能色（成功、危险、警告）”抽成 mixin，品牌色仅用于主按钮、logo 区，其余区域用中性色阶梯做视觉层次，保证品牌色占比 <10%，既合规又不单调。
3. 对比度自动检测：grunt-accessibility 调用 axe-core，扫描品牌色与背景对比度，若低于 4.5:1，不改动色值，而是自动在构建层插入aria-label、加粗字体、增加 1px 文字阴影，保证 WCAG 2.1 合规。
4. 深色模式适配：grunt-contrib-sass 配合@media (prefers-color-scheme: dark)，把品牌色映射到官方提供的暗色阶（如#0052CC→#0A66C0），若品牌方未给暗色阶，则用 grunt-colorguard 锁定亮度差异，禁止随意调色，只通过透明度层叠（rgba($brand, 0.9)）实现暗色感知，不生成新色值。
5. 性能与缓存：grunt-filerev 对“品牌色雪碧图”单独关闭哈希，避免 CDN 缓存失效导致品牌色闪烁；同时 grunt-newer 只对功能色图标做增量压缩，减少无谓构建。
6. 交付约束：在 Gruntfile 里用 grunt-contrib-copy 把brand-color.json（含官方色值、透明度使用范围）打入 dist，供下游 Java 或 Node 服务端做运行时校验，防止运营后台随意换色。

答案

“品牌色不可变”首先要把它工程化锁定：

1. 在 Gruntfile 中定义BRAND_COLOR=process.env.BRAND_COLOR || '#0052CC'，只读不写，任何插件试图修改即抛错；
2. 用 grunt-postcss 配 postcss-custom-properties，现代浏览器走变量，IE 走静态编译结果，不新增色值；
3. 视觉层次靠中性色阶梯与间距、字体粗细完成，品牌色仅用于主按钮、logo，占比可控；
4. 对比度不足时，不动色值，用 grunt-accessibility 自动插入aria-label、加粗、阴影，保证可访问性；
5. 暗色模式若品牌方未给暗色阶，仅用透明度层叠（rgba($brand,0.9)），grunt-colorguard 防止亮度漂移；
6. 构建产物附带brand-color.json，服务端运行时校验，杜绝运营误改。
   这样在不触碰品牌色前提下，依旧实现多端适配、可访问、可维护、高性能的工程化方案。

拓展思考

1. 设计 tokens 落地：如果集团后续允许“品牌色扩展”，如何把这套 Grunt 流程无缝迁移到 Style Dictionary，实现设计-代码一体化？
2. CI 卡点：在 GitLab CI 里用 grunt-colorguard 做MR 门禁，一旦检测到非官方品牌色即拒绝合并，把规范左移到开发阶段。
3. 微前端场景：子应用独立构建，如何用 grunt-shared-config 把母应用的品牌色运行时注入，避免每个子应用重复打包，减少 3% 包体积。