评论由：cemerick
SS 关于这一点，这种做法不会给 Maven 带来任何问题的观点是对的。此外，构建可以很容易地设置，始终发出两个 jar，一个“正常”，一个“调试”。
我建议，虽然 clojure.debug 可能具有广泛的影响，但应该有附加的属性来提供对未来的每个额外的“调试”相关参数化的细致控制。
我想提出几个可能相关的顾虑（在思考了一段时间的断言之后），其中一些或所有这些可能是由于我在各个领域缺乏理解而产生的。
查看在哪里使用 {{assert}} in {{core.clj}}（据我所知只用了两个地方：验证 {{derive}} 的参数和检查 {{fn}} 中的前条件和后条件），看起来将其设置为 {{false}} 不明智。即非 {{Named}} 值可以进入层次结构，并且前条件和后条件将被简单地忽略。
我的理解是，断言（这里指 JVM 构造，Clojure 从它重用 {{AssertionError}}），不应用于验证公共 API 函数的参数，也不应用于验证函数的正常操作的任何方面（即（链接：http://download.oracle.com/javase/1.4.2/docs/guide/lang/assert.html#usage）： "在哪里不使用断言"）。这意味着当必要时，{{derive}} 应该抛出 {{IllegalArgumentException}}，而 fn 的前条件和后条件应该抛出 {{IllegalStateException}}——或者，无论如何，通过 {{assert}} 抛出其他比 {{AssertionError}} 更合适的东西。这将与在 core 中使用 {{assert-args}} 而不是 {{assert}} 的大多数函数相匹配，前者抛出 {{IllegalArgumentException}} 而不是 {{AssertionError}}。
这导致我产生疑问：{{assert}}（以及 * ）是否被设计为Clojure的结构，或者是一种准互操作形式？
如果前者的话，那么它的大致语义可以任意设定，但这样一来似乎就不应该抛出{{AssertionError}}。
如果后者的话，那么在JVM中抛出{{AssertionError}}是合适的，但我们需要注意，应该在运行时（而无需切换不同版本的Clojure构建）启用和禁用断言（assertions），理想情况下使用主机定义的开关（例如{{-ea}}和其他），不太可能像 * 那样做。我不知道目前这是否可行或实用（我认为这将需要相当大的编译器改动）。
希望上述内容在这个时刻还没有成为“陈词滥调”。先行感谢您的耐心。:-)
