企业官网建设流程全解析

上周有位朋友把一块照片盘挂到我机器上，一个四十多万文件的目录树，扔进某款看图工具之后风扇转了十分钟，内存吃到六个 G，最后卡在"正在生成缩略图"那一步不动了。我当时的想法很简单：找个开源的、基于 .NET 的跨平台图片查看器替他顶上就行。翻了一圈才发现，这类工具要么只认 Windows，要么在 Linux 上得自己编译一晚上，要么宣传里的"格式全"其实只是指主流的十来种格式。后来我干脆自己攒了一个，断断续续折腾了半个多月，顺手把"快、省内存、格式全"这三个宣传词拆开来一项项量了一遍。下文我把这个自己写的查看器叫作轻览，避免变成产品导购。这份记录不讲跑分排行榜那一套，只讲我在这套技术栈上实际踩到了什么、哪些数字站得住、哪些纯属自欺欺人，适合正在用 .NET 写桌面图形工具、或者准备给自己造一个看图小工具的人对照着看。

1. 先把"快"和"省内存"翻译成可验证的指标

"快"这个词在图片查看器这个品类里被滥用到几乎没有信息量。我见过太多介绍页写着"秒开"，结果点进去是拿一张 800×600 的图标在那儿演示。真正要评估一个看图工具，至少得把它拆成四个互不干扰的时间段来看，每一段的瓶颈完全不一样，优化手段也完全不同。拆不开这四段，你调的每一个参数都可能是白费力气。

1.1 四个必须分开测量的时间段

冷启动到窗口出现：这一段跟图像处理几乎没关系，纯看程序集加载数量、是否 ReadyToRun/AOT、UI 框架初始化开销、以及是否在启动时傻乎乎地预扫描目录。我见过最离谱的实现是在Main里同步遍历整个图片目录算文件数，八万张图扫了四秒，用户以为程序没响应。

窗口出现到第一帧像素上屏：这一段才是解码的战场。注意是"上屏"不是"解码完成"，中间还隔着缩放、色彩转换、纹理上传。一张 2400 万像素的 JPEG 解码本身可能只要 180 毫秒，但从解码出的全尺寸位图缩到屏幕上的 1200 像素宽，如果走的是双三次插值在 CPU 上做，又能再吃掉 80 毫秒。

连续翻页时的下一页响应：这时候前一张还在内存里，考验的是缓存策略和预取逻辑。翻页和首次打开是两种完全不同的场景，很多工具首次打开很快，翻页却一张比一张慢，就是缓存没做好。

缩略图墙的首屏填充：这段和上面三段又是另一回事，它考验的是批量解码的并发控制和调度。

我把这四段的测量方式固定下来：用Stopwatch在关键节点打点，每组配置跑五次取中位数，冷启动前清一次系统文件缓存（这一条在三个系统上做法不一样，但至少要在同一台机器上保持测量条件一致）。

1.2 内存峰值该看哪个数，别被任务管理器骗

内存这件事比时间更容易自欺欺人。任务管理器里那个数字是工作集，包含已经被 GC 标记为可回收但还没归还给系统的页。托管程序尤其容易出现"看着占了一个 G，其实里面七百万是垃圾"的情况。

我同时盯三个数：GC.GetTotalMemory(false)拿托管堆实际占用量、进程的私有字节数拿真实占用、以及GC.CollectionCount(2)看第 2 代回收触发频率。判断"省不省内存"我只看两个场景：单张两千万像素以上的图打开后，稳定下来的私有字节是多少；以及连续翻五十张同尺寸大图，私有字节是涨到某个值后稳住，还是一条斜线往上爬。前者反映单图的解码开销，后者反映有没有泄漏。后者如果是一条斜线，别怀疑，一定是哪里没释放。

提示：连续翻图时内存线性上涨、GC 回收后也不下降，九成情况是某个图像对象被事件订阅或者静态字典意外持有了引用，而不是解码器本身有 bug。先查缓存键是不是无限增长的，再查有没有把图像对象挂进了日志或者异常上下文。

1.3 "格式全"的边界在哪里

