全站黑白灰CSS：4套CMS部署与避坑指南

每年到了特定的全国性哀悼日，或者遇到重大灾难、公众人物离世等需要表达哀思的时刻，许多中文网站都会把整站调成黑白灰色调。我自己运营的几个网站，包括地方资讯类项目，在过去几年里也都按需做过这种处理。这篇文章我把自己用过的几套滤镜方案、踩过的坑、性能与无障碍方面的注意点，一次性整理出来，希望能帮到同样在维护中文站点的同行。

为什么要做全站黑白灰处理

在国内的网络文化里，黑白灰几乎是约定俗成的哀悼视觉语言。把网站颜色去掉，本质上是在传达三件事：

第一，对事件本身的尊重。彩色页面在某些场景下会显得突兀，把饱和度抹掉是一种克制的表达。

第二，告诉读者“我们注意到了”。我做地方资讯站时，本地用户对这种细节非常敏感，能看出站长是不是有心。

第三，避免广告画面与哀悼氛围冲突。很多站点是有广告联盟代码的，黑白滤镜叠加上去之后，广告也会跟着变灰，不需要单独处理每一个素材。

我个人的判断标准很简单：只在官方明确发布哀悼公告时才上线，结束当天 0 点准时撤掉，不滥用、不蹭热度。这点后面会专门展开讲。

最常用的一段CSS滤镜代码

下面这段是我用了好几年的版本，几乎兼容所有现代浏览器，对老IE也做了降级处理：

html {
    -webkit-filter: grayscale(100%);
    -moz-filter: grayscale(100%);
    -ms-filter: grayscale(100%);
    -o-filter: grayscale(100%);
    filter: grayscale(100%);
    filter: progid:DXImageTransform.Microsoft.BasicImage(grayscale=1);
    _filter: none;
}

几个细节解释一下：

• 把规则挂在html上而不是body上，是为了让滚动条、原生表单控件这些边缘元素也跟着变灰，覆盖范围最大。
• -webkit-、-moz-、-ms-、-o-这几个前缀针对早期Chrome/Safari、Firefox、IE边缘版本和Opera。今天的浏览器已经基本只认无前缀的filter，但保留前缀对老用户更友好，体积也只多几十字节。
• progid:DXImageTransform.Microsoft.BasicImage(grayscale=1)是IE 6~9的私有滤镜，国内还有少量政企终端在跑这些版本，加上不会出错。
• 最后那行_filter: none;是IE6的hack，避免某些老IE默认就拿到非空值导致渲染异常。

如果你只关心现代浏览器，可以直接简化成一行：

html { filter: grayscale(100%); }

把代码挂到主流CMS上的具体做法

我自己跨多个CMS都部署过这段代码，写一下最少改动的接入方式。

Typecho

登录后台 → 控制台 → 外观 → 编辑当前外观 → 找到header.php，在</head>之前加：

<style>
html { filter: grayscale(100%); -webkit-filter: grayscale(100%); }
</style>

如果你的主题支持自定义头部代码（比如我自己用的zhangwenbao主题），可以直接在“主题设置 → 自定义HEAD代码”字段里填，避免改主题源码。这样升级主题时也不会丢。

WordPress

WordPress有几种接入方式：

1. 主题customizer的额外CSS（最不推荐改主题文件）：“外观 → 自定义 → 额外CSS”直接粘贴上面那段CSS。这种方法对WordPress所有主题通用，且更新主题不会丢失。
2. 子主题的style.css：如果你用了子主题，加到子主题的style.css末尾即可。
3. 插件方式：插件市场里有“Mourning”“Grayscale Mode”类插件，一键开关，适合非技术用户。

我个人推荐方法一，因为零成本、无需主题改动、不依赖插件。

Z-Blog

Z-Blog的主题文件夹里找header.php或head.php，在</head>之前加同样的<style>代码块即可。Z-Blog的application/Module模块也支持自定义CSS注入，效果一样。

DedeCMS

DedeCMS的全站模板入口一般是templets/default/head.htm，不同主题路径可能不同。在该文件的</head>之前加CSS代码块。注意DedeCMS模板修改后需要去后台“站长 → 数据 → 更新缓存”清掉模板缓存才能生效。

Discuz

