PATCH处理器有一些有趣的行为。从评论中：

// first time through,
	// 1. apply the patch
	// 2. save the original and patched to detect whether there were conflicting changes on retries

	// on a conflict (which is the only reason to have more than one attempt),
	// 1. build a strategic merge patch from originalJS and the patchedJS.  Different patch types can
	//    be specified, but a strategic merge patch should be expressive enough handle them.  Build the
	//    patch with this type to handle those cases.
	// 2. build a strategic merge patch from originalJS and the currentJS
	// 3. ensure no conflicts between the two patches
	// 4. apply the #1 patch to the currentJS object

我认为有三种可能对patch产生意义的操作模式：

1. 用户指定RV;patch尝试一次。如果RV不再匹配，则失败(如果用户的补丁以不可预测的方式依赖于对象的某些部分，这是有意义的)。
2. 用户不指定RV;patch尝试多次，如果补丁停止干净地应用，则失败(用户选择放弃任何锁定--'.spec.replicas'应该是X,我不关心其他人说什么)。
3. 用户指定一个基本对象和一个补丁；补丁将补丁更改解释为对每个更改具有隐含的“from”前提条件。只要具有隐含前提条件的补丁继续干净地应用，就一直重试。(用户希望并发安全地应用，并希望服务器执行重试循环。而且补丁是可预测的。)
   不幸的是，今天的代码没有做上述任何合理的事情，而是将2和3混淆在一起。编辑：1和2已经在#63146中得到解决。
   如果用户尝试今天的情况1,我们认为它仍然会进行5次重试，即使如果第一次有一个冲突，那么其他几次也一定会有冲突。
   如果今天的用户没有指定RV,今天的重试循环会进行一些无意义的冲突检测：用户没有指定与RV的关系，因此在请求首次进入时使用RV作为“基本对象”是一个任意的选择。如果生成冲突，用户只是会用完全相同的补丁重试。
   如果用户想要行为3,今天没有办法实现它。我个人记得行为3是PATCH最初宣传的行为，但这似乎不是普遍的记忆。
   所以，我提议进行以下更改：
4. 如果用户在补丁中指定了RV,不要进行任何重试。这是向后兼容的，因为他们本来都会失败。已在collapse patch conflict retry onto GuaranteedUpdate #63146中完成。
5. 如果用户没有指定RV,不要进行评论中提到的冲突检测，只需使用原始补丁重试。我认为这是向后兼容的，因为所有导致失败的原因实际上都是无意义的。已在collapse patch conflict retry onto GuaranteedUpdate #63146中完成。
6. 为用户提供一种有意调用行为3的方法。这将是一项“新”功能。