这是我踩得最深的一个坑。宣传里的"支持 XX 种格式"通常是把"能读出一个缩略图"和"能完整解码并正确显示"混为一谈了。我把常见格式按实际可得性分了三档：

看这张表你就明白，"格式全"本质上不是一个解码能力问题，而是一个分发与授权问题。真正难的不是写解码器，是决定哪些格式值得为它背上一个几十兆的原生依赖。

2. 技术栈的取舍：托管解码还是绑定原生编解码器

.NET 做跨平台桌面图形工具，绕不开两条路线：自绘式跨平台 UI 框架，和官方那套把各平台原生控件包装一层的框架。我两条都试过，最后选前者，理由和性能关系不大，和"一致性"关系极大。

2.1 为什么自绘式框架更适合看图场景

官方那套框架的思路是"在每个平台上用最地道的原生控件"，这在表单类应用里是巨大优势，但在看图场景里是灾难。每个平台的图片控件背后走的是不同的解码路径：有的走系统图像管线，会自动应用系统的色彩管理；有的会偷偷做一次预乘 alpha 转换；有的在高 DPI 下拿到的位图尺寸和你传进去的根本不是一回事。我曾经在三个平台上用同一份代码显示同一张带 ICC 配置文件的照片，结果三个平台显示出的颜色都不太一样，排查到最后发现是其中两个平台的控件在中间做了我没要求的色彩空间转换。

自绘式框架把渲染后端统一了，三个系统上同一张图渲染出来的像素是一致的，这对我这种要对比不同解码路径输出结果的人来说是刚需。另外它允许我把解码后的位图直接作为纹理提交给 GPU，省掉一次 CPU 侧的格式转换。代价是文件对话框、系统托盘、菜单栏这些都得自己封装一层，各平台的差异自己填坑。

2.2 两条解码路径的分工原则

我的分工原则只有一条：常用格式走纯托管，边缘格式走原生，且原生解码必须隔离在独立进程里。

纯托管解码的好处是跨平台行为完全一致、没有原生库分发的麻烦、内存管理交给 GC（虽然这既是好处也是负担）。托管解码库在 JPEG 上的性能其实不差，因为它内部同样用了向量化的 IDCT 实现，真正拉开差距的是"缩放解码"能力。

这里要展开说一个特别关键的技术点：编解码器层面的缩放解码。JPEG 的 DCT 变换天然支持 1/2、1/4、1/8 的降采样输出，也就是说如果你只需要一张 160 像素宽的缩略图，完全可以在解码阶段就让解码器只输出 1/8 尺寸的结果，而不是解出完整的 4000 像素宽再缩放。速度快四到八倍，内存占用降到原来的六十四分之一。托管库和原生绑定都提供了对应的能力，只是接口名字不一样：有的是在解码参数里给一个目标尺寸，有的是先向编解码器询问可用的缩放尺寸再指定。如果你的缩略图管线里没有用到这个特性，那你的缩略图生成速度至少有五倍以上的提升空间，这就是最容易拿到、也最容易被忽略的一笔优化。

原生解码则负责那些托管库啃不下来的格式。这里有个教训：原生解码一定要放进子进程。我最早是直接在主进程里 P/Invoke 一个处理 RAW 的库，某次遇到一张文件头损坏的图，原生侧直接段错误，整个应用闪退，用户看到的是"程序莫名其妙消失了"。改成独立的解码子进程之后，主进程只负责发路径、收像素数据，子进程崩了就标记这个文件读取失败、给个占位图，体验上只是"这张图打不开"，而不是"软件崩了"。

还有一个被严重低估的取巧办法：相机 RAW 文件里通常内嵌了一张全尺寸或半尺寸的 JPEG 预览。直接把这部分预览抠出来显示，速度是解 RAW 的几十倍，绝大多数时候用户只是想快速浏览、挑图，根本不需要真实的 RAW 数据。真正需要导出的时候再走完整的 RAW 解码。我按这个思路做，RAW 文件的首帧时间从一点几秒降到几十毫秒。这个思路对 PSD、AI 之类的分层文件同样适用。

2.3 内存分配器的配置比换库更能决定峰值

