不能——CSS滤镜函数按声明顺序串行执行，sepia()会压缩色域，再叠加hue-rotate()易导致色相失控、发紫或无变化；精细调色需用canvas手动处理。
sepia() 和 hue-rotate() 能直接叠加吗？
不能——CSS滤镜函数不是独立图层，而是按顺序串行执行的线性操作。写成 filter: sepia(1) hue-rotate(90deg)，浏览器会先对原图做灰度+棕褐色调处理，再对这个结果整体旋转色相，不是“在 sepia 基础上微调某个颜色区域”。
常见错误现象：hue-rotate(180deg) 加在 sepia(1) 后，本想让棕褐变青灰，结果画面发紫、肤色崩坏——因为 sepia 已经大幅压缩了色域，再 rotate 只是在窄色带上硬拧，失去控制。
- sepia() 本质是矩阵变换，把 RGB 映射到固定棕褐倾向的值，饱和度和色相自由度已严重受限
- hue-rotate() 对低饱和/单色调图像效果极弱，甚至看不出变化
- 想局部调色？CSS filter 没有“蒙版”或“通道选择”，做不到
什么时候该用 sepia + hue-rotate 组合？
仅适用于：原始图像本身色彩丰富、明暗对比清晰，且你只要一个粗略的“复古偏色”氛围，不追求精确色相控制。比如老电影海报缩略图、博客文章配图的轻量风格化。
使用场景示例：img.thumbnail { filter: sepia(0.6) hue-rotate(-15deg); } —— 0.6 保留部分原色，-15deg 把过暖的棕褐往黄绿方向压一点，比纯 sepia(1) 更耐看。
立即学习“前端免费学习笔记（深入）”；
- sepia 值建议控制在 0.3–0.7，太高会导致后续 rotate 失控
- hue-rotate 推荐 ±10deg 到 ±30deg，超过 45deg 容易出现意外色块
- 务必搭配
contrast()或brightness()补偿——sepia 会让图像变灰平，加contrast(1.1)能恢复层次
Chrome 和 Safari 对 filter 顺序的处理一致吗？
一致。所有现代浏览器都严格按 CSS filter 声明中的函数书写顺序执行，sepia(1) brightness(1.2) 和 brightness(1.2) sepia(1) 效果完全不同——前者先染色再提亮（棕褐更透），后者先提亮再染色（高光区域可能过曝发白）。
容易踩的坑：filter: url(#myFilter) sepia(1); 这种混合 SVG 滤镜和 CSS 函数的写法，在 Safari 中可能被忽略后半部分，或触发渲染异常；不要混用。
- 只用纯 CSS filter 函数时，顺序即执行逻辑，改顺序 = 改结果
- Firefox 早期版本（
- 移动端 WebView（尤其 Android 旧版）对 >3 个 filter 函数叠加可能出现性能抖动，建议控制在 3 个以内
真要精细控制 sepia 后的色调，该怎么办？
放弃纯 CSS filter。用 canvas 手动实现：先 drawImage，再 getImageData，遍历像素做自定义色相偏移（比如只对 R>100 且 G
简单替代方案：background-image: linear-gradient(hsla(120, 100%, 50%, 0.1), transparent), url(...); 配合 sepia，用半透色层“盖”出倾向性，比硬 rotate 更可控。
- CSS 里没有“sepia 后单独调蓝色通道”的语法，这是根本限制
- 如果项目已用 PostCSS，可考虑插件如
postcss-filters预编译生成兼容矩阵，但仍是静态方案 - 最省事的妥协：用两套图片——一套正常，一套用 PhotoShop 手动调好色导出，CSS 仅负责切换
复杂点在于：你没法用一行 CSS 解决“既要棕褐基调，又要让天空偏青、皮肤偏暖”这种需求。滤镜是全局运算，不是图层混合。
