我正在使用 autoreload-server 示例，该示例非常适合使用 ns-tracker 在更改 .clj 文件时重新加载命名空间。
https://github.com/pedestal/samples/blob/master/auto-reload-server/dev/dev.clj
但是，它不会在 resources/public 目录中获取激活模板的更改。我已将模板路径添加到 defn watch 中的向量：
`([] (watch ["src" "resources" "resources/public" "public"]))`
以及使用 enlive deftemplate 的命名空间中的这个：
(net.cgrand.reload/auto-reload *ns*)
但是，这不起作用。我的假设是 ns-tracker 仅适用于 clj 文件，并且我错误地使用了 enlive reload 功能。
有没有人在使用 enlive 并且已经解决了这个问题，或者有什么想法可以尝试？
我希望Enlive Issue #6: Auto-reloading of templates在 2013 年 12 月上旬的 1.1.5 版本中通过这个 commit得到解决。但是，在我的测试中，我无法确认它是一个修复程序。我可能做错了什么。
注意：我认为您引用的示例可以追溯到Pedestal 的 0.2.0 之前的工具更改。我可能是错的，但我认为你最好遵循当前的文档，而不是那个示例文件。
Pedestal 的 'hello world' 服务应用程序的主要建议（可能会改变）是：
使用ns-tracker确定要重新加载的命名空间。
添加:resource-paths ["config", "resources"]到project.clj以便 Enlive 可以找到您的静态 HTML 资源。
这些步骤不足以导致对资源的更改触发重新加载，因为ns-tracker不会关注:resource-paths. 以下是详细信息：
细细想来，就明白为什么ns-tracker不拾取资源了；它们不是 Clojure 命名空间。在我看来，这是一个连贯的设计决策，命名为ns-tracker.
尽管如此，从实用的角度来看，很明显，从 Pedestal 的角度来看，我们确实希望在资源更改时重新加载。
现在，让我补充一点。从工具的角度来看，假设您确实在资源目录上设置了一个监视。即便如此，以精细的方式确定哪些特定的 Clojure 命名空间会受到影响并不容易。一个资源可以被defsnippet多个deftemplate's 使用。因此，一项资源更改可能会影响多个 Clojure 命名空间。指向资源的字符串甚至可以动态构造。因此，在一般情况下，确定要重新加载的确切最小命名空间集可能是不可能的。
综上所述，只要资源发生更改，它应该足够“简单”且足够安全以重新加载所有 Clojure 命名空间。
所以，总而言之，我自己还没有解决这个问题，但希望我上面解释的内容将有助于推动球向前发展。
我找不到现成的可行解决方案，所以我最终编写了一个小型环形包装器来完成这项工作，请参阅https://github.com/kolov/enlive-reload