和别人一样，我也走过这条路：
- 从一个列表开始，也许是从当前的 GitHub 仓库下载的。
- 立即达到 2000 条条目的限制。
- 哦，我可以使用正则表达式——太棒了！
- 复杂的正则表达式很容易超过 100 个字符。
- 将它们分开。
- 优化正则表达式，糟糕，它又超过 100 个字符了。
- 将其进一步分解。
与限制共舞并非不可能，只是令人讨厌，尤其是当这些限制是人为设定的时候。话虽如此，我理解这种过滤是同步进行的，而扩展的处理可能会导致性能问题，我也理解在为尽可能多的受众设定合适的限制所面临的困难。所以，虽然我为这些限制而挣扎，但我无法合理地反对它们。
我在这里看到了 word_watcher.rb 的代码：word_watcher.rb。作为一名开发者，我很乐意尝试编写一个插件，但这段代码看起来并不容易扩展。我不知道如何在插件中用 JavaScript 来增强 Ruby 进程……或者这是否可能，取决于 word_watcher 代码的编写方式。
这里有一个增强功能的想法，可以帮助减轻处理大量列表的负担。
与其为每种监视列表类型处理整个列表，不如考虑通过不同的过滤器块进行循环。例如，我们可以将最常见和最滥用的过滤器放在 block1 中，其他放在 blocks2-n 中。同步过滤器进程一次只处理一个块，并且仅在最终的“保存”操作中进行一次完整的过滤器循环。块可以操作现有列表，因此无需任何人进行更改。现有列表将被分成 1000 条条目的块，因此 block1 是 1-1000，block2 是 1001-2000，依此类推。希望优化的管理员现在可以选择将他们优先级更高的过滤器移到列表的更前面。
这样做的一个优点是，不必处理整个列表就可以捕获问题。最可能出现的问题将在较小的块中被捕获，并且同步进程可以更快地从处理较小的块中返回。当然，如果在第一个块中找不到监视文本，则需要处理另一个块。这会稍微增加一些开销来捕获不太可能出现的滥用行为。这变成了一个可选的调整问题——如果有人愿意的话。
这里的另一个选项是让管理员选择块的大小。通过减小块的大小，也许每个循环周期为 500 条条目，每个同步进程将运行得更快，但可能需要处理的块会更多。这取决于滥用的类型以及列表的优先级设置情况。同样，这种调整将是可选的，坦率地说，我怀疑许多管理员会进行如此多的调整。
请注意，精细调整意味着我们拥有可量化的指标：我们在监视单词处理上花费了多少时间，以及我们实际捕获了多少问题？这种技术细节应该留待以后增强或插件来实现，如果确实有必要的话。
最终，如果这里描述的“监视单词块处理”得以实现，列表中的条目数量可以扩展到 2000 条以上。是的，读取更长的列表并将其分解会带来一些开销。再一次，如果我们有关于此过程消耗了多少时间的指标，管理员可以确定自己的优化阈值……但我有点怀疑有多少人会深入研究这一点。发布的指南可以是“在没有监视单词块处理的情况下，限制仍然是 2000 个监视单词。使用块处理没有特定限制，但实际限制可能估计为大约 5000 个，并且随着条目数量的增加，性能会显著下降。”
这有希望吗？