这一点我是被数据打脸之后才信的。一开始我不满意托管库的解码速度，花了两天时间评估另一个库，正准备动手迁移的时候，顺手把内存分配器的参数调了一下，峰值直接降了三分之一，速度也回来了。那一刻我意识到，很多人换库换了个寂寞。

托管图像库普遍会维护一块复用的像素缓冲区池，避免每张图都向 GC 申请一大块内存。池子的大小是有默认值的，默认值往往偏保守，因为库作者要考虑小内存设备的场景。桌面端看图完全可以把这个上限调大：

var configuration = Configuration.Default.Clone(); configuration.MemoryAllocator = MemoryAllocator.Create(new MemoryAllocatorOptions { MaximumPoolSizeMegabytes = 192, AllocationLimitMegabytes = 384 });

这几十行配置的实际效果是：连续翻图时，前一张图的缓冲区归还到池子里，下一张图直接复用，不再产生新的大对象。配合我后面会讲的分块解码，连续翻五十张两千万像素图的过程中，私有字节从"锯齿状爬升"变成了"一条几乎水平的线"。

反过来，如果你的场景是"打开一张大图、看很久、关掉"，复用池反而是浪费，因为它会一直占着那块内存不还给系统。这时候更适合用简单的 GC 分配器，让内存该还就还。分配器的选择应该跟着使用场景走，而不是跟着库的默认值走，这是我在这个项目里最实在的一条经验。

3. 我的测试台与四组实测数据

讲完选型，得拿数字说话。需要提前声明：下面的数字全部来自我这台八核 x86 笔记本上的单次采样，不构成任何普适结论，你机器上的绝对值会差很多，但相对关系大体是可复现的。

3.1 测试集是怎么组出来的

我准备了三组数据：

A 组：两千张日常照片，平均文件大小 2.3MB，像素在 1200 万到 2400 万之间，混合了手机拍的 HEIC 转 JPEG、相机直出 JPEG、少量带 ICC 配置文件的宽色域图。

B 组：两百张大图，最短边不低于 4000 像素，包含几张八千像素宽的全景拼接图和几张两万像素级别的扫描件。

C 组：六十个格式样本，专门覆盖各种刁钻情况：16 位深的 PNG、带 alpha 的 WebP 动图、多页 TIFF、CMYK 色彩空间的 JPEG、带 EXIF 方向标记的竖拍照片、文件名里有各种 Unicode 字符的文件。

C 组是我认为最有价值的一组。A、B 两组测的是性能，C 组测的是"这东西到底能不能用"。我见过太多工具在 A、B 两组上表现优秀，一遇到 CMYK 的 JPEG 就显示成一片反色。

3.2 启动与首帧的真实曲线

几个观察：ReadyToRun 是性价比最高的一档，几乎无代价地把启动时间砍掉四成，而且不影响任何反射相关的功能。原生 AOT 能把启动再压一半，但它对动态加载和序列化的限制在桌面应用里是真的疼，我最后只在便携版上开了 AOT，主分发版本还是 ReadyToRun。

首帧时间几乎不受发布方式影响，这符合预期——解码耗时是 CPU 密集型的，跟程序集加载没关系。真正让首帧从 340 毫秒掉到 90 毫秒的，是缩放解码加上"先显示低分辨率预览再补全"的两段式策略：

// 第一遍：只解到屏幕宽度左右，立刻上屏 var previewOptions = new DecoderOptions { TargetSize = new Size(screenWidth, 0) }; using var preview = Image.Load(previewOptions, path); ShowImmediately(preview); // 第二遍：后台解全尺寸，用于缩放和导出 var full = await Task.Run(() => Image.Load(path));

这里有个细节容易翻车：两段式显示时，第二遍解码完成之后如果直接替换画面，用户会看到图像"跳"一下变得更清晰，观感还行；但如果第二遍解码出来的结果和第一遍在色彩上不一致（比如第一遍忽略了 ICC 而第二遍应用了），就会看到明显的颜色跳变。我的做法是两遍走完全相同的处理管线，只是尺寸参数不同。

3.3 峰值工作集对照表

