一个重要的区别是，该高速缓存中的项可以在指定的时间之后过期（将从缓存中删除）。放入会话的项目将保留在那里，直到会话结束。
当可用内存量变小时，ASP.NET还可以从缓存中移除项。
另一个区别：会话状态可以保持在外部（状态服务器，SQL服务器），并在Web应用程序的多个示例之间共享（用于负载平衡）。该高速缓存的情况并非如此。
除了这些差异（如其他人所指出的）：会话是每个用户/会话，而缓存是每个应用程序。

AFAIK，关键的区别是会话是每个用户的，而缓存将用于应用程序范围内的项目。
正如在其他答案中提到的，只要提供一个密钥（通过会话或cookie），您就可以将每个用户的信息存储在该高速缓存中。这样，您就可以更好地控制该高速缓存中的过期项，并设置对它们的依赖关系。因此，如果有问题的DataTable将定期更改，那么缓存可能是一个合适的选择。否则，如果是静态会话可能更合适。Steven Smith has an excellent video on caching at dnrtv值得一看。
这真的取决于你想实现什么，你有多少时间。关于如何在应用程序中存储状态，还有一些其他的替代方案需要考虑。根据表的大小，您可以考虑将状态存储在cookie中（如果是敏感信息，则进行加密）。或者，如果它是应用程序范围内的数据，您可以在页面或类上使用静态字段。还有Application对象。

更新：我认为你必须问自己的关键问题是谁应该看到这些数据。

Are they going to access the data frequently?

(No，不要打扰）。

Is it going to change?

(No使用静态字段或应用程序）。

Is it acceptable for user a and user b to see the same results?

(No使用具有包括用户名和搜索项的关键字的该高速缓存）。
(Yes使用搜索项的关键字来使用该高速缓存）。
老实说，如果您的开发还没有沿着，我会考虑将缓存/状态问题放到以后--您甚至可能不需要它。
性能调优的前三条规则是：1.测量，2.再量一下。3.再次测量.

另一个重要的区别是，会话状态将被阻止如果并发的Ajax请求被执行，它将影响性能

缓存在应用程序范围内，目的是减少获取数据的次数。会话位于用户的会话范围内，目的是提供特定的用户状态。

这取决于你如何为ASP.NET配置会话。您是将会话存储在数据库中还是存储在内存中？如果在内存中，您是使用单独的服务器还是使用当前的Web服务器进行会话？
根据设置的不同，当您使用数据表之类的东西时，可能会对性能产生影响，这告诉我您可能存储了大量数据。
此外，会话是按用户存储的，并通过会话票证按用户检索，会话票证存储在会话cookie中或URL上（如果用户不接受cookie，并且您已将ASP.NET设置为无cookie模式）。您缓存的任何内容都将在应用程序级别缓存，并可用于所有用户会话，这可能是您想要的，也可能不是。

会话是每个用户的，缓存是应用程序的。
缓存中的项可以并且将会根据到期时间（滑动或固定）和IIS工作进程的内存约束自动删除。
因此，基本上缓存中的项目永远不会保证存在，但会话将保留在那里，直到会话结束。
基于每个用户存储项目（通过会话或创造性地使用缓存）可能会导致大量内存使用，应仔细考虑。
最重要的是，如果IIS重置工作进程，您可能会丢失缓存和会话。

看看这个答案。
Session会降低你的应用程序的性能，除非你使用memcached或velocity这样的后端提供程序。一般来说，你应该避免它。

据我所知，这完全取决于你的需要。
每当需要维护用户的状态时，在使用会话时必须非常小心。默认设置为“InProc”，它使用单个服务器的内存，在基于云的应用程序中无法正常工作。这可能适用于那些在多示例Web场环境中托管应用程序的人。Windows Azure负载平衡器在连接的节点内使用循环分配。
会话存储中有多个选项。SQL Server也可以用作会话状态的存储。自定义会话技术在Azure上可用，如表存储提供程序等。
该高速缓存也存储在服务器的内存中，但它与用户无关。同一个池中的任何用户都可以访问应用程序缓存数据。简而言之，在云上，我们需要使用云提供商提供的缓存服务。Azure提供Windows Azure分布式缓存服务。
事实上，开发人员在应用程序中应用状态管理技术时并不关心该技术的影响。它
“如果您的客户端没有云支持，那么您不必担心云场景”

我刚刚遇到了另一个限制，在最新的.NET版本中给我带来了一些问题。也就是说，使用缓存，可以非常简单地存储对象。对于会话，您只能存储字符串。
现在，很明显，你可以序列化你的对象，并将它们存储为字符串，但这是一个额外的步骤，我不太相信序列化总是按照你想要的方式工作。你必须确保你的对象是可序列化的。有很多扩展方法的例子可以使它变得更容易。
但是，有了缓存，它似乎 * 只是工作 *。作为一个懒惰的开发人员，我真的不希望序列化带来额外的麻烦。Newtonsoft.Json和新的System.Text.Json等各种序列化器之间也有一些显著的差异。虽然可能不相关，因为您将使用相同的Json序列化器进行输入和输出。
有了以上所有的答案，缓存似乎是安全的赌注，如果你的应用程序起飞，你的服务器内存需要敲门，你总是可以使用像Redis这样的东西来开始为你处理缓存很少的努力。