• 只解析你需要的东西
• 别让 find-file-noselect 拖慢批量操作
• 用 cl-progv 隔离全局状态
• 让数据形状决定行为，而不是手动标记
• 先 profile，再优化
• 哈希表替代线性扫描
• 总结

Elisp 里解析 Org 文件的标准方式是调用 org-element-parse-buffer 。它的默认行为是完整解析整个 buffer——包括行内标记、链接、脚注，全部递归展开。

但如果你只需要提取文件开头的标题和日期，完整解析就是巨大的浪费。 org-element-parse-buffer 接受一个可选的 GRANULARITY 参数：

'headline

只解析标题结构

'greater-element

不递归进入大元素内部，只解析顶层

'element

解析所有元素但不解析行内对象

'object

完整解析（默认）

原文作者只需要标题和日期等元数据，把粒度从默认的 'object 改成 'greater-element ，单文件解析时间直接砍了一截。这不是微优化——对 10000 个文件来说，每个文件少解析几百个行内元素，累积效果显著。

(org-element-parse-buffer)

(org-element-parse-buffer 'greater-element t)

选择哪个粒度取决于你需要什么。提取元数据用 'greater-element ，需要处理链接和行内标记才用 'object 。

Emacs 有两种方式读取文件内容：

1. find-file-noselect —— 正经打开文件，创建一个完整的 buffer
2. with-temp-buffer + insert-file-contents —— 把文件内容塞进临时 buffer

原文作者一开始选了 find-file-noselect ，觉得它更"正确"。然后用 Emacs 内置的性能分析器（ M-x profiler-start ）一看，发现这个函数吃掉了 13% 的 CPU。原因： find-file-noselect 会触发文件锁、版本控制查询、major-mode hook、org-persist 缓存写入等一系列交互式操作。对每个文件都来一遍，10000 个文件就是在重复 10000 次不必要的开销。

(org-with-file-buffer filename
  (org-element-parse-buffer 'greater-element t))

(with-temp-buffer
  (insert-file-contents filename)
  (org-element-parse-buffer 'greater-element t))

切换到 with-temp-buffer 后，10000 篇博文的处理时间从 3 分 44 秒降到 1 分 15 秒。教训：批量处理文件时，用临时 buffer 而不是 find-file-noselect 。后者是为交互式编辑设计的，带着整套"官僚系统"。

Emacs 的状态管理建立在全局变量上—— org-export-with-toc 、 org-html-link-home 等都是全局变量。在同一个进程里处理多个 route 时，一个 route 设置的变量会"泄漏"到下一个 route。

直觉上的做法是用 let 绑定：

(let ((org-export-with-toc t))
  (opd-route ...))   
(opd-route ...)

(opd-export)         

问题是： opd-route 不会立即执行导出，它只是把 route 的配置（输入模式、输出路径、过滤器等）存到一个列表里。真正的 HTML 生成发生在 opd-export 被调用的时候——但那时 let 的作用域已经结束了， org-export-with-toc 的局部绑定已经不存在了。换句话说，你在一个 let 块里填了一张表单，但处理表单的人要等到 let 块结束之后才看它，那时候表单上写的"特殊要求"已经没人记得了。

那能不能把 opd-export 放进 let 里？也不行，因为不同 route 需要*不同的*变量值——blog route 要目录（ org-export-with-toc 为 t ），RSS route 不要目录（ nil ）。 opd-export 一次执行所有 route，你没法在一个 let 里同时给不同 route 设不同的值。

解决方案是用 cl-progv ，这个来自 Common Lisp 的宏可以在运行时动态绑定一组变量。每个 route 把自己的变量设置写在 :env 属性里，引擎处理到那个 route 时才临时绑定，处理完自动恢复：

(cl-progv
    '(org-export-with-toc org-html-link-home)      '(nil "http://localhost:8080")                     (org-export-as 'rss))

cl-progv 接受变量名列表和值列表，在执行 body 期间动态绑定这些变量，执行完后自动恢复。这比手动在每个 lambda 里 let 绑定更干净——你可以把变量配置做成数据，从 route 定义里传入，而不需要在每个导出函数里硬编码。

原文遇到一个问题：blog route 和 rss route 都匹配 *.org 文件，两者都在全局注册表里写入 URL，互相覆盖。最初的解法是加一个 :canonical 标记，手动指定哪个 route 有写入权限。

后来发现根本不需要这个标记。关键是观察聚合（aggregate）后数据的形状：

• 1:1 route（每个文件对应一个输出）：数据的顶层有 abspath 属性
• 1:N route（多个文件聚合为一个输出，如 RSS）： abspath 藏在嵌套列表里

(defun opd--tree-has-abspath-p (tree path)
  "递归搜索 Lisp 树中是否包含 (abspath . PATH) 。"
  (cond
   ((and (consp tree)
         (eq (car tree) 'abspath)
         (equal (cdr tree) path)) t)
   ((consp tree)
    (or (opd--tree-has-abspath-p (car tree) path)
        (opd--tree-has-abspath-p (cdr tree) path)))
   (t nil)))

用数据结构本身的特征来区分行为，而不是引入额外的标记。这是 duck typing 的思想：不问"你是什么"，而是看"你长什么样"。消除了一个配置项，也消除了用户忘记设置它导致的 bug。

原文最有价值的教训之一：不要猜瓶颈在哪，用 Emacs 自带的性能分析器。

原文作者的直觉告诉他瓶颈在字符串模板处理上。profiler 显示真正的罪魁祸首是 find-file-noselect （13% CPU）和 org-persist-write-all-buffer （12% CPU）。直觉和数据的差距巨大。

性能优化的正确顺序：

1. 先写正确的代码
2. 用 profiler 找到真正的瓶颈
3. 只优化 profiler 指出的热点

这个顺序对任何语言都适用，但在 Elisp 里尤其重要——因为 Elisp 的性能特征和直觉经常不一致。你以为慢的地方可能根本不是瓶颈，真正的热点藏在你不注意的地方。

当文件数量从几十个增长到几千个时，线性扫描列表的成本从可以忽略变成不可接受。原文的处理方式很直接：任何需要按文件名查找的场景，用哈希表代替列表。

(member target-file file-list)

(gethash target-file file-hash-table)

原文在路由注册表（registry）、文件缓存（filecache）、依赖图（depcache）三个地方都用哈希表，消除了所有线性扫描。对于 10000 个文件的场景，这个差异是"每个文件多查 10000 次"和"每个文件查 1 次"的差距。

这不是过早优化——当你的数据量明确会达到千级别时，选择哈希表是基本的数据结构选择，就像去超市买东西用购物袋而不是一趟趟用手捧。

从这些优化中可以提炼出几条通用的 Elisp 工程原则：

1. 用正确的工具做正确的事 —— 临时 buffer 读文件， find-file-noselect 留给交互式场景
2. 只处理你需要的数据 —— org-element-parse-buffer 的粒度参数是个宝藏
3. 用 profiler 驱动优化 —— 不要猜，让数据说话
4. 用 cl-progv 隔离状态 —— 全局变量是 Emacs 的设计遗产， cl-progv 是在批量场景下控制它的有效手段
5. 让数据形状驱动逻辑 —— duck typing 比手动标记更不容易出错
6. 数据量大了就用哈希表 —— 这不是过早优化，是基本的数据结构选择