Differences 阳炎引擎与BSE的区别
由于阳炎引擎考虑到了运行时是和页面直接衔接，所以相比 BSE 的 Flash 运行时，产生了诸多安全区别。 比如：如果直接在页面运行代码，则代码弹幕可以偷去用户cookie、代替用户发弹幕、伪造站点信息等。 因此，KagerouEngine被设计成在沙箱内运行的引擎，但是因此也产生了一些兼容性问题。
沙箱局限性 Sandbox Limitations
沙箱并不是完美的，它在很多方面提供了更多的可控性，其中之一就是可以直接派发 XMLHttpRequest 请求。 由于这种请求依然被同域策略限制，请求只能访问Scripting的载体服务器。为了保证安全，你可以在一个子域 或者另一个根域名下放置脚本代码引擎，避免你的主服务器被请求。不过值得注意的是，代码依然可以访问外部的 开放资源，同时也可以借此把需要的信息向外部传递。当然，可以获得的信息仅限于通过 OOAPI 派发来的信息 而已。
兼容性挑战 Compatibility Issues
由于沙箱是建立在 信息传递（Messaging API） 基础上的，我们只能可靠的进行单向信息汇报。我们无法在 这个API下实现可靠的阻塞式双向信息传递，所以在沙箱内的许多功能將依赖沙箱外界发来的状态报告。
我们举例如下：
Player开放了许多可以用来读取播放器状态的接口，比如 Player.time, Player.state 等。由于我们
无法在脚本读取这些属性是现去请求外部，所以我们必须使用缓存的数据。即，外部定期会同步状态到沙箱内
而更细的信息则会被沙箱脑补。比如当播放器传来 Play/Timeupdate信息时，Player会更新内部的状态信息
而在第二个消息到来前，读取各种状态则会被Player脑补。
如果 Player.state 在播放中状态，那么在两个 timeupdate 之间，读取Player.time则会返回上次的
playtime + 从上次timeupdate 到现在所经过的时差。
同样， 由于无法高效获取外部的刷新率，enterFrame事件的广播则会完全由沙箱内部接管。不过这个广播的
派发频率可以由 $.frameRate 调整。更加详细的区别会在各个API接口处表示出来。