AssetMender 回答三个 Unity 自身答不了的问题。
【谁在用这个资源？】
Unity 的引用是单向存储的。Project 窗口能告诉你一个资源依赖了什么，却永远告诉不了你什么依赖了它。AssetMender 建立反向索引，任何资源都能查——在工具窗口里查，或者在 Project 窗口右键直接查。
【什么已经没人用了？】
AssetMender 从构建场景、Resources 目录、StreamingAssets、预加载资源、标记了 AssetBundle 的资源，以及 Project Settings 引用的资源出发，沿引用关系逐层展开。凡是走不到的，连同体积一起列出来，让你看清包体里到底装了什么。删除走的是系统回收站，不是永久删除。
【什么坏了，怎么修？】
AssetDatabase 只知道能解析成功的引用，所以它根本无法报告一个指向已删除资源的引用。AssetMender 直接读序列化文件，列出每一个解析不到的 GUID，并区分"丢失脚本"和"丢失资源"。
对于丢失的脚本，它还会显示挂载它的 GameObject 名称，以及这个组件上仍然序列化着的字段名。Unity 从来没存过类名，但看到 moveSpeed、jumpHeight、groundMask 这几个字段，通常就足以认出这是 PlayerController。
然后它会修好。把断裂的 GUID 指向正确的脚本，AssetMender 会重写全项目所有相关引用。每个组件上原有的数值全部保留——数据从来没丢，丢的只是指向类的那个指针。脚本在 Unity 外被重命名、被重新导入、在程序集之间移动、或者合并冲突处理失误之后，需要的正是这个。
任何改写之前，原文件都会先复制到 Assets 目录之外的带时间戳备份文件夹。
【它不会假装能做到什么】
没有任何引用扫描能看见运行时按名字加载的资源。所以在出结果之前，AssetMender 会先读你自己的脚本，查找 Shader.Find、Resources.Load、Addressables、AssetBundle.Load 和 Type.GetType 的调用，并指出具体文件和行号。一个在二十处调用 Shader.Find 的项目，列表里很大一部分其实都在用。
出于同样的原因，Shader 和脚本默认被排除在"无用资源"列表之外——这两类最常被按名字解析，因此最容易看起来没被引用。结果一律标注为"候选项"。AssetMender 不会告诉你某个资源可以安全删除，因为任何针对 Unity 项目的静态分析都支撑不起这个结论。