# 慢封禁还是错误封禁？
**URL:** https://meta.discourse.org/t/slowban-or-errorban/141633
**Category:** Feature
**Created:** [2020年二月14日 19:06 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633 "2020-02-14T19:06:17Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@dfabulich](https://meta.discourse.org/u/dfabulich)
#### Post date: [2020年二月14日 19:06 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/1 "2020-02-14T19:06:17Z")
> **[Suspension, Ban or Hellban?](https://blog.codinghorror.com/suspension-ban-or-hellban/)**
>
> For almost eight months after launching Stack Overflow to the public, we had no concept of banning or blocking users. Like any new frontier town in the wilderness of the internet, I suppose it was inevitable that we’d be obliged to build a jail at...
早在 2011 年，Jeff 就撰写了一篇精彩的博客文章，讨论了不同类型的替代封禁措施：
- **地狱封禁（hellbanned）** ：用户对所有其他用户不可见，但关键的是，对他们自己可见。从他们的角度来看，他们似乎正常参与社区活动，但_从来没有人回应他们_。（地狱封禁也被称为“影子封禁”。）
- **慢速封禁（slowbanned）** ：用户访问的每个页面都会被强制插入延迟。
- **错误封禁（errorbanned）** ：用户访问的页面会被随机插入错误信息。
我注意到有一个 [Discourse 影子封禁插件](https://meta.discourse.org/t/discourse-shadowban/85041)。但影子封禁/地狱封禁对被封禁用户来说相对容易发现：只需退出登录后浏览论坛即可。
Discourse 团队是否会考虑实施慢速封禁或错误封禁？或者这必须通过插件来实现？
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2020年二月14日 19:11 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/2 "2020-02-14T19:11:27Z")
> [@dfabulich](#):
>
> Discourse 团队是否考虑实施“慢封禁”（slowban）或“错误封禁”（errorban）？
“慢封禁”与将用户锁定为信任等级 0（及其带来的相应速率限制）有何不同？
在我看来，将那些问题用户（其严重程度尚不足以被停权或封禁）锁定到较低的信任等级并施加相应的速率限制，效果很好。我们在 Meta 站点就是这么做的。
---
### Author:  [@dfabulich](https://meta.discourse.org/u/dfabulich)
#### Post date: [2020年二月14日 19:23 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/3 "2020-02-14T19:23:29Z")
公开停权和封禁可能导致用户进行报复，甚至延伸到论坛之外。“被禁了！他们想让我闭嘴！我得到了回应，这太令人兴奋了！我要号召论坛成员，让大家看看版主有多邪恶！”
秘密封禁是一种在不引发用户报复的情况下对其进行处罚的方式。理想情况下，这些用户只是对论坛失去了兴趣。
正如 Jeff 在帖子中指出的那样：
> 我曾与一些大型在线社区的管理者交谈过——你很可能每天都在参与这些社区——其中一个原因是，这些社区之所以至今没有陷入彻底的混乱，是因为他们秘密地对问题最严重的用户实施 **地狱封禁** （hellban）和 **缓慢封禁** （slowban）。这些方法巧妙地解决了让麻烦用户“自愿”离开社区的问题，同时将戏剧性冲突降到最低。很难反驳那些已被证明行之有效的手段。
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [2020年二月14日 19:26 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/4 "2020-02-14T19:26:03Z")
> [@dfabulich](#):
>
> 暂停和封禁
这完全不是我建议的。我问的是，为什么不将该用户锁定在较低的信任等级，以限制其发帖频率，从而实际上让他发帖_变慢_（即降低发帖频率）。
---
### Author:  [@dfabulich](https://meta.discourse.org/u/dfabulich)
#### Post date: [2020年二月14日 19:35 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/5 "2020-02-14T19:35:08Z")
这并不神秘。
---
### Author:  [@sam](https://meta.discourse.org/u/sam)
#### Post date: [2020年二月15日 00:56 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/6 "2020-02-15T00:56:33Z")
> [@dfabulich](#):
>
> Discourse 团队是否会考虑实现 slowban 或 errorban？或者这需要通过插件来实现？
在此说明 Discourse 的立场。
在可预见的未来，我们没有任何计划将 slowban、errorban、hellban、disemvowling（移除元音字母）、自动报复性 DoS 攻击、downloadfloodban、bitcoinban 以及任何其他报复性功能集成到核心产品中。
我们也没有计划围绕这一领域开发插件。此类功能必须通过第三方插件实现。
---
### Author:  [@Stephen](https://meta.discourse.org/u/Stephen)
#### Post date: [2020年二月15日 03:29 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/7 "2020-02-15T03:29:31Z")
> [@sam](#):
>
> 去元音化
我最新喜欢的术语。
---
### Author:  [@anon48433008](https://meta.discourse.org/u/anon48433008)
#### Post date: [2020年二月15日 13:25 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/8 "2020-02-15T13:25:12Z")
> [@sam](#):
>
> 这类功能必须通过第三方插件实现。
但请注意，客户没有这个选项，这可能会引发不满。或许应该重新考虑如何让客户需求与员工职责更好地协调。
我想这就是为什么会有这些限制，当两者不匹配时，额外的工作量就会增加。
---
### Author:  [@justin](https://meta.discourse.org/u/justin)
#### Post date: [2020年二月16日 01:07 UTC](https://meta.discourse.org/t/slowban-or-errorban/141633/9 "2020-02-16T01:07:51Z")
另一种观点认为，更强大的封禁工具与更好的内容审核解决的是同一个问题。虽然网络喷子永远存在，但许多麻烦用户的问题可以通过版主一致且富有沟通性的行动得到纠正。社区并非民主制度（因此需强制执行参与规则），但应首先给予人们通过自身行为做出更好选择的机会。在我看来，这是体面且值得尊重的做法。