欢迎！请在关于页面了解有关此功能的更多信息。
如果merge可使用瞬态会更理想。
补丁 - clj-1458-7.patch
方法 在transients和reduce之后迁移c.c/merge到核心中。保留旧版本作为merge1，用于之前的更早定义的情况。让APersistentMap/conj和ATransientMap/cons意识到IKVReduce。
附上的补丁保留了merge的两个现有行为- 元数据传播- 合并的右边可以是Map.Entry，长度为2的IPersistentVector以及常规地图。
由请求和jira审核
评论人：jawolfe
我将在今天尝试修改补丁。
此补丁（transient-merge.diff）使merge，merge-with和zipmap（因为它就在那里，显然也会受益于瞬态）使用瞬态。
三个潜在问题- 我必须移动这些函数，因为它们依赖于瞬态和相关函数。我假设这比前向声明更可取。这是我找到的最佳位置，但乐于将其移动到其他地方。- 我添加了多个参数数量，以避免将单个参数瞬态化可能带来的潜在性能成本。如果需要，我乐于取消这一点。- 由于瞬态映射不支持contains?（或find），我不得不对merge-with中的逻辑进行微小修改。
评论者：michalmarczyk
我在2012年5月30日为{{zipmap}}发布了单独的票据（补丁）：CLJ-1005。
哎呀，抱歉我越界了。如果这样能简化事情的话，我很乐意从这次补丁中移除那个更改——请告诉我。
评论者：gshayban
附加了一种替代方法，将合并延迟至协议加载后，然后使用transducers。
评论者：michaelblume
看起来你在两次进行（get m k）操作——这不应该被放入局部变量吗？
嗯，我把本地变量称为“put”——“throw”是一个不恰当的词语。
是的，这会影响到——在CLJ-700被提交后，将不再使用get。
我们应该添加性能测试。合并两个、三个、多个映射，并且根据映射的大小和对于合并-with，碰撞百分比的变化。
需要回到（某些身份）逻辑，否则从第一个提供的映射以外的映射会传播元数据。我稍后会修复。
我不知道这是否应该被允许的，但这会破坏
(merge {} (link: :foo 'bar))
此字符串被 compojure-api 用于实际应用。
https://github.com/metosin/compojure-api/blob/0.16.6/src/compojure/api/meta.clj#L198
Ghadi, contains? 在底层使用 get，所以仍然是两次 get，对吧？看起来坚持用 ::none 技巧可能更有效。
评论者：bronsa
这是一个使用 if-let + find 的方法。
新的补丁解决了到目前为止的问题
CLJ-1458-transient-merge3.patch 移除了愚蠢的内联宏，改用单例函数。
非常好 =)
应该附上测试。如果我们想保留与 MapEntry 合并的能力，应进行测试。这不仅仅是补丁的弱点，更是现有测试的弱点。我在测试套件中看到几次使用了 merge 和 merge-with，但我看不到专门测试其行为的测试。
