在我的应用程序中，我通过监听更改流来对couchdb文档进行后处理。场景如下：
- 我的应用程序收到通知，文档已通过/db/_changes更改
- 它获取文档并检查文档是否有适当的附件，以及附件的
revpos是否等于文档版本的第一部分。例如，如果rev看起来像这个13-D2JDBS3，那么我在-字符处拆分字符串，获取第一个匹配项，将其转换为数字，并将其与附件的revpos进行比较 - 如果以上检查失败，我会生成一个PDF并将其附加到文档中
到目前为止，这个效果还不错。但我想知道这是不是couchdb的设计有意为之。依赖这种行为安全吗(revpos反映了它所属修订的第一部分)？我在文档中找不到任何关于这方面的信息。
提前感谢您对这个话题的任何提示。
我认为这是有意的，似乎是公开的，并记录了API，尽管措辞可能需要一些澄清。
在修订文件中，他们说：
修订号是文档传输表示的MD5哈希，前缀为N，表示文档更新的次数。
在附件文档中，他们说：
revpos(数字)：添加附件时的修订数字[强调他们的]
有点不幸的是，他们在前一个文档中将整个_rev标识符称为"修订号"，因为很明显，后者的目的是将"N"前缀突出显示为">编号"。
你可能会考虑就此提交一个文档错误，要求他们澄清revpos将始终是"N-前缀"的"N"部分，如果他们确实愿意保证的话。