khenmu
(John Sweeney)
1
你好。
@JammyDodger 发布了 https://meta.discourse.org/t/trust-level-permissions-table-inc-moderator-roles/224824，其中提到：
然而，当我（Discourse Meta 用户信任等级 2。获得徽章后，我无法再点赞，并被告知需要等待更长时间。这让我认为初始的 50 次点赞或 x1.5 倍数是不正确的。如果这是准确的，我猜是后者，否则数学计算就不那么清晰了。
我最初打算回复该帖子，询问他是否可能犯了错误，但是，随着我继续研究，我开始怀疑他正确地记录了预期的行为。
例如，博文 Understanding Discourse Trust Levels 也提到了 UTL2 的点赞倍数（诚然，我不确定这篇博文是否被编辑过或允许过时）。
此外，UTL 相关徽章的描述也暗示了这一点；
所以，要么是功能在某个时候被故意更改了，而记录它的资源都没有相应更新（考虑到 Discourse 是一个庞大的项目，这完全有可能），要么是信任等级的“每天点赞次数更多”部分似乎没有按预期工作。
我既不是 Ruby 程序员，也不熟悉代码库，所以无法进一步调查。
这些由管理员设置中的“additional likes per day”（每天额外点赞数）控制，并且仍然非常有效：
您可能会收到两条关于点赞的消息——一条是您用完了当天的所有点赞额度，另一条是您在短时间内使用点赞过快，这也会有一个冷却期。我想知道您是不是触发了第二条消息而不是第一条？
我刚刚在我的测试站点上用一个 TL2 测试用户快速测试了一下，以确保一切正常，它似乎运行正常：
补充说明——“Out of Love”（点赞耗尽）徽章也是每天授予的，而不是由发帖行为触发的，所以这也可能解释了您获得徽章的时间与您当天剩余点赞数之间的不匹配。
khenmu
(John Sweeney)
3
不；肯定是第一种。这里有一张截图；
我后悔你把这个话题从 Contribute > Bug 移走，但我不会冒险去撤销版主编辑。
确实，在不提供更多信息的情况下擅自覆盖团队分类的移动，这不符合论坛礼仪。 
如果你能提供更详细的复现步骤，或者指出其他存在此问题的网站，我们随时可以将其移回原处。
我在测试站点上进行了测试，发现其表现完全符合预期。因此，这看起来更像是由于以下延迟造成的误解：