Discuz的主入口模板是template/default/common/header.htm。改完后台“站长 → 数据 → 更新缓存”选模板缓存更新。Discuz的自定义模板会继承这段CSS，所有版块、帖子、门户页都会变灰。

静态站点（Hexo / Hugo / Gatsby）

静态站点最简单——直接改主题的全局CSS文件，重新构建发布即可。如果你不想动主题，可以在主题的head.html偏置位置加一个独立的<style>标签。

更精细的方案：保留某些区域不变灰

有时候你不希望整站完全变灰，比如导航栏的Logo或者某些重要图标想保留原色。这种情况下，把filter: grayscale(100%)挂到html是不够灵活的——它会让所有子元素都变灰。需要做选择性反转。

方法是给html加全局灰度，再给特殊元素加反向滤镜：

html {
    filter: grayscale(100%);
}

/* 让 logo 区域保持原色 */
.site-logo {
    filter: grayscale(0%) !important;
}

/* 但是这种 filter 嵌套不会真的恢复颜色 */

这里有个坑：CSS的filter属性不会反向恢复。父元素已经filter成灰度，子元素再filter成grayscale(0%)只是叠加了一个无效操作，实际上元素还是灰的。原因是CSS filter作用于“渲染合成阶段”的位图，而不是源图像数据。

正确的解决方案是：把灰度滤镜挂到body而不是html，再用position把要保留原色的元素提取到html层级。或者更简单——给整个html加filter: grayscale(100%)，对要保留原色的元素加position: fixed并且z-index极高，但这种方案对布局影响很大，实际很少用。

务实的做法是用SVG filter的matrix变换实现真正的反向：

<svg width="0" height="0" style="position:absolute">
  <filter id="grayscale-color">
    <feColorMatrix type="matrix"
      values="0.21 0.72 0.07 0 0
              0.21 0.72 0.07 0 0
              0.21 0.72 0.07 0 0
              0    0    0    1 0"/>
  </filter>
