一条被拦截的消息去了哪里
拦截，是一个关于「要不要回复」的决定，它没有说明你的文本接下来会怎样。不同的服务做法不同：有些会丢弃它，有些会记录这次事件，有些会保留消息以供审查，还有些会把反复出现的拦截计入账号记录。而那些描述过滤器的页面，很少提到这一点。
人们把一次拦截，当作这次交流的终点。但从服务一方来看，这往往是一份记录的开端，而这份记录，是一个和你当初提问完全不同的独立问题。
接着阅读
这次事件通常会被记录下来
即使一项服务丢弃了消息的文本，它通常也会记录下发生过一次拦截，带上时间戳和类别。这份日志的存在，是为了调优过滤器，也是大多数服务会保留的最低限度的记录。丢弃文本，和保留事件记录，这两者并不冲突，而一个声称「什么都不存储」的页面，可能说的正是这个意思。
有些服务会保留消息本身
审查一批被拦截消息的样本，正是过滤器得以改进的方式，而改进，需要真实的例子。在这种情况下，一条被拦截消息的文本，被人工阅读到的可能性，反而比一条普通消息更高。这和通常的预期正好相反，在你粘贴一些敏感内容去测试过滤器之前，这一点值得了解。
反复出现的拦截，可能会波及账号
有些服务，会统计拦截次数，达到一个阈值后就采取行动：一次警告、一次限制，或者一次封禁。这种机制如果存在，通常写在条款里，而不是产品页面上。一项没有账号的服务，没有任何地方可以附加这样的计数，这是一种结构性的差异，而不是政策上的差异。
如何查清楚
去读条款里「审核」「审查」「执行」这些词，而不是去读产品页面。一项说清楚自己保留什么、保留多久的服务，确实告诉了你一些信息；而一项只描述过滤器做了什么的服务，回答的是一个不同的问题。
输入之前
一条被拦截的消息，比一条得到回答的消息更安全吗？
往往正好相反，因为被拦截的消息，正是那些值得被审查的消息。以为拦截就意味着文本被扔掉了，是一个常见的误解。
一项没有账号系统的服务，依然会记录拦截吗？
它可以记录这次事件，却没办法把它和某个具体的人关联起来。事件和身份是两回事，只有后者才需要一个账号。
我能问一项服务，它保留了什么吗？
如果存在一套数据请求流程，可以。得到的答案，涵盖的是绑定在你账号上的内容，所以一项没有账号的服务，没有任何东西可以返回给你。
在测试一项服务会拦截什么之前，先读读它会保留什么。
打开无过滤聊天