★ FEATURED ARTICLE 1. 先厘清问题边界图标颜色为什么不能写死1.1 一个典型的需求现场做桌面端主题化的时候最先炸的往往不是布局也不是字体而是图标。深色主题一开原本灰黑色的图标直接消失在背景里强调色一换侧边栏那排图标还是老样子禁用态的按钮图标和可用态长得一模一样用户根本分不清哪里能点。这类问题的根子不在界面层而在Qt-Material图标资源系统对 SVG 图标动态颜色替换这件事上有没有做对。我见过不少项目是这么处理的每种颜色导出一套 SVG浅色一套、深色一套、强调色再来一套文件名后缀_dark、_light、_primary。短期能跑中期资源体积翻三倍长期没人知道到底该引用哪一份。只要主题体系里多一个颜色维度比如高对比度模式这套方案立刻崩盘。真正的解法是把 SVG 当成模板而不是成品磁盘上只存一份单色的形状描述颜色在运行时注入。这篇文章要讲的就是这条链路上每一环该怎么做、为什么这么做、哪里会翻车。内容面向已经上手 Qt Widgets 或 QML、准备给自己的应用做一套完整主题体系的人也面向那些已经有一套图标系统但被颜色问题反复折磨的人。1.2 图标资源系统在整个主题架构里的位置把主题拆开看它至少有三层颜色令牌层、控件样式层、资源层。颜色令牌层定义primary、onSurface、outline这些语义化的名字控件样式层把它们映射到具体控件资源层负责图标、图片、字体。绝大多数主题框架的前两层做得不错第三层却经常被忽略因为它看起来只是几个静态文件。问题在于图标是唯一一种既是形状又是颜色的资源。字体可以靠字号和字重区分图片一般不做变色处理只有图标既要求形状随尺寸缩放不失真又要求颜色跟着主题走。它必须被纳入令牌体系而不能游离在外。一旦你承认这一点每套颜色一份文件的方案就自动出局了因为令牌是运行时可变的而文件是编译期固定的。所以资源层的正确抽象是图标 形状数据 颜色参数 渲染结果。形状数据来自磁盘上的 SVG颜色参数来自当前主题令牌渲染结果是一个按需生成、带缓存的位图。三者的生命周期完全不同混在一起管理必然出问题。1.3 三条可选技术路线的取舍在动手之前值得把可选路线摆清楚因为选错了后面全是补丁。第一条是字符串替换SVG 本质是 XML 文本把里面的fill#000000或currentColor换成目标颜色再交给渲染器。优点是能保留多色图标的原始配色逻辑缺点是要处理正则边界容易误伤。第二条是合成上色先用渲染器把原始 SVG 渲染成一张带 Alpha 的位图再用QPainter的CompositionMode_SourceIn把目标颜色灌进所有不透明区域。优点是绝对稳不会误伤任何属性缺点是只适用于单色图标多色图标会被压成一整块纯色。第三条是运行时着色器QML 侧用ShaderEffect或MultiEffect在 GPU 上做颜色映射。优点是切换颜色零成本、可做动画缺点是需要 OpenGL 或 RHI 后端支持在软件渲染模式下会退化而且 Widgets 侧完全用不了。我自己的实际选择是合成上色做主力字符串替换做补充着色器只在需要颜色过渡动画的少数场景用。理由很直接——绝大多数界面图标本来就是单色的合成上色覆盖了八成以上需求且零风险剩下那些确实需要多色的品牌图标走替换法单独标注。下面几章就围绕这个组合展开。2. SVG 动态着色的核心原理拆解2.1 SVG 是文本这是替换法成立的前提很多人把 SVG 当二进制资源看其实它就是纯文本。你可以用任何文本编辑器打开它看到path dM12 2L2 22h20z fill#000000/这样的内容。这个事实带来一个非常实用的能力颜色可以在加载阶段被改写。但替换法有两个必须提前处理好的边界。第一个边界是属性值本身。fillnone表示不填充如果你无脑把所有fill...替换成目标色原本镂空的图形会被填满图标直接变成一块实心方砖。所以正则里必须带负向前瞻排除none。第二个边界是颜色写法的多样性同一个颜色可能写成#000、#000000、rgb(0,0,0)、black甚至写在stylefill:#000里。真正稳妥的做法是约定模板规范所有新图标统一用currentColor作为占位符只替换这一个关键字其余写法一律不允许入库。// 只替换约定占位符绝不碰其它颜色 QByteArray svg file.readAll(); const QByteArray hex color.name(QColor::HexRgb).toLatin1(); // #RRGGBB svg.replace(currentColor, hex);这样做的好处是把替换从一个模糊的文本操作变成了一个精确的契约。模板里写了currentColor就会被着色没写就保持原样。新加图标时忘了写占位符视觉上会立刻暴露而不是等到某个主题下才发现颜色不对。顺带说一个资源制作上的细节导出 SVG 时一定要选纯 SVG而不是带编辑器元数据的格式。带元数据的文件里会有大量编辑器私有的命名空间和注释虽然不影响渲染但会让替换逻辑的匹配范围变得不可控也白白撑大了资源体积。2.2 合成上色把颜色灌进 Alpha 通道合成上色的思路完全不同不碰文本只碰像素。先用QSvgRenderer把 SVG 渲染到一张透明的 ARGB 位图上此时图形是有颜色的可能是黑色然后用QPainter把合成模式设成SourceIn画一个铺满整张位图的纯色矩形。SourceIn的含义是新绘制的内容只在目标已有的不透明区域内可见透明度按目标的 Alpha 值加权。结果就是——原来不透明的部分不管原本是什么颜色全部被目标色覆盖原来透明的部分保持透明抗锯齿产生的半透明边缘会得到一个平滑的颜色过渡。这就是为什么它能保留图标的清晰轮廓而不是像二值化那样出现毛边。这套方案的关键前提有两个。一是位图必须是预乘 Alpha 格式。QImage::Format_ARGB32_Premultiplied在合成运算时性能最好也最不容易出现边缘发黑。如果用了非预乘格式半透明边缘的颜色分量和 Alpha 值不匹配SourceIn之后就会出现一圈灰黑色描边尤其是在深色主题下特别明显。二是SVG 的多个图层会被压平。如果你的图标里有半透明的装饰层合成上色会把它一并染成单色原本的层次感就没了。所以判断标准很清楚形状由单一路径构成、只靠轮廓区分信息的图标走合成上色带渐变、带多色语义的图标走字符串替换或者干脆保持原色。在一个成熟的主题体系里前者应该占绝对多数。2.3 两条路线的实战对照把两条路线放在一起对比很多决策就清楚了。下表是我在实际项目里总结的对照可以作为选型依据。维度字符串替换法合成上色法适用范围单色、多色图标均可仅单色图标多色保留保留原始配色逻辑全部压平为单色抗锯齿边缘质量取决于原图优秀平滑过渡实现复杂度中等需处理正则边界低几行代码出错风险误伤其它属性几乎无半透明图层保留被合并运行开销文本解析 渲染仅渲染 一次填充我的实际配置是资源目录里用两个子目录分开管理icons/mono/下的全部走合成上色icons/multi/下的走字符串替换。目录即策略调用方不需要额外传参避免了这个图标该用哪种方式的心智负担。3. 图标资源系统的工程化实现3.1 资源目录与命名规范很多人低估了命名规范的重要性。当图标数量超过两百个之后哪个文件对应哪个功能本身就成了一个检索问题。我的做法是照搬成熟的图标命名体系分类目录 动作描述 可选变体全部小写用下划线分隔。:/icons/ mono/ action/ add.svg delete.svg settings.svg navigation/ arrow_back.svg menu.svg status/ check_circle.svg error.svg multi/ brand/ logo_full.svg分类目录不是为了好看是为了让缓存和热点统计有意义。实际使用中action和navigation两类几乎占了全部调用量的九成而status类只在状态变化时才会刷新。如果混在一个平铺目录里你很难做出针对性的优化。另一个细节是文件内不能依赖外部引用。有些设计工具导出的 SVG 会引用外部样式表或者use一个外部 symbol 定义这种文件在独立渲染时要么缺色要么缺形状。入库前统一做一次内联化处理把所有样式和引用都展开到同一个文件里这是保证渲染结果可预期的前提。3.2 缓存设计key 怎么拼、容量怎么控图标渲染是纯计算但没有缓存的话开销相当可观。一张 24 逻辑像素、设备像素比 2 的图标渲染过程要经历 SVG 解析、路径栅格化、抗锯齿合成单次大约在毫秒量级。一个列表页有三十行每行三个图标滚动时每秒刷新几十帧累加起来就是灾难。缓存的 key 必须完整覆盖所有影响渲染结果的变量缺一个就会命中错误的缓存产生颜色不对图标模糊这类诡异现象。完整的 key 应该包含四项图标名、颜色、逻辑尺寸、设备像素比。QString cacheKey(const QString name, const QColor c, int size, qreal dpr) { // 用 rgba() 而不是 name()因为 name() 会丢掉 Alpha return QStringLiteral(%1#%2#%3%4) .arg(name, QString::number(c.rgba()), QString::number(size), QString::number(dpr, f, 2)); }这里有个小坑值得单独说颜色字符串千万别用QColor::name()。它返回的是#RRGGBB不含 Alpha。如果你的主题里有半透明图标比如禁用态用 38% 透明度用name()做 key 会导致 38% 和 100% 的黑命中同一条缓存禁用态看上去和正常态一模一样。用rgba()返回 32 位整数就没这个问题。容量控制上QCache是最省事的选择。它会自动淘汰最久未使用的条目你只需要给一个合理的上限。上限怎么定算一下就知道了一张 24 逻辑像素、dpr 2 的图标渲染出来是 48×48ARGB32 每像素 4 字节单张约 9.2 KB。设上限 1024 条最坏情况约 9.4 MB——对桌面应用完全可以接受对嵌入式就要再压一压降到 256 条约 2.4 MB。注意QCache的容量参数是条目数不是字节数。如果你的图标尺寸差异很大既有 16 像素的小图标也有 128 像素的空状态大图单纯按条目数限制可能失控这时候应该按尺寸分桶每个桶单独设上限。3.3 高 DPI 与多尺寸策略高分屏是图标系统最容易出事的地方。核心原则只有一条渲染尺寸 逻辑尺寸 × 设备像素比然后在结果上标回设备像素比。少了后一步Qt 会把一张已经放大的图再按逻辑尺寸摆放图标就糊了少了前一步图本身就没跟上屏幕密度同样糊。const int px qRound(logicalSize * dpr); // ... 渲染到 px × px 的位图 ... pm.setDevicePixelRatio(dpr); // 关键告诉 Qt 这张图是为几倍屏准备的qRound而不是直接截断是为了避免在 1.25、1.5 这类非整数倍率下反复向下取整导致图标缩了一号。实际测试中24 像素图标在 125% 缩放下正确尺寸是 30 像素用static_castint取整同样是 30但在 1.375 倍率下就是 33 和 33差别不大真正出问题的是 1.1、1.3 这种倍率取整误差累积后视觉上能看出来。另一个常见需求是同一个图标要在多个尺寸下使用比如工具栏 24 像素、菜单 16 像素、空状态 96 像素。这里不要想着渲染一张大的然后缩小缩小的结果一定是糊的。正确做法是每个尺寸独立渲染、独立缓存。SVG 本来就是矢量的渲染多少次都不会损失精度唯一成本就是那点计算量被缓存一挡几乎为零。如果要构造QIcon给 Widgets 侧用可以用addPixmap挂多个尺寸让 Qt 在不同场景下自动挑选QIcon icon; for (int s : {16, 24, 32, 48}) { icon.addPixmap(renderColored(name, color, s, dpr), QIcon::Normal, QIcon::Off); } // 禁用态单独给一个降低透明度的版本 icon.addPixmap(renderColored(name, disabledColor, 24, dpr), QIcon::Disabled, QIcon::Off);4. 完整实操搭一条可复现的着色管线4.1 第一步准备模板 SVG 与资源清单资源这一步看着枯燥但做错了后面全要返工。具体动作有这么几件。打开每个待入库的 SVG确认里面所有需要着色的fill和stroke都改成了currentColorfillnone保持不动删掉所有编辑器添加的注释、元数据、命名空间声明。改完之后用一个最小化的渲染脚本过一遍确认形状没坏。然后写资源清单。Qt 用.qrc文件管理资源把整个icons目录挂进去RCC qresource prefix/icons filemono/action/add.svg/file filemono/action/delete.svg/file !-- 其余略 -- /qresource /RCC清单里有一件事值得提前做给每个图标登记所属策略。可以在代码里用一个静态映射表也可以直接在目录上体现mono/和multi/。我更倾向后者因为目录结构本身就是文档新人接手时看一眼就明白不需要翻代码。还有一点容易被忽略currentColor在标准 SVG 里是有语义的它表示沿用父元素的 color 属性。但QSvgRenderer并不完整实现 CSS 继承它只做基本的 XML 解析和渲染。所以不能指望它自己去解析currentColor必须由我们在加载阶段就替换成具体色值。这是替换法必须存在的原因不是可选项。4.2 第二步实现核心着色函数下面这段是整套系统的核心两种策略各一个函数输入输出保持一致上层调用无感知。// icon_renderer.h #pragma once #include QPixmap #include QColor #include QString class IconRenderer { public: // 单色图标先渲染再合成上色 static QPixmap renderMono(const QString resPath, const QColor color, int logicalSize, qreal dpr); // 多色图标替换 currentColor 占位符后渲染 static QPixmap renderMulti(const QString resPath, const QColor color, int logicalSize, qreal dpr); };// icon_renderer.cpp #include icon_renderer.h #include QSvgRenderer #include QPainter #include QFile #include QImage QPixmap IconRenderer::renderMono(const QString resPath, const QColor color, int logicalSize, qreal dpr) { QSvgRenderer renderer(resPath); if (!renderer.isValid()) return {}; const int px qRound(logicalSize * dpr); if (px 0) return {}; // 关键点一预乘 Alpha避免半透明边缘发黑 QImage canvas(px, px, QImage::Format_ARGB32_Premultiplied); canvas.fill(Qt::transparent); { QPainter p(canvas); p.setRenderHint(QPainter::Antialiasing, true); p.setRenderHint(QPainter::SmoothPixmapTransform, true); renderer.render(p, QRectF(0, 0, px, px)); } // 关键点二SourceIn 只在已有不透明区域内着色 { QPainter p(canvas); p.setCompositionMode(QPainter::CompositionMode_SourceIn); p.fillRect(canvas.rect(), color); } QPixmap pm QPixmap::fromImage(canvas); pm.setDevicePixelRatio(dpr); // 关键点三 return pm; }renderMulti的结构类似区别在渲染前的文本处理QPixmap IconRenderer::renderMulti(const QString resPath, const QColor color, int logicalSize, qreal dpr) { QFile f(resPath); if (!f.open(QIODevice::ReadOnly)) return {}; QByteArray svg f.readAll(); const QByteArray hex color.name(QColor::HexRgb).toLatin1(); svg.replace(currentColor, hex); QSvgRenderer renderer(svg); // 直接从内存构造 if (!renderer.isValid()) return {}; const int px qRound(logicalSize * dpr); QImage canvas(px, px, QImage::Format_ARGB32_Premultiplied); canvas.fill(Qt::transparent); QPainter p(canvas); p.setRenderHint(QPainter::Antialiasing, true); renderer.render(p, QRectF(0, 0, px, px)); p.end(); QPixmap pm QPixmap::fromImage(canvas); pm.setDevicePixelRatio(dpr); return pm; }这里有一个性能优化点值得提renderMono里每次都要重新构造QSvgRenderer并解析 SVG这是整个流程里最重的部分。如果某个图标被频繁以不同颜色渲染可以把QSvgRenderer实例按资源路径缓存起来。但要注意QSvgRenderer不是线程安全的只能在同一个线程内复用跨线程共享会直接崩。4.3 第三步接上缓存与对外接口有了渲染函数外面还要包一层带缓存的入口否则每次绘制都重新渲染性能优化等于没做。class IconCache { public: static IconCache instance() { static IconCache inst; return inst; } QPixmap get(const QString name, const QColor color, int size, qreal dpr) { const QString key cacheKey(name, color, size, dpr); if (QPixmap *hit m_cache.object(key)) return *hit; const QString path resolvePath(name); QPixmap pm isMono(name) ? IconRenderer::renderMono(path, color, size, dpr) : IconRenderer::renderMulti(path, color, size, dpr); if (!pm.isNull()) m_cache.insert(key, new QPixmap(pm), 1); return pm; } void invalidateAll() { m_cache.clear(); } private: IconCache() : m_cache(1024) {} QCacheQString, QPixmap m_cache; };invalidateAll()是主题切换时的关键动作。主题一换所有令牌颜色都变了旧缓存全部作废。这里不要图省事做按颜色精确清除因为颜色可能只是变了明度语义完全一样逐个比对反而容易漏。Widgets 侧的接入就一步QIcon makeIcon(const QString name, const QColor color, int size 24) { QIcon icon; const qreal dpr qApp-devicePixelRatio(); for (int s : {size, size * 2}) { icon.addPixmap(IconCache::instance().get(name, color, s, dpr), QIcon::Normal, QIcon::Off); } return icon; }4.4 第四步QML 侧的接入方式QML 这边麻烦一点因为Image的source是 URL不能直接传一张已经渲染好的位图。标准做法是注册一个QQuickImageProvider把参数编进 URL。class IconProvider : public QQuickImageProvider { public: IconProvider() : QQuickImageProvider(QQuickImageProvider::Pixmap) {} QPixmap requestPixmap(const QString id, QSize *size, const QSize requestedSize) override { // id 形如 mono/action/add-ff5722-24 const QStringList parts id.split(-); if (parts.size() 3) return {}; const int sz requestedSize.isValid() ? requestedSize.width() : 24; const QColor c(QStringLiteral(#) parts.at(parts.size() - 2)); const QString name parts.mid(0, parts.size() - 2).join(-); QPixmap pm IconCache::instance().get(name, c, sz, qApp-devicePixelRatio()); if (size) *size pm.size(); return pm; } };QML 侧这样用Image { width: 24 height: 24 source: image://maticons/action/add-ff5722-24 // 主题切换时这个属性变化Image 会自动重新请求 property string themeColor: Theme.onSurface }注意这里有一个极其容易踩的坑。如果你把颜色写成#ff5722直接拼进 URL#会被 QML 当作 URL 的 fragment 分隔符provider 收到的id会被截断你会看到图标全是黑的或者根本加载不出来。解决办法是用 URL 编码的%23或者干脆在拼接时去掉#provider 里再补回来——就像上面代码那样。4.5 第五步主题切换时的联动刷新前面几步做完单个图标已经能正确渲染了但主题切换时整片界面不会自己更新。原因很简单缓存里还是旧颜色的位图QML 侧绑定没有失效Image不会重新请求。Widgets 侧相对简单主题切换信号触发后调用invalidateAll()然后遍历顶层窗口调用update()控件重绘时会重新走makeIcon。QML 侧需要显式让绑定失效。我的做法是在主题单例里放一个自增的generation属性所有图标的 URL 都依赖它Image { source: image://maticons/ Theme.iconUrl(action/add, 24) }Theme.iconUrl内部会把generation拼进去主题一变generation加一所有依赖它的绑定自动重新求值URL 变了Image重新请求。这样不用手动遍历界面元素新增的图标也自动生效。还有一点主题切换那一瞬间会有明显的闪烁因为所有图标都在同一帧里重新渲染。缓解办法是提前预热——在切换前把新主题下最常用的二三十个图标先渲染进缓存。实测下来这一招能让切换从能看出卡顿变成几乎无感。5. 踩坑实录与排查速查表5.1 颜色没变、变一半、变错地方这三类现象看着像同一个问题成因完全不同混在一起排查会浪费大量时间。颜色完全没变先查缓存。很可能 key 里漏了颜色维度或者用了QColor::name()导致不同透明度命中同一条。再查调用链QML 侧 URL 变了但Image的cache属性为true可能仍在用旧的解码结果。最后一个可能是主题令牌本身没更新图标系统背了锅。只变了一半典型原因是 SVG 里既有currentColor又有硬编码色值。字符串替换只认占位符硬编码的部分原样保留于是出现了一半红一半黑的图标。这种情况必须回资源层改文件代码层没有干净的解。变错了地方通常是合成上色时SourceIn覆盖了不该覆盖的东西。比如 SVG 里有一层全画布的透明矩形做背景虽然 Alpha 为 0但如果渲染器处理不当合成后整块区域会被染色图标变成一个实心方块。遇到这种把那一层删掉重新导出即可。5.2 边缘毛刺、模糊与黑边黑边是最经典的问题九成以上是位图格式没用预乘 Alpha。Format_ARGB32存储时颜色分量没有乘以 Alpha半透明边缘的 RGB 值和 Alpha 不匹配SourceIn混合后边缘就浮出一圈深色。改用Format_ARGB32_Premultiplied基本能解决。模糊则要往 DPI 方向查。要么渲染时没乘dpr要么乘了但没调setDevicePixelRatio。判断方法很简单把窗口拖到另一块不同缩放比的屏幕上如果图标突然变清晰或者变糊就是 DPI 处理有问题。毛刺更少见一些通常是Antialiasing没开或者渲染矩形用了整数坐标导致路径落在像素边界上。把p.setRenderHint(QPainter::Antialiasing, true)加上渲染矩形用QRectF而不是QRect基本能消除。5.3 问题排查速查表下面这张表是我自己整理的高频问题对照遇到现象先按表定位能省掉大半的调试时间。现象最可能的原因快速验证方式处理办法图标全黑或全白URL 中的#被当作 fragment 截断打印 provider 收到的 id去掉#或用%23编码禁用态和正常态一样缓存 key 用了QColor::name()打印 key 字符串换成rgba()深色主题下图标消失图标颜色写死为深色换主题观察改用onSurface令牌图标边缘有灰黑描边位图非预乘 Alpha查QImage::Format改ARGB32_Premultiplied高分屏图标模糊未乘dpr或未回写拖到不同缩放屏幕补qRound(size*dpr)和setDevicePixelRatio图标变成实心方块fillnone被替换掉打开 SVG 查属性正则加负向前瞻主题切换卡顿明显缓存全清后批量重渲染打日志统计耗时提前预热常用图标滚动列表掉帧未命中缓存每帧重渲染统计renderMono调用次数检查缓存 key 是否稳定多色图标变单色误用了合成上色策略查目录归属移到multi/目录走替换法图标大小差一像素渲染尺寸未取整打印实际 px 值用qRound而非截断5.4 几条只有踩过才知道的经验别在工作线程里创建QPixmap。QPixmap依赖图形后端只能在 GUI 线程构造。如果你的图标渲染放在线程池里做渲染阶段的产物必须是QImage回到 GUI 线程再转QPixmap。我见过不止一个项目在子线程里QPixmap::fromImage在部分平台上直接崩在另一些平台上不崩但行为诡异极难定位。QSvgRenderer构造时如果传的是文件路径它会自己打开文件。这意味着如果你的资源在.qrc里路径得用:/icons/...的形式不能是磁盘绝对路径。有些人为了方便调试把路径写成磁盘绝对路径打包后资源不存在图标全空还以为是资源没编译进去。禁用态的图标不要只降低透明度。在浅色主题下把黑色降到 38% 透明度看起来是淡灰勉强能区分但在深色主题下同样的白降到 38%几乎和背景分不开。正确做法是禁用态使用独立的令牌色比如onSurface再叠加一层surface让它在任何主题下都保持足够的对比度差异。图标尺寸别用非整数。width: 22.5这种写法在 QML 里是合法的但图标渲染时会取整到 23 或者 22和相邻元素对不齐整行看起来就是歪的。工具栏、菜单、列表项统一用 16、20、24、32 这几档不要为了视觉微调破坏这个约定。缓存清理要跟着主题走不要跟着控件走。有些实现是在控件析构时清自己的图标缓存结果同一个图标在十个控件里渲染了十次。缓存应该是全局的、按 key 索引的、随主题整体失效的和控件生命周期完全解耦。6. 让这套系统更耐用的几个扩展方向前面讲的是一条能跑通的最小闭环。真要用上两三年还得往外扩。图标别名层。业务代码里不要直接写action/add而是写语义化的icon.add中间用一个映射表转。好处是换图标时不用改业务代码废弃一个图标也只需要把映射指向新的。这件事在图标数量破百之后价值会非常明显。图标与文字的对齐约束。图标单独看都对放到按钮里就容易上下不齐。原因是图标的视觉重心和几何中心往往不重合。解决办法是在 SVG 里留出统一的留白比如 24×24 的画布图形限制在 20×20 的安全区内这样所有图标放进容器后自动对齐不需要每个地方手动调padding。构建期的资源体检。在编译流程里加一个脚本扫描所有 SVG检查三件事是否含currentColor、是否残留编辑器元数据、是否存在硬编码色值。发现问题直接让构建失败。这一招能在资源入库那一刻就把问题拦住比上线后靠肉眼发现靠谱得多。颜色令牌与图标解耦到配置层。把哪个语义用哪个色抽成一份 JSON 或者 YAML运行时加载。这样产品经理想调整警告图标用哪个橙色改配置就行不用重新编译。配置文件里还可以加一档高对比度覆盖辅助功能需求一并解决。我个人在实际操作中的体会是这套系统的复杂度不在渲染本身那部分代码加起来不到两百行真正花时间的是资源规范、缓存策略和跨主题的一致性验证。前期在资源规范上多花两天后面能省掉两个月的返工。尤其那个所有图标必须写currentColor的约定看着是小事实际上它决定了整套系统能不能自动化运转——只要有一个文件破了规矩后面所有的批量处理都要加上例外判断复杂度会指数级上升。
阅读完成 · 觉得有帮助？
