在Emacs Lisp中劫持宏参数：定义宏作用域的实现问题

问题根源：宏的展开时机坑了你 #

你这个思路踩中了Lisp宏的核心特性——宏是在代码编译/定义阶段展开的，不是运行时。咱们拆解一下为什么你的hijack-f没用：

库里面的g是个函数，当你定义(defun g (x) (f x))的时候，Lisp会立刻把函数体内的(f x)展开成x（因为库的f宏逻辑就是返回参数）。等你后来调用g的时候，它的实际代码早就变成了(defun g (x) x)，不管你用macrolet怎么重定义f，g的逻辑已经完全固化，运行时根本不会再触发f的宏展开，自然没法劫持参数。

解决方案分两种情况 #

情况1：允许修改库的代码（最直接的方案） #

把库中的g从函数改成宏：

; 修改后的库代码
(defmacro f (x) x)
(defmacro g (x) `(f ,x))

这时候你的hijack-f就能完美工作了！调用(hijack-f (g 1))时，g会先展开成(f 1)，这个f会被hijack-f里的macrolet劫持，进一步展开成(f (+ 1 1))，最后全局的f宏把它展开成(+1 1)，结果就是2。直接调用(g 1)则会正常展开成1，完全符合你的预期。

情况2：完全不能修改库的代码（曲线救国方案） #

这种情况下，你没法真正劫持g内部的f调用（因为函数体内的宏展开早就完成了），只能退而求其次，直接修改g的行为：

(defmacro hijack-f (body)
  `(flet ((g (x) (funcall #'g (+ 1 x))))
     ,@body))

这个方案是在hijack-f的上下文里重新定义了一个局部的g函数，它会把参数加1后传给原来的g。这样调用(hijack-f (g 1))会返回2，直接调用(g 1)返回1，但要注意：这本质是修改g的输入参数，不是劫持f的参数——如果g里有多个f调用，这种方法没法统一处理。

核心结论 #

宏的展开时机决定了：只有当被调用的代码（比如g）是宏时，才能通过macrolet这种局部宏定义劫持其中的宏调用；如果是函数，函数体内的宏调用在定义时就已经被“固化”成普通代码了，运行时没有任何办法回溯干预。

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