分块加载这一项值得单独说。一张两万像素宽的 PNG，完整解码后光像素缓冲就是 1.6GB，在 32 位进程里直接没戏，64 位进程里也会让系统卡顿好几秒。我的处理是设置一个最大像素阈值（我用的是 1 亿像素），超过阈值的图不走完整解码，而是按视口分块解码——用户看到哪一块就解哪一块，滚动时按需补块，滚出视口的块释放。代价是缩放级别改变时要重新解码若干块，但这个延迟用户是可以接受的，总比内存爆掉强。

提示：最大像素阈值这个数值不要拍脑袋定。它应该由"目标机器上可接受的最大单图内存占用"倒推出来：宽 × 高 × 4 字节。如果你希望单图占用不超过 400MB，那阈值就是 1 亿像素左右。另外这个检查必须在解码之前做，从文件头里读尺寸，别等解完了才发现太大。

3.4 三个和直觉相反的结论

结论一：多线程并行解码的收益远小于缩放解码。我一开始想让批量缩略图生成开满线程，实测八个线程确实快，但内存峰值翻了四倍，而且因为线程间争抢内存池，单张的平均耗时反而变长了。把并发数压到 CPU 核数的一半，配合缩放解码，总吞吐量比开满线程还高一点。

结论二：AVIF 的解码耗时是 JPEG 的十倍以上，而且很难优化。一张 4K 的 AVIF，纯 CPU 解码要六百到八百毫秒。这个格式的压缩率优势在存储和网络上，在即时预览场景里是纯粹的负担。我的做法是把 AVIF 的优先级排在最后，用户打开 AVIF 目录时先显示占位图和文件信息，解码任务丢到低优先级队列里慢慢来。

结论三：真正拖慢大批量缩略图生成的往往不是解码，是磁盘随机读。十万个文件分散在机械盘上，每次寻道十几毫秒，解码才几毫秒。后来我加了一个"目录级顺序预读"的逻辑，按扇区顺序把文件预读进内存缓存，整体速度快了将近一倍。这一条对固态盘不太适用，所以我做成了自适应判断。

4. 十万张照片的目录：虚拟化与三级缩略图缓存

性能数据讲完，真正的硬仗是这个四十多万文件的目录。这个场景和"打开单张大图"几乎是两门学科，前者是吞吐和调度问题，后者是内存和算法问题。

4.1 虚拟化列表的关键不是控件，是取消与限流

虚拟化本身没什么神秘的，只渲染可视区加上前后各一屏的项，主流 UI 框架都有现成支持。真正决定流畅度的是另外两件事：滚动时能不能及时取消已经滚出视口的解码任务，以及同时在跑的解码任务有没有上限。

我第一版没做取消，快速滚动的时候队列里堆了几百个解码任务，用户滚到底部之后，程序还在慢慢解第 30 行位置的缩略图，风扇狂转，用户感觉"卡了"。加了取消令牌之后，滚出视口的任务立刻收到取消信号，实测滚动时的 CPU 占用从接近满核降到两成左右。

private CancellationTokenSource? _cts; async Task LoadThumbnailAsync(ImageItem item) { _cts?.Cancel(); _cts = new CancellationTokenSource(); var token = _cts.Token; try { var thumb = await _decodeQueue.EnqueueAsync(item.Path, token); if (!token.IsCancellationRequested) item.SetThumbnail(thumb); } catch (OperationCanceledException) { /* 正常流程，不记日志 */ } }

限流用信号量，容量我设成"物理核数的一半"，因为解码是 CPU 密集，超过这个数只会增加上下文切换和内存压力。这个值在笔记本上设保守一点（比如 4），台式机上可以放到 8，最好做成可配置。

还有一个容易忽略的点：解码队列的优先级要和滚动方向关联。用户往下滚，优先解下方的；往上滚，优先解上方的。这个逻辑实现起来就十几行，但体感差异非常明显，用户会觉得"缩略图是跟着我的手指长出来的"。

4.2 三级缓存的键设计和失效策略

三级缓存的具体分层：

