资源文件的转换问题
这篇讲的是作者在自研游戏引擎中遇到的一个资源转换缓存失效问题，以及由此展开的架构优化。 他们引擎的资源转换采用惰性策略：在虚拟文件系统中，根据`.lk`描述文件和平台信息按需生成最终资源。但最近发现，对于 shader 这类依赖其他 include 文件的“代码型”资源，仅靠源文件和`.lk`文件的 hash 作为缓存 key 是不够的——修改依赖文件后，系统并未感知变化，错误地返回了旧缓存。 根因在于初始设计过于简化，未考虑编译的完整依赖链。放弃惰性构建的方案很快被否决，团队最终提出一个更巧妙的方案：当请求构建时，系统会在后台无条件重新编译，并将此次编译的**完整参数和依赖关系**（包括所有依赖文件的路径及当前 hash）写入一个新的构建脚本文件（如 `a.sc.lk.ios`）。这个文件本身唯一确定了一个编译结果，其 hash 就成了新的、精确的缓存 key。 这个机制既保留了惰性转换的优点，又实现了准确缓存。相比 Unity 的 cache server，它的优势很明显：缓存键是包含依赖的完整过程，因此可以跨项目复用（同一张贴图不会因路径改变而需重新编译）。此外，文件服务器还能利用空闲时间预编译其他平台版本，这是纯键值存储的 cache server 做不到的。这个设计有点类似 Git 大文件存储，用一个轻量引用指向背后的编译服务。