解读

国内面试中，这道题常作为“WebGL线程模型”的敲门砖。
面试官真正想听的，是候选人能否把“浏览器安全沙箱 + Unity WebGL导出机制”这两个底层限制讲清楚，并给出可落地的替代方案，而不是背概念。
答不出“JavaScript单线程 + 无POSIX pthread”会直接被判定为缺少真机WebGL调优经验。

知识点

1. WebGL导出后代码最终编译为JavaScript（WebAssembly），运行在主线程，没有真正的后台线程。
2. 浏览器禁止任意创建Worker；Unity WebGL运行时也未把System.Threading.Thread映射到Web Worker，因此Thread.Start会抛出NotSupportedException。
3. ThreadPool同样不可用，因为CLR层面就没有pthread实现。
4. Unity官方文档明确：所有Unity API（含资源加载、Instantiate、Transform操作）必须在主线程调用，否则直接崩溃。
5. Task、async/await在WebGL下不会创建新线程，只是C#状态机的语法糖，回调仍然排队到主线程的Unity Job System或浏览器事件循环，所以安全可用。
6. 若需真并行，只能手动JavaScript层创建Dedicated Worker并通过jslib插件与Unity通信，但无法访问UnityEngine命名空间，仅适合纯计算任务。

答案

“WebGL平台最终生成JavaScript，浏览器出于安全考虑不提供POSIX线程，Unity也未把Thread映射到Web Worker，因此Thread.Start在运行时会直接抛NotSupportedException。
所有Unity API必须在主线程执行，后台线程方案在WebGL下既无意义也不被允许。
替代方案是使用async/await或Task，它们在WebGL下不会新建线程，只是利用C#状态机把回调压入主线程队列，即保证了线程安全，又能把耗时逻辑分帧处理，避免卡死UI。
例如，把大块数据解析拆成await Task.Yield()循环，即可在不阻塞渲染的前提下完成加载。
如果确实需要并行计算，只能手写JavaScript Web Worker，通过jslib插件把计算结果PostMessage回Unity，但无法调用任何UnityEngine接口，落地成本较高，国内项目一般优先拆帧+协程解决。”

拓展思考

1. Unity 2021之后推出的Unity.WebGL.Threading包，内部用Emscripten的emscripten_async_call把Task回调塞入浏览器事件循环，可进一步降低帧率抖动，建议商业项目直接引入。
2. 对于海量数据解析场景，可预编译为AssetBundle或gzip压缩后放CDN，首帧只加载索引，后续按需异步解压，把CPU峰值平摊到多帧，比任何“假多线程”都稳。
3. 面试时可以主动反问：“贵司WebGL项目是否用Web Worker做物理预测？”展示你对极限性能优化的嗅觉，容易加分。