您可以选择将 AssetBundle 与游戏或应用程序一起分发，也可以选择通过游戏或应用程序从远程服务器下载。在后一种情况下，下载 AssetBundle 时，务必采取预防措施，防止 AssetBundle 数据损坏以及恶意行为者的攻击。用户的设备会莫名其妙地崩溃，一个常见原因就是下载的 AssetBundle 中存在数据损坏。此类情况可能要花费大量精力和时间来诊断和解决。尽管 AssetBundle 不能包含可执行代码，但更改序列化数据可能允许攻击者利用游戏代码或 Unity 运行时中的漏洞。
UnityWebRequestAssetBundle 可用于从互联网下载和缓存 AssetBundle。使用此 API 时，应在 URL 中使用 HTTPS 协议，除非 URL 引用在同一台机器上运行的本地 Web 服务器。HTTP 协议并不安全，容易受到中间人恶意攻击。
Unity 提供的工具可用于使用校验和来确定 AssetBundle 在下载时未损坏或遭到修改。在 AssetBundle 构建过程中会生成一个 32 位校验和，该校验和会记录在 .manifest 文件中并由 BuildPipeline.GetCRCForAssetBundle 公开。检查 CRC 可确保 AssetBundle 数据在构建后未损坏或篡改。通过 UnityWebRequestAssetBundle.GetAssetBundle 下载 AssetBundle 时，必须提供此 CRC，以便无效 AssetBundle 内容无法进入缓存。请参阅 AssetBundle 压缩和缓存，了解更多详细信息。
如果自行下载或分发 AssetBundle，并且不使用内置的 AssetBundle 缓存，那么在使用检索到的任何内容之前，请务必执行完整性检查。可以使用 AssetBundle Load API 上的可选参数来传递预期的 CRC 值。如果提供，加载系统会在加载 AssetBundle 之前计算其未压缩内容的校验和。如果 AssetBundle 的 CRC 与提供的 CRC 不匹配，则不会加载 AssetBundle。对于使用 LZ4 压缩的 AssetBundle，这样做的开销可能很大，因为这会强制将文件完全解压缩到 RAM 中。对于 LZMA 压缩的 AssetBundle，加载已强制进行全内容解压缩，因此执行 CRC 检查不会带来很多额外开销。总之，在设备上检索和存储文件时，执行一次完整性检查，从而避免 CRC 计算的开销，而不是在每次加载时重复执行，这种做法可能非常实用。
注意：如果使用 AssetBundle 压缩，则不应使用其他常见哈希算法（例如 md5）来验证 AssetBundle 文件。这是因为 Unity 有时会重新压缩 AssetBundle，即使内容没有更改，这意味着在文件内容实际仍然有效的情况下，文件内容哈希可能会更改。相反，AssetBundle 的 CRC 值是根据未压缩的内容计算的，即使重新压缩捆绑包，该值也保持不变。
注意：Unity 构建计算并存储在 .manifest 中的 AssetBundle 哈希不是 AssetBundle 完整文件内容的哈希。它可用作 AssetBundle 的版本值，但不适合用于检测文件损坏。
如果您允许用户上传分发给其他玩家的内容（用户生成的内容），则您有责任过滤此数据中的不当或恶意内容。我们不建议您让用户构建和上传二进制 AssetBundle 文件。最好让用户上传他们的源资源，并让您（开发人员）为他们构建 AssetBundle 二进制文件。这将使您更容易通过手动和自动流程过滤掉恶意或不适当的内容。如果您升级到更高的 Unity 版本，这样还可以让您根据需要重建 AssetBundle。