从Go 1开始，WriteTimeout可能需要一个更清晰的描述。也许只有我遇到这个问题，但不仅我需要多次阅读它，还需要检查源代码以确保我正确理解了它。
参考一下，现在它是这样的：

// WriteTimeout is the maximum duration before timing out
    // writes of the response. It is reset whenever a new
    // request's header is read. Like ReadTimeout, it does not
    // let Handlers make decisions on a per-request basis.
    WriteTimeout time.Duration

我认为这段代码按照文档说明工作，尽管毫无疑问文档可以改进。如果你设置了一个短的超时时间，那么这个超时时间就会生效。我无法准确地告诉你想要的不同行为是什么；也许使用一个 context.Context 会在这里有所帮助。

CC @bradfitz

我无法准确地告诉你你想要的不同行为。
从 WriteTimeout 的名称来看，人们可能会期望 timeout 适用于每个 Write 单独或写入响应整体。然而，实际上 WriteTimeout 对读取请求体、处理它(例如执行数据库查询)和写入响应施加了组合限制。
此外，即使在“请求处理”期间遇到 WriteTimeout,也不会在请求完全处理后(例如所有数据库查询都已执行)被检测到，直到尝试写入响应时才会被发现。与 context.Context 一样，WriteTimeout 有效地“中止”了长时间的请求，但与 context.Context 不同，它以相当低效的方式这样做，即它只阻止响应被写入。
因此，在我看来，有三个相关但独立的问题：

• 由于请求花费太长时间的问题(如上所述),当前的行为值得怀疑。
• 变量名有些误导性。
• 文档有些模糊。

就文档而言，Mattermost 配置页面对 WriteTimeout 的实际作用有清晰而准确的描述：“这是从读取请求头结束到响应被写入的最大允许时间。”我喜欢它的措辞。

如果你对某个方面有建议，可以更新文档以澄清它，但正如其他人所说，我们不能在这里改变行为。
人们真正感兴趣的功能请求bug是 #16100 ,用于在Handler中操作超时。

这种令人困惑的行为是Mattermost中某些错误的根本原因：
https://mattermost.atlassian.net/browse/MM-9692mattermost/mattermost#8348

由于这个功能按预期工作并且有相应的文档记录，改变行为可能会破坏代码(由于Go 1兼容性承诺，我们无法这样做),这看起来是Go2需要考虑的事情。
我会让@bradfitz对此发表意见。