
做3D打印、逆向建模或者机械结构设计的人硬盘里大概率都躺着一个塞满STL文件的模型库。真到了要找某个零件的时候打开Windows资源管理器一看几百个文件全是清一色的白色图标名字还都叫 model_01、part_final、part_final_2 这种只能一个个双击打开切片软件或者建模软件去确认。为了让Windows资源管理器直接显示3D模型缩略图也就是让STL文件预览变成文件夹里一眼看穿的效果我前后试过五六种方案从装现成的Shell扩展、自己写注册表到干脆批量转格式生成封面图踩过的坑足够写一篇完整记录了。这篇内容面向的是手上有大量STL素材、又不想每次都开软件确认的从业者也适合刚接触3D打印、想把素材库整理利索的新手从原理到实操到排错我会把每一步为什么这么做讲透。1. 先搞清楚为什么资源管理器对STL视而不见1.1 STL是一个只有骨架、没有皮肤的文件很多人第一反应是Windows不支持3D格式这个理解只对了一半。资源管理器能不能显示缩略图跟文件是不是3D模型没关系关键在于系统里有没有为这个扩展名注册一个缩略图提供程序。图片之所以能显示是因为系统内置了针对jpg、png的处理程序PDF能显示是因为装了阅读器之后阅读器顺手注册了自己的缩略图处理器。STL属于典型的系统默认不管的格式装上建模软件也不会自动接管所以它只能退回默认图标。再往深一层看STL这个格式本身也确实不太友好。它本质上是一堆三角面片的坐标集合二进制格式的结构极其朴素开头80字节的文件头很多导出器往里塞注释甚至塞满空格接着4字节记录三角形数量然后每个三角形固定占50字节——12字节法向量、36字节三个顶点的XYZ坐标、2字节属性字段。整份文件里没有颜色、没有材质、没有贴图、没有相机角度也没有这个模型长什么样的任何提示信息。这意味着什么意味着任何缩略图方案都必须现场把几何数据读出来、算包围盒、摆好视角、打光、光栅化成一张位图。这不是读个元数据那么轻松而是一次小规模的三维渲染。ASCII格式的STL更麻烦文本逐行描述 facet normal、outer loop、vertex 这些关键字文件体积通常是二进制的五到六倍一个中等复杂度的模型轻松几十兆解析起来更慢。这里有个经典坑得提前说判断STL是ASCII还是二进制不能只看开头是不是solid。大量二进制导出器也会在80字节文件头里写以 solid 开头的字符串一刀切按文本解析会直接崩掉。最稳的判定方式是拿文件总长度去对如果 文件大小 84 50 × 三角形数量那基本可以确定是二进制对不上再按ASCII走。这个判断逻辑后面讲排查的时候还会用到因为不少自制或老版本的缩略图扩展就是在这一步翻车的。1.2 三条技术路线的取舍在动手之前我先把可选方案摊开对比了一遍。不同人的诉求差别很大有人只想偶尔瞄一眼有人是要管理上千个文件的素材库方案选错了后面全是返工。路线具体做法覆盖范围上手难度性能开销适合谁系统级缩略图扩展装一个实现 IThumbnailProvider 的Shell扩展注册到 .stl 的 ShellEx 键下全局生效所有文件夹、所有打开/保存对话框都能看到中需要管理员权限可能要手动注册首次生成有开销之后走缓存素材库重度用户、天天跟STL打交道的人外挂式预览工具独立小工具选中文件按空格或快捷键弹出3D预览窗仅在该工具内生效低装完即用随用随加载几乎不占常驻内存偶尔看一眼、不想动系统的人转格式或预生成封面把STL批量转成系统认识的格式或者用脚本渲染出一张PNG放旁边取决于转换目标低到中需要脚本一次性批量处理之后零开销归档型素材库、要分享给不装工具的人我最终走的是第一条路线理由很实在缩略图扩展是一次配置、长期受益的东西装完之后资源管理器的行为跟原生支持没区别打开文件对话框选模型的时候也能直接看图这个体验提升是外挂工具给不了的。第二条路线的优势是零风险卸载干净不留痕适合先试水。第三条路线听起来笨但对归档场景其实特别靠谱——转出来的封面图可以跟着文件一起备份、一起同步换台机器、换个系统照样能看到不依赖任何环境。至于为什么不推荐把STL全转成OBJ这种思路因为转换过程会丢精度、改文件大小、破坏原有的引用关系素材库一旦规模上去转换本身就是个维护负担。缩略图扩展是在显示层解决问题不动原始数据这是它最核心的价值。注意这里说的缩略图扩展是64位进程加载的组件。64位系统上的资源管理器是64位进程32位的扩展哪怕注册成功也不会被加载装之前一定要确认位数。2. 缩略图背后的机制Windows是怎么把一张图塞进文件夹的2.1 从打开文件夹到出图的完整链路理解这条链路后面所有排错都会变得有章可循。当你打开一个文件夹、切到大图标或中等图标视图时资源管理器并不是自己去读文件而是走一套标准的COM组件调用流程。第一步它看当前视图需不需要缩略图。如果文件夹选项里勾了始终显示图标从不显示缩略图或者性能选项里关掉了缩略图显示流程到这里就终止了这也是装完没反应最高频的原因后面单独讲。第二步它按扩展名去注册表里找缩略图处理器位置是 HKEY_CLASSES_ROOT.stl\ShellEx\ 下面那个固定的GUID子键 {e357fccd-a995-4576-b01f-234630154e96}读它的默认值拿到一个CLSID。第三步用这个CLSID去 HKEY_CLASSES_ROOT\CLSID\ 下找到组件的注册信息加载对应的DLL创建实现了 IThumbnailProvider 接口的对象调用它的 GetThumbnail 方法。第四步是关键一步GetThumbnail 会收到一个 cx 参数告诉你我要多宽的图组件得按这个尺寸返回一个 HBITMAP 句柄。资源管理器拿到位图之后不会每次都用而是写进缩略图缓存数据库位置在 %LocalAppData%\Microsoft\Windows\Explorer\ 目录下文件名是 thumbcache_ 加一串尺寸标识比如 thumbcache_96.db、thumbcache_256.db、thumbcache_1024.db不同视图尺寸对应不同文件。这套机制解释了一大堆看起来诡异的现象。为什么改了文件内容缩略图还是旧的因为缓存没失效。为什么同一个文件在小图标视图正常、大图标视图空白因为不同尺寸的缓存是分开的某一个尺寸的缓存文件损坏了。为什么移动文件到另一个盘之后缩略图重新生成了一遍因为缓存键里带了路径信息。搞明白注册表定位 → COM加载 → GetThumbnail渲染 → 缓存落盘这四段排查的时候就知道该在哪一段下手了。2.2 一个STL缩略图处理器必须扛住的四件事如果只是自己用随便找个现成的装上就行但如果你想评估一个扩展靠不靠谱或者哪天想自己写一个得知道合格线在哪。我拆过几个不同的实现发现真正决定体验的就四件事。第一件是格式判定的鲁棒性。前文提过靠solid开头判断ASCII是错的。好的实现会先做长度校验再做头部采样对那种文件头塞满随机字节、三角形数量字段跟实际长度对不上的损坏文件要能优雅地放弃而不是让资源管理器卡死或者崩溃。资源管理器里加载扩展崩溃的后果是整片文件夹变白甚至拖慢整个桌面这个代价很高。第二件是包围盒和视角的归一化。模型的坐标可能是毫米级一个50mm的零件坐标范围-25到25也可能是米级一个建筑设计模型坐标几千甚至是从CAD导出来的、原点在十万八千里之外的偏移坐标。不归一化直接渲染出来的图要么是个小点要么完全在画面外。正确做法是算三个轴的最小最大值得到包围盒把模型平移到原点、按最大边长缩放到统一尺寸再看情况给一个固定角度的透视图或者等轴测视角。等轴测视角的好处是同一个模型每次渲染结果一致看图的时候不会有这个零件好像跟上次长得不一样的错觉。第三件是面片数量的控制。一个精细的3D扫描模型动辄上百万三角面片几十兆上百兆的文件如果 GetThumbnail 里老老实实全量渲染切到缩略图视图的那一刻硬盘狂转、风扇起飞。成熟的实现会做几件事设文件大小上限比如超过64MB直接返回默认图标、面片数超阈值时做抽稀或者只取前若干万个面片、渲染分辨率严格按请求的 cx 走而不是无脑上高分辨率。实测下来这个上限值设得太松是卡顿的第一元凶。第四件是渲染质量的基本体面。最低要求是能看出轮廓进一步是加个简单的朗伯光照让形体有立体感再好一点是给个深浅渐变背景或者地面阴影。我见过有的实现渲染出来是纯白一片——因为法向量没算、光照方向跟视线平行整个模型过曝。这个不是功能问题是体验问题但恰恰是区分能用和好用的地方。2.3 为什么不建议自己从零写一个每次聊到这个话题都有人问既然原理这么清楚自己写一个是不是更自由我的答案是技术上完全可行工程上不太划算。写一个最小可用的 IThumbnailProvider核心代码其实不到三百行实现 IUnknown 的三个方法、实现 IInitializeWithStream 或 IInitializeWithFile 拿到文件、在 GetThumbnail 里读STL、算包围盒、做正交投影、用最朴素的Z缓冲光栅化填色、创建DIB Section返回。真正麻烦的是外围COM注册、32/64位两套编译、DPI感知、多线程调用下的线程安全、异常安全的边界COM组件里抛异常直接崩宿主、签名与杀软误报、以及不同Windows版本之间的行为差异。我见过最深的一个坑是资源管理器在某些场景下会用很小的尺寸比如16×16调用 GetThumbnail如果你的渲染器对极小尺寸没做处理浮点缩放会算出零宽度返回一个无效位图结果是列表视图里那一列全是空白而且不报任何错。这类边角情况只有长期跑在真实环境里才会暴露。所以我的建议很明确优先用成熟的开源实现除非你有非常特殊的定制需求比如要在缩略图上叠打印时长、叠材料类型否则自己写的投入产出比很低。3. 实操把缩略图扩展装进系统并让它真的出图3.1 装之前的五项体检这一步千万别跳我见过太多人装完发现不生效折腾半天最后发现是某个开关没开。按顺序过一遍五分钟能省掉两小时。第一项确认系统位数。右键此电脑看属性或者在命令行敲echo %PROCESSOR_ARCHITECTURE%返回 AMD64 就是64位。64位系统必须用64位的扩展这个没有例外32位扩展在资源管理器里永远不会被加载。有些安装包会同时装两套那最好。第二项检查文件夹选项。打开任意文件夹查看 → 选项 → 查看选项卡确认始终显示图标从不显示缩略图没有被勾上。这个选项一旦勾上全局关闭缩略图任何扩展都白搭。顺手确认隐藏已知文件类型的扩展名是否勾选调试阶段建议取消勾选能直接看到 .stl 后缀避免把 .stp、.step 混进来。第三项检查性能选项。WinR 输入systempropertiesperformance在视觉效果里找显示缩略图而不是图标确认勾选。这一项在某些优化版系统或者被人手动调过性能选项的机器上经常是关的。第四项确认扩展来源。优先选有源码、有更新记录的项目看清楚它支持的是32位还是64位、支持哪个Windows大版本。装之前把安装包丢到多引擎在线查一下Shell扩展本身就是杀软重点关注对象误报率不低提前心里有数。第五项准备好回滚手段。装之前导出一次相关注册表分支或者干脆建个系统还原点。Shell扩展出问题的表现可能是资源管理器反复崩溃重启那时候想进系统改注册表都费劲有个还原点能救命。3.2 两种安装方式的完整步骤现成的扩展一般提供两种安装方式安装包和手动注册我把两条路都走一遍。安装包方式没什么可说的下一步下一步注意两点一是右键选以管理员身份运行普通权限写不进 HKEY_CLASSES_ROOT二是安装过程中如果弹出是否信任此发布者看清楚再点。装完之后直接跳到3.3节做缓存刷新。手动注册方式适合绿色版或者自己编译的版本。假设扩展DLL放在D:\Tools\StlThumb\StlThumb.dll以管理员身份打开命令提示符执行regsvr32 /s D:\Tools\StlThumb\StlThumb.dll/s是静默模式不弹成功提示框。想确认到底注册成功没有去掉/s再跑一次会弹出一个对话框告诉你成功或失败失败时括号里通常带错误码比如 0x80070005 是权限不足0x8007007E 是缺依赖DLL。如果这个扩展没有自带注册脚本就得手动写注册表。两种做法一是跑一遍 regsvr32它内部会调用 DllRegisterServer 把 CLSID 和文件关联都写好这是最省事的二是纯手工写注册表用下面这个 .reg 文件模板把里面的 CLSID 换成扩展实际的Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\.stl\ShellEx\{e357fccd-a995-4576-b01f-234630154e96}] {你扩展的CLSID} [HKEY_CLASSES_ROOT\CLSID\{你扩展的CLSID}\InprocServer32] D:\\Tools\\StlThumb\\StlThumb.dll ThreadingModelApartment注意路径里的反斜杠要写双份这是 .reg 文件的语法要求。ThreadingModel 写 Apartment 还是 Both 取决于扩展本身的设计写错了不一定立刻报错但可能在高负载下出诡异问题这个值以扩展作者的说明为准。改完双击导入系统会提示确认确认即可。还有一种情况扩展只提供了DLL但没写 DllRegisterServer。这时候上面那个 .reg 就得连 CLSID 一起手动建还得确保 .stl 的 ProgID 关联存在。这种情况比较少见遇到了建议直接换一个实现不要在这种半成品上耗时间。3.3 让缩略图立刻生效的缓存清理组合拳注册完不会立刻生效这是最容易被误判成装失败的环节。资源管理器有缩略图缓存和图标缓存两层还有 explorer 进程本身的组件缓存得一起处理。第一步重启资源管理器。命令行执行taskkill /f /im explorer.exe start explorer.exe桌面会闪一下任务栏重新出现。这一步让 explorer 重新加载所有Shell扩展新注册的组件才会被感知。第二步如果还是不出图清缩略图缓存。先关掉所有文件夹窗口然后del /f /s /q /a %LocalAppData%\Microsoft\Windows\Explorer\thumbcache_*.db删不掉是正常的因为 explorer 正占用着这些文件所以顺序应该是先 taskkill 再删再启动。嫌麻烦的话用系统自带的磁盘清理勾选缩略图那一项清理一次效果一样。第三步刷新图标缓存这个主要针对图标变成白纸这类问题ie4uinit.exe -show这条命令会重写图标缓存数据库执行完桌面图标会重新绘制一遍。三步做完回到放STL的文件夹把视图切到大图标正常情况下会看到图标先变成默认的白纸然后一两秒内被替换成渲染出来的模型预览图。如果是几十个文件一起刷第一次会慢一点因为每个文件都要真渲染一遍之后就走缓存了再进这个文件夹是秒开。提示如果文件夹里文件特别多第一次生成建议先切到中等图标视图缩略图尺寸小、渲染快等缓存建好了再切大图标体感会好很多。3.4 参数微调尺寸、上限与DPI装好之后还有几个参数值得调调对了体验差别不小。关于尺寸。缩略图缓存是按尺寸分档的常见档位对应96、256、768、1024、1920这几档具体取决于你的显示缩放比例和视图大小。想让它显示得更大更清楚把视图切到超大图标系统会请求更大的 cx扩展按需渲染。这里有个取舍超大图标视图下每个文件都要渲染一张接近1920像素宽的图文件一多第一次进入文件夹会有明显的等待。关于大文件上限。多数扩展在配置里提供了超过多少MB不生成缩略图的选项或者写在注册表里。我的经验值是这样日常零件模型大多在1到20MB之间扫描类模型经常上百兆。如果把上限设成128MB那么素材库里那几个巨型文件每次刷新都会拖慢整体速度。我一般设在32到64MB之间巨型文件单独放到一个子目录需要看的时候用独立的3D查看器打开。这个不是抠门是在看得见和不卡之间找平衡。关于DPI。高分屏上有个隐蔽问题系统缩放150%的时候请求的缩略图尺寸会跟着放大如果扩展没做好DPI感知出来的图会糊得像蒙了层纱。判断方法很简单把显示缩放切回100%看看是否清晰如果100%清晰而150%糊那就是扩展的DPI处理有问题这种情况下换一个实现比调参数更有效。关于磁盘类型。缩略图缓存默认在系统盘的用户目录下机械硬盘上第一次批量生成会比较慢。如果你有固态盘并且系统盘空间紧张可以把缓存目录迁到别的盘但迁移涉及环境变量和权限收益不大一般不建议折腾。4. 踩坑实录装完不显示、卡顿、错乱的排查手册4.1 装完没反应的五步定位法这是最高频的问题我整理了一个按代价从低到高排序的排查顺序照着走基本能在十分钟内定位。现象最可能的原因排查动作处理方式所有STL都是白纸图标其他格式正常文件夹选项关了缩略图或性能选项关了查文件夹选项始终显示图标查性能选项显示缩略图而不是图标打开对应开关重启explorer只有部分文件夹不显示换个目录就正常该目录被设为优化为文档或存在 desktop.ini 覆盖右键文件夹属性 → 自定义 → 把优化类型改成常规项目改完刷新装完完全没变化注册表项也在扩展位数不对32位装到了64位系统用reg query HKCR\CLSID\{你的CLSID}\InprocServer32看DLL路径用dumpbin或文件属性确认位数换64位版本重装注册表项缺失或指向错误.stl 的 ShellEx 键没写或CLSID值写错手动查HKCR\.stl\ShellEx\{e357fccd-a995-4576-b01f-234630154e96}的默认值重新导入reg或重跑regsvr32装了有反应但一进文件夹explorer就重启扩展内部崩溃常见于畸形STL看事件查看器 → Windows日志 → 应用程序找 explorer.exe 的错误模块名卸载该扩展换实现或先把可疑STL移出目录验证除了表格里的还有两个特殊情况值得单独拎出来。一个是网络位置和云同步目录。放在网络共享盘上的STL缩略图生成要走网络读取很多扩展为了性能会直接跳过网络路径。云盘的按需下载占位文件同理本地根本没有实际数据扩展读不到内容自然出不了图。遇到这种情况把文件设为始终保留在此设备上或者干脆把素材库放本地盘。另一个是路径过长。Windows传统路径上限260字符素材库如果嵌套很深加上长文件名读取文件时可能直接失败扩展拿不到数据就退回默认图标。表现是同目录下文件名短的有图长的没图。解决办法是把目录层级压平或者开启系统的长路径支持。4.2 卡顿、崩溃与缩略图错乱缩略图能出来了新问题跟着来。卡顿的典型表现是进入STL文件夹时整个资源管理器僵住十几秒鼠标转圈期间硬盘灯常亮。根因通常是某个超大文件或者超多面片的模型在同步渲染。定位方法是把文件按大小排序先把最大的几个挪出去再进文件夹看是否恢复流畅。确认是哪个文件之后把它单独放到重型模型目录或者调整扩展的文件大小上限。另一个常被忽略的点是缩略图渲染是串行还是并行、并发数是多少部分实现在多核机器上开太多线程反而因为磁盘随机读把速度拖垮。崩溃的表现更直接一进某个文件夹桌面闪一下任务栏消失又出现这是explorer重启了。事件查看器里能看到 explorer.exe 的错误记录故障模块名直接指向那个Shell扩展DLL。这种基本可以判定是扩展对畸形文件的容错没做好比如三角形数量字段写成天文数字导致申请内存失败或者ASCII解析时遇到不闭合的 loop。处理方式是先把可疑文件隔离二分法一半文件移走看是否还崩逐步缩小范围确认之后要么删掉这个坏文件要么换一个更健壮的扩展。我个人建议是两者都做。缩略图错乱的表现是明明改过模型缩略图还是旧的或者A文件的缩略图显示成了B文件的。前者是缓存键没变导致的改文件内容但保持路径和修改时间不变系统认为缓存有效。强制刷新的办法是复制一份副本再改名或者用前面说的删缓存。后者多见于缓存数据库损坏删掉 thumbcache 文件重建即可。如果删了还错乱那就要怀疑扩展的线程安全问题了——多个 GetThumbnail 并发调用时共享了渲染上下文把A的图返回给了B这是实现缺陷只能换。4.3 卸载残留与系统更新后的失效Shell扩展这类东西装的时候容易卸干净不容易。卸载的正确姿势是先反注册再删文件regsvr32 /u /s D:\Tools\StlThumb\StlThumb.dll/u是反注册它会调用 DllUnregisterServer 清掉CLSID和关联。如果你图省事直接把DLL删了注册表里的CLSID还留着资源管理器每次进STL文件夹仍然会尝试加载那个不存在的路径虽然多半会静默失败但会在事件日志里刷一堆错误而且影响加载性能。残留的清理位置有三处HKCR\CLSID\{那个CLSID}、HKCR\.stl\ShellEx\{e357fccd-...}、以及可能的HKLM\SOFTWARE\Classes\CLSID下的WOW6432Node分支。系统大版本更新之后缩略图突然失效这个我遇到过两次。原因通常是更新过程重置了部分文件关联或者把 ShellEx 键清掉了也可能是新系统对扩展的签名要求变严。处理方式就是重新跑一遍注册然后重启explorer。所以我的习惯是装好扩展之后把那个 .reg 文件和DLL一起备份到素材库旁边的 tools 目录出问题了双击一下就能恢复比重新找安装包快得多。注意如果你同时装了两个STL缩略图扩展后装的会覆盖先装的注册项但两个DLL都在系统里。表现是行为不稳定有时候是A的渲染风格有时候是B的。排查这类问题先查注册表里那个GUID键到底指向哪个CLSID。5. 不想动系统三条轻量路线与批量整理工作流5.1 轻量预览的三条退路不是所有人都愿意往系统里塞Shell扩展尤其在公司电脑或者共用机器上。这里有三条替代路线我都实测过各有适用场景。第一条是空格键快速预览类工具。这类工具的形态是常驻托盘选中文件按空格弹出一个预览窗支持图片、文本、压缩包也支持部分3D格式。优点是不改注册表、不注入explorer卸载就是删目录缺点是预览窗是独立窗口不能像缩略图那样一眼扫一屏。适合偶尔确认文件内容的场景。第二条是独立3D查看器。专门看模型的轻量查看器加载速度快支持旋转、缩放、线框切换、尺寸测量比切片软件轻得多。用法是把查看器固定到任务栏拖文件进去看或者设成 .stl 的默认打开方式双击直接开。这条路线的好处是信息量大——能看尺寸、能测壁厚缩略图给不了这些坏处是依然是一个一个看没法批量扫。第三条是预生成封面。思路很简单写个脚本遍历素材库里的所有STL用命令行渲染器或者建模软件的无头模式导出一张PNG命名成原文件名_preview.png放在同目录。资源管理器对PNG是原生支持缩略图的于是你看到的效果跟装了扩展一样而且这套东西不依赖任何环境换机器、发给别人、备份到移动硬盘都跟着走。缺点是占空间每张封面几百KB、文件数量翻倍、新增模型要记得跑一次脚本。我有几个长期归档的素材库就是用这个方式管的稳得不能再稳。5.2 把几百个STL整理成可检索素材库的流程缩略图只是看得见真正让素材库好用还得靠组织方式。我现在的流程是这样跑了大半年回头率很高。第一层是目录结构。按用途分一级目录结构件、外观件、玩具、维修备件按项目分二级目录单个项目里的文件不再分层。层级压平的好处是路径短、缩略图加载快也方便批量操作。第二层是命名规范。文件名带上关键信息格式大概是项目缩写_零件名_版本_日期比如 brk_mount_v3_20240312.stl。名字里带版本和日期一眼能看出哪个是最新的不用开软件。ASCII文件名优先避免特殊字符和空格能省掉一堆路径解析的麻烦。第三层是封面图。对重点模型我会额外导出一张渲染图存成同名PNG这样即使在不装扩展的机器上也能靠大图标视图看到内容。批量做法是用命令行渲染器跑一个循环脚本里控制视角一致、背景透明、分辨率256跑完整个库大概几分钟。第四层是索引。用一个表格记录每个文件的用途、材料、打印参数、来源链接。表格里嵌一列封面图的缩略图整个库就变成了一份可检索的清单。这个看着土但在要找那个上次打过的支架的时候比翻文件夹快十倍。第五层是备份策略。素材库和索引表一起做增量备份缩略图缓存不用备份会重建但预生成的封面图要备份因为那是人工产物。备份的时候注意排除临时文件和切片软件生成的中间格式能省不少空间。这套流程跑下来最直观的变化是找文件从打开软件一个个看变成扫一眼文件夹就定位一个几百个模型的库找东西的时间从几分钟压到十几秒。缩略图扩展解决的是看得见命名和索引解决的是找得到两者配合起来才是一个真正能用的素材库。最后分享一个我在实际使用中的体会这类系统级的小工具稳定性比功能丰富度重要得多。我宁愿用一个只会画灰色轮廓、但从不出错的扩展也不要用一个能加材质、能加阴影、偶尔让资源管理器崩一次的扩展——因为崩溃一次的成本远大于那点视觉提升。装之前先想清楚自己是要天天用还是偶尔瞄一眼答案不同选型完全不同。