Shake构建咨询：Pandoc建站中后续发现依赖文件的处理方案

我来帮你梳理下这个Shake+Pandoc搭建网站时的依赖管理问题，结合我实际用Shake做构建的经验聊聊：

先回答你的第一个问题：need的调用顺序重要吗？ #

Shake里的need是用来声明构建依赖的，它的调用顺序本质上不影响构建的正确性——因为Shake是基于依赖图来调度任务的，不管你什么时候调用need，只要在执行实际的构建动作前声明了所有依赖，Shake都会先确保这些依赖处于最新状态，再继续当前任务。

不过有个小细节要注意：如果在构建动作执行到一半时才调用need，Shake会暂停当前动作，先处理完依赖更新再回来继续。从代码可读性和维护性来说，最好在构建动作的最开头就声明所有依赖，这样逻辑更清晰，也能避免中途暂停带来的潜在混乱。

再对比三个方案的优劣 #

方案一：让Pandoc调用函数返回依赖列表，后续调用need #

这绝对是最优方案，既没有冗余工作，也不需要生成额外中间文件，完美贴合Shake的依赖管理逻辑。

具体来说，你可以封装一个工具函数，比如pandocExtractDeps，它内部会解析目标Markdown文件（比如用Pandoc自带的--list-inputs参数提取引用的资源，或者自己解析文件里的YAML配置、CSS链接、参考文献路径等），返回生成的HTML路径和所有依赖文件列表。然后在Shake规则里，先调用这个函数拿到依赖，用need声明这些依赖，最后再执行实际的Pandoc转换。

举个伪代码示例：

-- 封装提取依赖的函数
pandocExtractDeps :: FilePath -> IO (FilePath, [FilePath])
pandocExtractDeps srcMd = do
  let destHtml = replaceExtension srcMd ".html"
  -- 这里可以调用pandoc --list-inputs获取所有引用的文件，或者自定义解析逻辑
  deps <- cmd "pandoc" "--list-inputs" srcMd
  return (destHtml, lines deps)

-- Shake规则
"*.html" %> \dest -> do
  let src = replaceExtension dest ".md"
  (_, deps) <- liftIO $ pandocExtractDeps src
  need deps -- 先确保所有依赖都最新
  -- 执行实际转换
  cmd "pandoc" src "-o" dest "--css=style.css" "--bibliography=refs.bib"

这个方案的优势是：没有重复工作、逻辑连贯、依赖追踪准确，完全符合Shake的设计理念。

方案二：先调用独立的依赖查找函数（重复工作） #

这个方案的问题很明显——重复执行了两次类似的解析工作：一次是为了找依赖，一次是实际转换。如果你的文档体积大、依赖多，会直接增加构建时间，降低效率。而且如果后续要修改依赖解析逻辑，你需要同时维护两个地方的代码，很容易出现不一致的问题。除非你的依赖逻辑特别简单（比如只需要追踪固定的CSS文件），否则完全不推荐。

方案三：拆分步骤生成中间文件 #

这个方案虽然能解决依赖问题，但会硬生生打断Pandoc到HTML的直接转换流程，生成一堆无意义的中间文件（比如先把Markdown转成包含依赖信息的元文件，再基于元文件生成HTML）。这不仅会让项目目录变得混乱，还增加了构建流程的复杂度，后续维护成本很高。除非你有必须拆分步骤的特殊需求（比如需要对中间内容做二次加工），否则这个方案的性价比极低。

内容的提问来源于stack exchange，提问作者user855443