缓存键的设计是整个缓存系统里最容易出错的地方。我第一版用的是"文件路径 + 修改时间"，结果发现在 Windows 上有个诡异现象：某些同步工具会保留修改时间但替换文件内容，导致缩略图不更新。后来加了文件大小和文件系统内的唯一标识（不同平台做法不同），才算稳定。

磁盘缓存的目录结构我用的是二级哈希：cache/{key[0..2]}/{key[2..4]}/{key}.thumb，每级最多 256 个目录。为什么不用单层目录？因为单层目录下放十万个文件，在某些文件系统上单次打开的开销会明显变大，而且用文件管理器打开这个目录会直接卡住。二级哈希之后，每个目录下最多几百个文件，一切都顺滑了。

清理策略我用的是 LRU 加总量限制，后台线程定期扫描，超过上限就按访问时间删最旧的。这里有个细节：缓存清理要避免和其他 IO 抢带宽，我把它设成最低优先级，并且只在用户空闲（超过十秒没有交互）时才启动。

4.3 滚动卡顿的真凶：那个 85KB 的坎

这一条是我在这整个项目里最有价值的发现，值得单独讲。

托管运行时里有个约定俗成的分界线：大于约 85KB 的对象会被分配到大对象堆。大对象堆的回收代价远高于普通堆，而且默认不压缩，容易产生碎片。看图软件里什么东西最容易落在 85KB 附近？缩略图。

算一下：一张 160×160 的 RGBA 缩略图，像素数据是 160×160×4 = 102400 字节，加上对象头和元数据，稳稳超过 85KB。也就是说，一个显示三十个缩略图的屏幕，会产生三十个落在大对象堆上的对象，滚动时不断产生和回收，碎片越攒越多，滚动就越卡。

我把缩略图尺寸从 160 改成了 128：128×128×4 = 65536 字节，加上对象头刚好落在小对象堆里。改完之后，滚动时的第 2 代回收次数从每屏 3 到 5 次降到接近 0，帧率曲线的毛刺基本消失。这个改动只花了我两分钟，收益超过前面所有的多线程优化加起来。

如果你确实需要 160 像素以上的缩略图，另一个办法是把像素缓冲区从对象里拆出来，用池化的连续内存块管理，只在渲染时把指针交给渲染层。这个做法复杂一些，但同样能绕开大对象堆。

顺带说一下 GC 模式的配置。看图这种交互式单文档应用到不了服务器级别的吞吐量，果断用工作站并发模式，别开服务器 GC。如果滚动时还是有可感知的停顿，可以临时把延迟模式调成持续低延迟：

GCSettings.LatencyMode = GCLatencyMode.SustainedLowLatency; // 批量生成缩略图结束后记得还原，否则会推迟回收、抬高常驻内存 GCSettings.LatencyMode = GCLatencyMode.Interactive;

这个设置不能一直开着。我最早图省事全局设了持续低延迟，结果长时间使用后常驻内存一路涨到一点几个 G 不下降，因为 GC 一直在推迟回收。改成"滚动时开启、静止三秒后还原"，问题消失。

5. 三个系统上真正不一样的六件事

跨平台这件事，写到能跑只花了两天，写到三个系统上体验一致花了两个星期。下面这些是我认为最值得提前规划的部分。

5.1 文件关联、拖拽与剪贴板

文件关联在三个系统上是三套完全不同的机制。Windows 侧要写注册表里的 ProgID 和文件扩展名映射，还要注意设置应用的用户模型 ID，否则任务栏图标会把你的程序和宿主进程合并成一个，图标错乱。我在这上面栽过一次，调试了整整一个下午，最后发现是漏了一行设置。macOS 侧要在应用包的信息清单里声明支持的文档类型，而且必须走完整的应用包结构，单文件发布出来的可执行文件是没法建立关联的。Linux 侧最省事也最麻烦，写一个桌面入口文件配合 MIME 类型声明，用户装不装、装在哪个目录，全看发行版。

我的建议是：文件关联做成一键开关，放在设置里由用户主动开启，而不是安装时偷偷写进去。一来三个平台的行为差异太大，二来用户对"偷偷改我默认程序"这件事非常敏感。

