目前没有CEP提案，也没有在Cassandra 5.0的发布路线图上列出的任何项目重新引入Windows支持。正如Cedrick提到的那样，你可以选择使用WSL，但我认为使用Docker容器可能更适合/更容易作为整体“捆绑包”的一部分部署和运行，并且能够根据需要预先配置容器。

不要
有一个discussion about this on the mailing list，最终导致Cassandra 4.0删除了Windows支持。其原因可以在讨论中找到，但主要与NTFS的问题有关。这些由（现任）PMC主席Josh McKenzie详细描述，他在CASSANDRA-16171中说得最好：
与linux相比，Windows在删除主动打开的文件句柄的硬链接方面有更严格的政策。换句话说，他们不让你做。考虑到C* 中LSM树的架构，这只是一个痛苦的匹配开始，并且反复导致烦恼和延迟文件清理以及各种功能的删除。
可以说，Windows上对Cassandra的原生支持已经消失，而且不会再回来了。

我想插一句，支持亚伦的观点。上下文：在Windows支持方面处于领先地位，推动了2.2版本的发布，因此我们在没有存储引擎重写的情况下获得了Windows支持，并且是Aaron上面引用的人。：）
Windows在内存Map的情况下确实有一些非常可靠的性能指标，但最终作为高性能java应用程序的生产运行时环境，仍然存在一些非常明显的痛点。硬链接无法删除是一个痛点;出现在sstable早期重新打开时，我们不得不删除，在快照积累和需要一个黑客处理注册，在JVM关闭时删除文件，以及在一堆其他小的微妙的地方。
另一个大问题是Windows上的合并计时器：请参阅this link here以深入了解它的困难。其上的TL;DR：为了使Windows上的服务器获得一致的性能（即让线程以常规节奏唤醒，以便epoll响应网络上的内容），我最终不得不使用所谓的“多媒体计时器”，这种计时器迫使系统范围的计时器过载，而不是以15 ms+的间隔合并，而是每毫秒唤醒一次。真的很适合固定那些性能数字;如果世界上有成千上万的服务器在Windows上运行C*，并且不必要地消耗CPU周期，那么这对环境不是很好。作为一个有趣的轶事，当我意识到我的压力运行 * 快得多 * 时，我发现了这一点，因为某种原因，我打开了IRC。结果是IRC客户端正在设置合并计时器窗口，这会影响整个系统。
总之，长话短说- WSL（特别是w/2.0版）在Windows上开发基于Linux的env的易用性方面确实有很大的不同，我个人不建议在基于Windows的环境中运行基于Java的高性能进程，特别是LSM树，考虑到环境的上述一些现实。
假设有人想站出来贡献一等公民Windows支持，这对现有的代码库没有太大的破坏性，并且他们有兴趣维护它，项目将100%接受谈论它。但现在，没有一个活跃的贡献者关注这一点，也没有计划回到它。