当在Unity中通过方法 Cursor.SetCursor 设置光标时，需要传递的参数之一是 cursorMode，它是类型为 CursorMode 的枚举。这个枚举有两个取值，在文档中的描述如下：

Auto - 在受支持的平台上使用硬件光标。

ForceSoftware - 强制使用软件光标。

这些描述对我来说非常含糊——到底是什么意思（“硬件光标”和“软件光标”是什么）？在什么情况下这些不同的取值会导致不同的行为？

解决方案

Unity的文档在这点上有些两极分化。有些类型（类、枚举或其他类型）解释得相当清楚，甚至还给出示例；而有些你不仅要挠头或捶脸，甚至需要量子物理学学位来“解码”。

简而言之：关于Unity如何处理光标的一个主要线索在Cursor页上：

Supports hardware cursors on macOS, Windows and Linux. Falls back to software cursors on unsupported platforms.

这意味着 ForceSoftware 是“我知道这对任何情况都能工作”的“安全”代码路径。 Auto 更像是一种“如果可以使用就用，如果不能就给我你所能提供的”类型。如果应用程序具备“直接访问操作系统API”的能力（是的，我在这里故意说得含糊一些），就有机会使用硬件光标；否则，就不能使用（比如在用WebGL的浏览器游戏、那种15年前的、已弃用的类似Flash的 Unity插件，或者鼠标并不完全原生支持的情况的设备——如某些控制台、电视、移动设备等）。

至于差异，硬件光标据说更为精确。因为它由操作系统完全处理，性能也更好。就大多数场景而言，开发者在编码时应使用“Auto”，无论你的游戏类型是什么。软件光标是实现光标的“旧方法”（意味着在较旧的操作系统上，或在那些本身不原生支持的系统上以某种模拟方式实现）。

一些闲聊的若干枝节问题：从上面的链接可以推断，确实存在支持硬件光标的操作系统/平台（显然是桌面端，因为移动设备本来就没有真正的“光标”，通常使用 TouchType），但对其他平台如电视、浏览器等可能有一些限制，因为它们是“分层的”（如果你愿意这样称呼的话）。当然，智能电视和浏览器各自有自己的“保护机制”，例如低完整性、作业/OS命名空间、沙箱等（视情况而定），每个环境都利用其API；这是一个很长的话题，并不完全相关，但或许能帮助你理解为何光标并非“100% 可访问”的，它只是一个“软件光标”，以及Chrome等浏览器如何实现自我隔离的问题。如果你想知道Chrome如何将自己与桌面环境隔离，可以看看这篇有趣的旧文。核心观点是，层级越被隔离，你可用的功能就越少（比如没有硬件光标）。这也是为什么UWP游戏的功能访问比完全桌面应用/游戏要少的原因。类似地，为什么Xbox的后台在控制台上不能使用完整的WINAPI（因为控制台也是以自身的方式被沙箱化的）。