拖拽的坑在于，Windows 拖过来的可能是文件路径，也可能是文件描述符；macOS 拖过来的是带类型信息的粘贴板条目；Linux 上则取决于文件管理器。统一的做法是把三个平台的拖放事件都转换成"要么给我一个路径，要么给我一个可以读的流"，其余逻辑不动。

剪贴板更微妙。从浏览器复制一张图到剪贴板，Windows 上通常是位图数据，macOS 上可能是多种格式并存，Linux 上的行为跟桌面环境强相关。我最后只做了一件事：优先取"文件路径列表"，取不到再取原始位图，再取不到就提示不支持。别指望能覆盖所有情况。

5.2 高 DPI 与色彩管理

高 DPI这一块，Windows 上要在应用清单里声明每显示器 DPI 感知，否则多显示器混合缩放的场景下，把窗口从 4K 屏拖到 1080P 屏，整个界面会糊成一片。macOS 的 2 倍缩放相对省心，但要注意别自己做缩放，交给框架。Linux 上分数缩放至今是个难题，X11 下 1.5 倍缩放的处理方式各个桌面环境都不太一样，我的做法是提供一个手动覆盖的缩放系数，让用户自己填，比自动猜测体验好。

色彩管理这件事的优先级被严重低估了。一张带 ICC 配置文件的宽色域照片，如果不做色彩转换，在普通色域显示器上显示出来要么发灰、要么过饱和。我在第一阶段完全没处理这块，结果用户第一反应是"你这软件显示的颜色不对"。后来接入了完整的色彩管理管线：读入 ICC、转换到工作色彩空间、输出时按目标显示器的配置文件再转一次。这个改动之后，同一张照片在本工具和其他主流工具之间的色差基本看不出来了。

这里有个实操细节：色彩转换要放在解码之后、缩放之前，顺序反了会导致边缘出现色彩溢出。另外转换本身有性能开销，一张大图转换要几十毫秒，所以我把转换结果也纳入了缓存。

5.3 打包体积：裁剪与 AOT 的代价

裁剪的坑在于它是"静态分析猜你用到了什么"，猜不到的直接删掉。图像库、序列化、以及任何依赖反射的配置绑定都是重灾区。我的做法是给每个裁剪警告逐条加根描述，并且专门跑一遍覆盖所有格式的解码测试，确保没有被误删的路径。这个过程很枯燥，但比发布之后被用户投诉强。

原生 AOT 我最终只用在便携版上。它在启动速度上的优势实在诱人，一百七十毫秒的冷启动体验跟原生应用没什么区别。但代价是任何动态加载的解码器插件都不能用了，我只好把所有诊断路径改成编译期静态注册。这个取舍你得根据自己的插件策略提前想清楚。

6. 踩坑记录：几个改到凌晨的兼容性问题

6.1 EXIF 方向被应用了两次

这个问题我排查了三个晚上。现象是：一部分竖拍照片显示的时候被旋转了 90 度，但不是全部；另一部分显示正确。用十六进制编辑器逐个对比文件头才发现规律：一部分照片的像素数据本身就是正向的，只是在 EXIF 里写了一个方向标记；另一部分是像素数据被旋转过，同时 EXIF 里也写了方向标记。前一种情况应该应用 EXIF，后一种情况应用了就转错了。

问题在于，从文件本身无法可靠判断像素数据到底转没转过。这是格式设计上的历史遗留问题，所有看图工具都在猜。我的处理是：默认信任 EXIF，同时提供一个"忽略方向标记"的开关放在右键菜单里，让用户遇到问题时一键切换。这样一来，百分之九十九的情况正确，剩下的百分之一用户自己一秒钟就能解决，比我去猜靠谱。

顺带说一句，这个问题在批量导出的时候更严重。如果导出时又把方向应用一次，出来的文件会带着错误的方向标记，然后被下一个软件再转一次。所以导出流程里一定要把方向处理成"像素已经转正、标记清零"的状态。

6.2 动图解码的帧缓冲泄漏

GIF 和动图 WebP 的播放，我最初的实现是"把每一帧都解码缓存在内存里，播放时按索引取"。这在短动图上没问题，遇到一段几百帧的动图，内存直接起飞，一张 800×800 的动图能吃到一个多 G。