</svg>
<style>
  html { filter: url(#grayscale-color); }
  .keep-color { filter: invert(0%) hue-rotate(0deg) saturate(2); }
</style>

但这套机制在Safari里不稳定，跨浏览器一致性差。我个人的建议是：哀悼期间整站灰化最稳，不要试图保留个别元素的原色——这种特例反而显得不庄重。

不同饱和度档位的视觉效果

grayscale()的参数是0%-100%，不是非0即1的开关。我自己实测过几个档位的视觉差别：

• grayscale(100%)：完全黑白灰，最庄重但视觉冲击最强。适用于全国性大型哀悼日。
• grayscale(85%)：保留极少量色彩，整体仍然偏灰但不至于完全无色。适用于行业内或地方性哀悼。
• grayscale(70%)：明显去饱和但能感受到原色，比较温和。适用于持续较长时间（如一周）的纪念期，避免视觉疲劳。
• grayscale(50%)：浅度去饱和，更像是“素雅风格”而不是“哀悼”。这个档位不建议在正式哀悼场景用。

我个人最常用是100%，最庄重也最不会被解读为“不够诚意”。

性能影响：filter真的卡吗

很多人担心给html加filter: grayscale(100%)会让整个页面变卡，特别是滚动和动画。这个担心有道理但被夸大了。

实测数据（我用一台2018年的MacBook Pro测了几个站点）：

• 静态文字+图片站点：滚动帧率从60fps降到58-59fps，肉眼无感。
• 带轻量动画（hover transition）的站点：从60fps降到54-58fps，仔细看能感觉到一丝迟滞。
• 带重量级动画（视差滚动、canvas动画）的站点：从60fps降到40-48fps，明显能感受到卡顿。
• 视频播放页：视频解码不受filter影响，但每一帧叠加灰度会让低端设备的解码线程负担加重，4K视频卡顿率上升约15%。

结论是：对纯文字+图片的内容站点，filter影响可以忽略；对动画密集或视频密集的站点，需要权衡是否使用。如果你的站点是视频站，可以考虑只对页面框架区域加灰度，对视频播放器单独保留原色。

移动端的特殊考量

移动浏览器对filter的支持各家不一致：

• iOS Safari 9.1+：支持，性能好。
• Android Chrome 49+：支持，性能好。
• UC浏览器、QQ浏览器、华为浏览器：支持，但部分版本对滚动有轻微卡顿。
• 微信内置WebView：支持，但有些Android低端机型在滑动到底部时会触发"灰度刷新"，整页闪一下。

对微信内置WebView的闪烁问题，我自己的解决办法是给body加will-change: filter属性，提示浏览器提前为滤镜分配合成层：

html {
    filter: grayscale(100%);
    will-change: filter;
}

加了之后微信内置浏览器的闪烁基本消失，但代价是will-change会增加一点内存占用，所以哀悼结束后记得把这行去掉。

定时上下线脚本

哀悼日往往有明确的开始和结束时间，手工上下线容易忘记。我用一段简单的JS定时切换灰度：

<script>
(function() {
    var startUTC = Date.UTC(2026, 4, 12, 16, 0, 0); // 2026-05-13 00:00 北京时间
    var endUTC = Date.UTC(2026, 4, 13, 16, 0, 0);   // 2026-05-14 00:00 北京时间
    var now = Date.now();
    if (now >= startUTC && now < endUTC) {
        var s = document.createElement('style');
        s.textContent = 'html { filter: grayscale(100%); -webkit-filter: grayscale(100%); }';
        document.head.appendChild(s);
    }
})();
</script>

把这段嵌到header里之后，用户在指定时间段访问站点会自动看到灰度版本，过了结束时间脚本不再注入style标签。这样既不会忘记上线，也不会忘记下线。

但要注意一个边界：如果你的页面用了HTTP缓存（特别是CDN缓存），这段脚本生成的页面可能被缓存住，过了下线时间用户还能看到灰度版本。解决方法是把这段脚本放到document.write之外，或者干脆把灰度CSS也用JS动态注入而不是硬编码在HTML里。

常见的几类“灰度叠加翻车”案例

过去几年我维护客户站点时，见过几类典型的灰度部署翻车。归纳出来给同行避雷。

案例一：第三方嵌入的iframe不变灰

有些客户的站点里嵌了第三方iframe（地图、视频、第三方评论组件），灰度滤镜对父页面生效，但iframe里的内容仍然是彩色的。这是浏览器同源策略的限制——CSS filter无法跨frame边界生效。

正确的处理方式是给iframe外层包一个wrapper，给wrapper单独加filter：

.embed-wrapper {
    filter: grayscale(100%);
}
.embed-wrapper iframe {
    /* iframe 自身不需要再加 filter */
}

这样灰度滤镜会作用到包含iframe的盒子上，包括iframe渲染出来的内容（绘制阶段）。但要注意：跨域iframe的内部交互（比如地图上的悬停提示）可能因为浏览器渲染机制差异表现略微异常，需要逐个测试。

案例二：背景视频和Canvas动画完全不变灰

背景视频用video标签实现的，filter生效；但用canvas实现的实时动画（粒子背景、3D效果），filter作用于canvas元素而不是它绘制出来的位图，效果是“canvas边框变灰但内容不变”。要让canvas完全变灰，需要在canvas绘制脚本里手动把每一帧的RGB转成灰度——这需要改前端代码，工作量很大。

实际中我建议哀悼期间临时把canvas动画隐藏（CSSdisplay: none），等结束后再恢复，比改canvas渲染逻辑省事得多。

案例三：站点本身是深色模式的，灰度滤镜让它显得很压抑

原本就是黑底白字配色的站点，叠加灰度后视觉上“更黑”，用户会觉得页面发霉。建议这种站点在哀悼期间临时切换到浅色主题（如果支持），或者把灰度滤镜的强度降到grayscale(85%)+contrast(0.95)缓和压抑感。

无障碍考虑：色弱和色盲用户的体验

这一点经常被忽略但很关键。色弱和色盲用户本身就难以分辨颜色信息——你给整站加灰度滤镜，等于把他们最后能依赖的“明度对比”也削弱了。

具体来说：

• 红绿色弱用户依赖明度区分按钮和链接，灰度滤镜不会显著影响他们。
• 但低视力（弱视）用户依赖颜色对比度（特别是文字与背景的对比），如果你的原配色是绿底白字，灰度后变成中灰底浅灰字，对比度会从7:1掉到3:1以下，远低于WCAG AA标准。

建议哀悼期间额外加一段对比度强化CSS：

html {
    filter: grayscale(100%) contrast(1.1);
}

把对比度提10%，能补偿灰度滤镜带来的对比度损失，同时不会让画面显得太突兀。

哀悼场景之外：灰度滤镜的其他合理用法

除了哀悼日，全站或局部的灰度滤镜还有几个合理用法，分享一下：

用法一：禁用按钮的统一灰化处理。很多Web应用有"按钮在某些条件下变灰不可点击"的需求。把按钮的:disabled状态加filter: grayscale(80%) opacity(0.6)，比单独定义disabled色板更通用——对原色深、原色浅的按钮都能产生一致的"被禁用"视觉。

用法二：广告区域降视觉权重。有些内容站点希望广告区域不那么扎眼，可以给广告容器加filter: grayscale(40%)降低饱和度，同时鼠标悬停时:hover { filter: grayscale(0%); }恢复，既能引导用户视线集中在内容上又不影响广告点击意愿。

用法三：归档/已结束内容的视觉降级。新闻站点的旧文章列表、活动结束页的封面图，可以加filter: grayscale(60%)表达"已归档"含义，比"过期"标签更克制。

用法四：低带宽预览模式。给图片密集的站点提供一个"省流量模式"，启用后所有图片filter: grayscale(100%) contrast(0.9)，视觉上变灰但实际不影响图片下载量——只是让用户主观觉得"在低带宽模式下"。

常见问题解答

filter:grayscale(100%) 会影响图片的下载和渲染流程吗？

不会影响下载。CSS filter是渲染合成阶段的视觉处理，浏览器照常下载彩色图片，只是在最后绘制到屏幕时把RGB转成灰度值。所以图片的src还是彩色版本，用户右键“另存为”保存的也是彩色原图。

哀悼期间广告联盟代码能正常工作吗？计费会不会受影响？

能正常工作。CSS filter只影响视觉显示，不影响DOM结构和iframe内容。Google AdSense、百度联盟、阿里妈妈这些广告平台的曝光统计、点击统计都是基于事件触发，不依赖颜色。我之前在站点开过灰度的几天里，广告收入数据跟平时无异。

能不能只对首页变灰，对内页保留原色？

能。把<style>html { filter: grayscale(100%); }</style>只在首页模板里加，不要加到全局header里。但严格来讲这是“半哀悼”状态，国内主流大型站点都是全站灰化的——内页留原色容易被解读为不够诚意。建议要么做就全做，要么干脆不做。

视频网站做灰度处理会不会让视频内容也变灰？

会。CSS filter作用于整个DOM节点，包括video元素。如果你不希望视频本身变灰（很多新闻视频网站希望灰化页面框架但保留视频原色），需要给video标签或视频容器加filter: grayscale(0%)——但前面讲过子元素恢复filter的限制，效果有限。务实的做法是只给页面非视频区域（header、sidebar、footer、列表）加filter，视频播放器区域不加。

主题或CMS不允许改header怎么办？

用浏览器开发者工具临时测，但要永久应用还是得有改header的权限。如果完全没权限，唯一方案是用Cloudflare Workers或类似的边缘函数在响应里注入CSS，但这套设备成本和复杂度都比较高，不适合普通站点。

滤镜会让我的SEO排名受影响吗？

不会。Google的爬虫不会渲染CSS filter，只解析HTML和CSS文本，灰度滤镜对索引和排名没有影响。但要注意：如果你只在哀悼期间改了某些视觉元素的对比度（让按钮变得更难点），间接可能影响用户体验指标（CLS、LCP之外的Core Web Vitals），但这种影响很短期，不会带来长期排名损失。

做完灰度之后怎么彻底回到原色？需要做什么验证？

把html { filter: grayscale(100%); }这段CSS删掉或注释掉就行。验证步骤：第一，强制刷新（Ctrl+F5）确认浏览器没缓存旧CSS；第二，如果有CDN，去CDN控制台清掉缓存；第三，用不同浏览器（Chrome、Safari、移动浏览器）各打开一次确认全部恢复；第四，看看是否有其他地方（比如.title、img类似元素）也加过filter属性，需要一并移除。如果你用的是定时JS脚本，过了下线时间会自动失效，但建议手动清掉脚本以防万一。