修法分两层。第一层是只在可见时解码：离开视口立刻停止解码并释放已缓存的帧。第二层是改成环形缓冲：只保留当前帧和前后各两帧，往前推进时释放最旧的。这样内存占用就和动图总帧数无关了，只跟单帧尺寸有关。

还有一个隐蔽的坑：动图的帧延时并不总是等于文件里写的那个值。很多动图里写的是 0，实际播放器都按一个最小值处理。如果你老老实实按 0 毫秒延时去跑，会变成一个死循环把 CPU 跑满。我的做法是设一个 20 毫秒的下限。

6.3 路径大小写与 Unicode 归一化

这两个坑属于"不遇到就永远想不到，遇到了要查一整天"的类型。

大小写：Windows 默认不敏感但保留大小写，macOS 的默认文件系统也不敏感但保留大小写，Linux 敏感。这就导致缓存键如果用原始路径字符串做哈希，同一个文件在 macOS 上用不同大小写访问时会被当成两个文件，缓存命中率下降一半。我的做法是在 Windows 和 macOS 上统一把路径转成小写再做哈希键，Linux 保持原样。

Unicode 归一化：macOS 的文件系统返回的文件名用的是分解形式（比如"é"存成"e"加一个组合符号），而用户在搜索框里输入的是合成形式。字符串比较直接不相等，搜不到文件。我在搜索和缓存键两处都做了归一化处理，统一转成合成形式再比较。这个 bug 在纯 ASCII 文件名下永远不会暴露，一旦有中文以外的带音标字符就炸。

提示：如果你的程序要处理用户目录下的图片，符号链接和硬链接也要考虑。我是直接不跟随符号链接的，遇到就跳过并标记，因为照片目录里出现符号链接循环的概率虽然低，但一旦出现就是无限递归卡死。跳过的成本远低于处理它的成本。

7. 一些零散但有用的实操细节

最后把几个不成体系、但确实省了我不少时间的点记下来。

缩略图生成要跳过已经存在的缓存文件，但别在 UI 线程里判断。我见过把File.Exists放在渲染循环里的实现，十万个文件就是十万次系统调用，界面直接卡住。

解码失败的文件要记录下来，不要反复重试。一个目录里总有几个损坏的文件，如果每次滚动过去都重新尝试解码，日志会被刷屏，CPU 也会被浪费。我用一个固定大小的失败集合记录它们，程序重启时清空。

给大图的解码加超时保护。托管解码跑在后台线程里，某些极端文件会让它跑上十几秒甚至卡死。我加了一个软超时（比如十秒），超时就在界面上显示"这张图解码时间过长"，同时把任务丢到低优先级，别阻塞用户看下一张。

别忘了 Windows 上的长期路径支持。现在的照片目录层级动辄几十层，很容易超过二百六十个字符。要在应用清单里声明长期路径感知，还要在项目配置里打开对应选项，否则会遇到莫名其妙的"找不到文件"。

测试集里一定要放中文、日文、韩文、emoji 和带音标字符的文件名。我是吃过亏之后才加进 C 组的，加进去当天就抓到了两个 bug。

这套东西做下来，我最大的体会是：看图软件的性能瓶颈几乎从来不在"解码算法"上。真正吃掉时间和内存的，是缩略图的尺寸刚好踩在大对象堆的门槛上、是滚动时没有及时取消任务、是缓存键设计得不严谨导致的重复解码、是路径字符串在三个系统上的隐式差异。这些问题单看都很小，凑在一起就是一分钟开不了一个目录。

另一个体会是关于"格式全"的。我现在觉得，一个看图工具支持多少种格式，远不如它"遇到不支持的格式时怎么处理"重要。直接崩掉是最差的选择，弹一个看不懂的错误框是次差选择，显示一张占位图加一行清楚的说明，才是用户真正能接受的。我这套代码里所有解码入口外面都包了一层兜底，任何异常都转成占位图加原因，程序本身永远不会因为某张图而挂掉。这个设计带来的稳定感，比多支持三种冷门格式有价值得多。